callgraph-mcp 1.4.3 → 1.4.4

package/README.md

@@ -1,12 +1,12 @@
 # callgraph-mcp
 
-**CallGraph MCP Server** — exposes deterministic call-graph analysis for any codebase as [Model Context Protocol](https://modelcontextprotocol.io/) tools. Give your AI agent a precise, structural map of your code — no hallucination, no guessing.
+<p>**CallGraph MCP Server** — exposes deterministic call-graph analysis for any codebase as [Model Context Protocol](https://modelcontextprotocol.io/) tools. Give your AI agent a precise, structural map of your code — no hallucination, no guessing.</p>
 
-Fully local. No cloud. No LLM. No telemetry.
+<p>Fully local. No cloud. No LLM. No telemetry.</p>
 
-Powered by [`@codeflow-map/core`](https://www.npmjs.com/package/@codeflow-map/core) and Tree-sitter WASM parsers.
+<p>Powered by [`@codeflow-map/core`](https://www.npmjs.com/package/@codeflow-map/core) and Tree-sitter WASM parsers.</p>
 
-**Supports:** TypeScript · JavaScript · TSX · JSX · Python · Go
+<p>**Supports:** TypeScript · JavaScript · TSX · JSX · Python · Go</p>
 
 ![Cyclic call graph demo](https://raw.githubusercontent.com/devricky-codes/callgraph-mcp/refs/heads/main/assets/cyclic.gif)
 
@@ -16,13 +16,13 @@ Powered by [`@codeflow-map/core`](https://www.npmjs.com/package/@codeflow-map/co
 
 ## Why Deterministic Analysis Matters
 
-Most AI coding tools answer structural questions about your codebase by reading source files as text and reasoning over them. This causes three compounding failure modes:
+<p>Most AI coding tools answer structural questions about your codebase by reading source files as text and reasoning over them. This causes three compounding failure modes:</p>
 
 - **Hallucination.** When asked "what calls `processPayment`?", a model without structural grounding will guess based on naming patterns and training priors. It will confidently name callers that don't exist and miss ones that do.
 - **Lost in the middle.** Research shows that LLMs systematically fail to recall information from the middle of long contexts. Paste a 200-file codebase into context and the model will answer based on whatever happened to land near the top or bottom.
 - **Attention dilution.** Even when information is present, spreading the model's attention across tens of thousands of lines means each individual fact gets less weight. A critical edge in the call graph competed for attention with everything else.
 
-**callgraph-mcp eliminates all three.** It never reads your code as prose. It parses every file into an AST using Tree-sitter, builds an exact directed call graph, and answers structural queries against that graph. Every caller, every callee, every reachable function, every cycle - returned as a precise index. The answer is always the same regardless of how large your codebase is, which files happen to be in context, or how deeply buried a function is. **There is no probability involved. There is no attention to dilute.**
+<p>**callgraph-mcp eliminates all three.** It never reads your code as prose. It parses every file into an AST using Tree-sitter, builds an exact directed call graph, and answers structural queries against that graph. Every caller, every callee, every reachable function, every cycle - returned as a precise index. The answer is always the same regardless of how large your codebase is, which files happen to be in context, or how deeply buried a function is. **There is no probability involved. There is no attention to dilute.**</p>
 
 ---
 
@@ -33,7 +33,7 @@ Most AI coding tools answer structural questions about your codebase by reading
 
 ### Option 1 — VS Code via `npx` (no install required)
 
-Add to your project's `.vscode/mcp.json`:
+<p>Add to your project's `.vscode/mcp.json`:</p>
 
 ```json
 {
@@ -50,15 +50,15 @@ Add to your project's `.vscode/mcp.json`:
 }
 ```
 
-Start the server in your editor. WASM grammars are bundled — no environment variables needed.
+<p>Start the server in your editor. WASM grammars are bundled — no environment variables needed.</p>
 
 > **Tip:** Create `.vscode/mcp.json` via the Command Palette -> **MCP: Add Server** -> **stdio**.
 
 ### Option 2 — HTTP-SSE (shared or remote server)
 
-Use `FLOWMAP_TRANSPORT=http` for HTTP-SSE compatible clients.
+<p>Use `FLOWMAP_TRANSPORT=http` for HTTP-SSE compatible clients.</p>
 
-Start the server:
+<p>Start the server:</p>
 
 ```bash
 FLOWMAP_TRANSPORT=http FLOWMAP_PORT=3100 npx callgraph-mcp
@@ -66,7 +66,7 @@ FLOWMAP_TRANSPORT=http FLOWMAP_PORT=3100 npx callgraph-mcp
 # $env:FLOWMAP_TRANSPORT="http"; $env:FLOWMAP_PORT="3100"; npx callgraph-mcp
 ```
 
-Then point your client at it:
+<p>Then point your client at it:</p>
 
 ```json
 {
@@ -81,7 +81,7 @@ Then point your client at it:
 
 ## Tools Reference
 
-Optional parameters shown in `[brackets]`.
+<p>Optional parameters shown in `[brackets]`.</p>
 
 <table>
 <colgroup><col width="22%"><col width="38%"><col width="40%"></colgroup>
@@ -99,7 +99,7 @@ Optional parameters shown in `[brackets]`.
 </tbody>
 </table>
 
-**`workspacePath`** — absolute path to the repo root (e.g. `/home/user/my-project` or `C:\projects\my-app`).
+<p>**`workspacePath`** — absolute path to the repo root (e.g. `/home/user/my-project` or `C:\projects\my-app`).</p>
 
 ---
 
@@ -127,13 +127,13 @@ Optional parameters shown in `[brackets]`.
 
 > *"I just modified `processPayment`. Without reading any code, tell me every function that could break and rank them by how many hops away they are from the change."*
 
-The agent calls `flowmap_get_callers("processPayment", workspacePath)` for the direct impact radius (1 hop), then recursively traverses callers-of-callers to build a ranked list by distance.
+<p>The agent calls `flowmap_get_callers("processPayment", workspacePath)` for the direct impact radius (1 hop), then recursively traverses callers-of-callers to build a ranked list by distance.</p>
 
 ---
 
 > *"We're about to merge a PR that touches `validateCart`. Give me an impact report — what's the worst case if this function throws."*
 
-The agent calls `flowmap_get_flow("validateCart", workspacePath)` to map every function reachable downstream, then `flowmap_get_callers("validateCart", workspacePath)` to map every upstream caller.
+<p>The agent calls `flowmap_get_flow("validateCart", workspacePath)` to map every function reachable downstream, then `flowmap_get_callers("validateCart", workspacePath)` to map every upstream caller.</p>
 
 ---
 
@@ -141,13 +141,13 @@ The agent calls `flowmap_get_flow("validateCart", workspacePath)` to map every f
 
 > *"Which functions in this codebase are architectural nasty-surprises — called by everything but calling a lot themselves. I want names, file paths, and exact counts."*
 
-The agent calls `flowmap_analyze_workspace(workspacePath)` to get the full graph, then filters for nodes with high in-degree (many callers) and high out-degree (many callees). These are the structural chokepoints — functions where a bug propagates in both directions. Returned with exact counts. No approximation.
+<p>The agent calls `flowmap_analyze_workspace(workspacePath)` to get the full graph, then filters for nodes with high in-degree (many callers) and high out-degree (many callees). These are the structural chokepoints — functions where a bug propagates in both directions. Returned with exact counts. No approximation.</p>
 
 ---
 
 > *"Find every cycle in the call graph. For each one tell me which file I should break the dependency in to resolve it cleanly."*
 
-The agent calls `flowmap_find_cycles(workspacePath)`. Each cycle is returned as an ordered list of functions with file paths and the exact call edges forming the loop — no post-processing needed. Because the graph is exact, cycle membership is exact — not a guess about which modules "seem" circular.
+<p>The agent calls `flowmap_find_cycles(workspacePath)`. Each cycle is returned as an ordered list of functions with file paths and the exact call edges forming the loop — no post-processing needed. Because the graph is exact, cycle membership is exact — not a guess about which modules "seem" circular.</p>
 
 ---
 
@@ -155,7 +155,7 @@ The agent calls `flowmap_find_cycles(workspacePath)`. Each cycle is returned as
 
 > *"I want to delete code safely. Give me every function that is provably unreachable — not called by anything, not an entry point. Include file and line number."*
 
-The agent calls `flowmap_find_orphans(workspacePath)`. This returns every function not reachable from any entry point in the call graph — with file path and line number for each one. 
+<p>The agent calls `flowmap_find_orphans(workspacePath)`. This returns every function not reachable from any entry point in the call graph — with file path and line number for each one.</p>
 
 ---
 
@@ -163,7 +163,7 @@ The agent calls `flowmap_find_orphans(workspacePath)`. This returns every functi
 
 > *"I just joined this team. Walk me through this codebase starting from the entry points — explain each major flow in plain English without me having to read a single file."*
 
-The agent calls `flowmap_list_entry_points(workspacePath)` to find every main, route handler, CLI command, and React root. Then it calls `flowmap_get_flow` on each one to trace the execution.
+<p>The agent calls `flowmap_list_entry_points(workspacePath)` to find every main, route handler, CLI command, and React root. Then it calls `flowmap_get_flow` on each one to trace the execution.</p>
 
 ---
 
@@ -171,7 +171,7 @@ The agent calls `flowmap_list_entry_points(workspacePath)` to find every main, r
 
 > *"I want to extract the payment logic into its own module. Based purely on call relationships, which functions naturally belong together and which ones would need to stay behind."*
 
-The agent calls `flowmap_analyze_workspace(workspacePath)` and uses the graph to find the connected component of functions reachable from payment-related entry points. 
+<p>The agent calls `flowmap_analyze_workspace(workspacePath)` and uses the graph to find the connected component of functions reachable from payment-related entry points.</p>
 
 ---
 
@@ -179,13 +179,13 @@ The agent calls `flowmap_analyze_workspace(workspacePath)` and uses the graph to
 
 > *"Cursor just made changes across 14 files. Based on what it touched, what else in the codebase should I be nervous about that it didn't touch."*
 
-The agent calls `flowmap_get_callers` for each modified function and `flowmap_get_flow` for each modified function. The union of those results — minus the files already touched — is the set of functions that depend on the changes but weren't updated. These are the places where silent breakage is most likely. Returned as a precise list, not a guess about what "might be related".
+<p>The agent calls `flowmap_get_callers` for each modified function and `flowmap_get_flow` for each modified function. The union of those results — minus the files already touched — is the set of functions that depend on the changes but weren't updated. These are the places where silent breakage is most likely. Returned as a precise list, not a guess about what "might be related".</p>
 
 ---
 
 ### Agentic code generation with structural guardrails
 
-When an agent is generating new code, it can call `flowmap_analyze_workspace` before and after to verify:
+<p>When an agent is generating new code, it can call `flowmap_analyze_workspace` before and after to verify:</p>
 - New functions are connected to the call graph (not accidentally orphaned)
 - No existing entry points were broken
 - The intended call relationships were actually created
@@ -196,9 +196,9 @@ When an agent is generating new code, it can call `flowmap_analyze_workspace` be
 
 > *"We've been using an AI agent to build this codebase for 3 months. How much logic has it silently duplicated?"*
 
-Agents optimize for the current instruction, not long-term architecture. It copies, tweaks slightly, and moves on. It satisfied the local goal.
+<p>Agents optimize for the current instruction, not long-term architecture. It copies, tweaks slightly, and moves on. It satisfied the local goal.</p>
 
-The agent calls `flowmap_find_duplicates(workspacePath)`. Each cluster in the result is a group of functions with different names — often in different components — that call the same set of dependencies. 
+<p>The agent calls `flowmap_find_duplicates(workspacePath)`. Each cluster in the result is a group of functions with different names — often in different components — that call the same set of dependencies.</p>
 
 ---
 
@@ -206,7 +206,7 @@ The agent calls `flowmap_find_duplicates(workspacePath)`. Each cluster in the re
 
 > *"The agent has been adding features for weeks. Are there any circular call dependencies I should know about before this becomes a production problem?"*
 
-The agent calls `flowmap_find_cycles(workspacePath)`. Every cycle is returned with the exact functions involved.
+<p>The agent calls `flowmap_find_cycles(workspacePath)`. Every cycle is returned with the exact functions involved.</p>
 
 ---
 
@@ -218,7 +218,7 @@ The agent calls `flowmap_find_cycles(workspacePath)`. Every cycle is returned wi
 4. Entry points are detected: functions that are never called but call others
 5. The graph is partitioned into independent execution flows via BFS from each entry point
 
-Files are parsed in parallel batches of 50. Results are cached for 30 seconds — repeated calls within a session are instant.
+<p>Files are parsed in parallel batches of 50. Results are cached for 30 seconds — repeated calls within a session are instant.</p>
 
 ---
 
@@ -231,4 +231,4 @@ Files are parsed in parallel batches of 50. Results are cached for 30 seconds
 
 ## License
 
-MIT
+<p>MIT</p>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "callgraph-mcp",
-  "version": "1.4.3",
+  "version": "1.4.4",
   "description": "MCP server for codebase call-flow analysis. Local, deterministic, language-agnostic. Powered by @codeflow-map/core.",
   "keywords": [
     "mcp",