Connect OpenThunder to Claude Code, Cursor, and other AI agents

OpenThunder ships an MCP (Model Context Protocol) server that lets your AI coding agent work against your repo's real architecture graph, with file:line evidence, instead of burning tokens re-reading files. It is keyless and deterministic: no API key, and nothing leaves your machine.

It exposes three MCP capabilities: tools (30+ callable actions, highlighted below), read-only resources (openthunder:// context an agent pulls on demand), and prompts (reusable workflows). The guiding rule: your agent declares intent and requests; OpenThunder observes reality and decides. An agent can ask OpenThunder to verify a change; it can never tell OpenThunder the change is verified.

What your agent can ask (tools)

These are the highlights of the deep-graph toolset; the server registers 30+ tools in total (add change-coordination and verification tools like get_repository_context, verify_change, and can_i_ship).

• resolve_route , which server route serves an HTTP path, and where its handler lives (file:line). It matches a concrete call like /api/users/42 to the route /api/users/:id.
• trace_flow , the end-to-end path of a request: client fetch to route to handler to database table, as ordered steps with file:line. This is the cross-tier path an agent cannot derive by reading one file.
• who_owns , which feature or subsystem a file belongs to (derived from the graph, not folder names), plus that feature's routes and tables.
• list_findings , structural problems the graph proves by enumeration: client calls that hit no route (broken calls), routes nothing calls (orphans), and unguarded database-write paths.
• api_contract_drift , mismatches across the client/server seam: a client call whose method doesn't match the route, a call with no route, or a route nothing calls.
• graph_blast_radius , the precise reachability blast radius of a file: what a change can affect downstream, what depends on it upstream, and the routes, tables, and flows in the closure.
• risk_hotspots , the riskiest files to touch, ranked by git churn multiplied by architectural centrality (a file that changes constantly and that many things depend on is where regressions cluster).
• co_change_coupling , hidden coupling: files that change together in git history but have no code dependency between them , an implicit contract nothing enforces.
• suggest_reviewer , who should review a change to a file: the engineers with the most commit history in it (git ownership).
• sensitive_data_flows , routes whose flow reaches sensitively-named data (users, passwords, tokens, payments, ...) , a review trigger for authentication and exposure. It helps identify risk; it is not a security guarantee.
• trace_event , trace a domain event through pub/sub: who publishes and consumes it, and which events are orphans (published but never consumed, or vice-versa).

Context your agent can pull (resources)

Resources are read-only context the agent fetches on demand instead of you pasting it in. Each reflects the current repo and is keyless and deterministic:

• openthunder://repository/summary , what the repo is: architecture and layers.
• openthunder://repository/architecture , the boundaries and constraints to respect before editing.
• openthunder://changes/current , the live change set: branch, observed changes, and the agent-claim-vs-observed-reality view.
• openthunder://findings/open , findings detected in the current repo.
• openthunder://risks/current , ranked risk hotspots.
• openthunder://intent/discovered , the intent discovered from the code (what the software is meant to do).

Reusable workflows (prompts)

Prompts steer the agent to call OpenThunder's own tools in the right order. They never act on their own:

• openthunder-review-current-change , review the uncommitted change with OpenThunder evidence before committing.
• openthunder-verify-before-finish , record intent + evidence and request verification before declaring a change done.
• openthunder-explain-repository , explain the repo grounded in the deterministic analysis.
• openthunder-fix-finding , fix a specific finding and prove the fix.
• openthunder-architecture-impact , assess the architecture impact of changing a file before editing it.

Install

Install it into your agent with one command (from a repo, or pass OT_REPO_PATH):

openthunder mcp install --client claude    # or: cursor, codex, all

This writes the correct config for that client (merge-safe, with a .bak backup) and pins the repo. Prefer to configure it by hand, or use a different client? The manual paths below all work. The server ships as @openthunder/mcp (binary: openthunder-mcp); openthunder mcp print outputs a copy-paste config.

Claude Code

claude mcp add openthunder \
  --env OT_REPO_PATH=/path/to/your/repo \
  -- node /absolute/path/to/openthunder/packages/mcp/dist/index.js

Then, in a session, ask things like "trace the flow for POST /api/orders" or "what does the graph say is broken?" and the agent will call the tools.

Cursor

Add to ~/.cursor/mcp.json (global) or the project's .cursor/mcp.json:

{
  "mcpServers": {
    "openthunder": {
      "command": "node",
      "args": ["/absolute/path/to/openthunder/packages/mcp/dist/index.js"],
      "env": { "OT_REPO_PATH": "/path/to/your/repo" }
    }
  }
}

Any MCP client

The server speaks MCP over stdio. Launch node packages/mcp/dist/index.js; the repo defaults to the OT_REPO_PATH environment variable or the current directory, and every tool also accepts a repoPath argument so one server can answer for multiple repos.

Languages

The graph is built from real code across TypeScript/JavaScript, Python, Go, C#/.NET, and Java, and it correlates across languages , so in a polyglot repo a TypeScript frontend fetch links to the Python, Go, C#, or Java route that serves it, all the way down to the data layer (SQL tables, MongoDB collections, and Prisma models). Every extractor is keyless and deterministic; unsupported files are simply skipped.

Privacy

Everything runs locally and keyless. The server reads your code on your machine to build the graph and returns only derived facts (routes, flows, findings) with file:line pointers. Your source is never uploaded.