ReachScan – MCP 서버 및 AI 에이전트에 대한 정적 연결 가능성 분석

Static capability analysis for Python and TypeScript/JavaScript AI code. Know what it can do before it does it. You're giving an LLM tools. Tools mean real-world access — files, shell, network, credentials. Most developers add tools without a clear accounting of what permissions they're actually granting. The agent docs tell you what the tool is for. They don't tell you what it can do. reachscan is the accounting. It analyzes Python and TypeScript/JavaScript code and reports the actual capabilities present: what the code can read, write, execute, send, and access. Not what the README says. What the code does. Seven capability classes, built from AST analysis and pattern matching: | Capability | What it means | |---|---| EXECUTE | Shell commands, subprocess, OS exec APIs | READ | Local file reads, path traversal | WRITE | File creation, modification, deletion | SEND | Outbound HTTP, websockets, raw sockets | SECRETS | Env vars, credential managers, secret stores | DYNAMIC | eval, exec, dynamic imports | AUTONOMY | Background tasks, schedulers, self-directed execution | Cross-capability risks are also flagged — READ + SEND detected together raises a data exfiltration flag. SECRETS + SEND raises a credential leak flag. Knowing a capability exists in a codebase is useful. Knowing whether the LLM can actually trigger it is what matters. reachscan detects the LLM-facing entry points in your codebase, builds an intra-project call graph, and traces which capabilities are reachable from those entry points. Every finding is tagged with one of five states: | State | Meaning | |---|---| reachable | Confirmed on a call path from an LLM entry point | unreachable | Exists in the codebase, not on any LLM call path | module_level | Runs on import — executes when the module loads, not via a function call | unknown | Inside code that can't be statically resolved (dynamic dispatch, parse failure) | no_entry_points | No entry points detected — full reachability analysis not possible | The call graph follows up to 8 hops from each entry point. Call paths are shown in the report so you can see exactly how the LLM reaches a capability. reachscan recognises LLM-callable functions across all major Python agent frameworks: | Framework | Detection pattern | |---|---| | Pydantic AI | @agent.tool , @agent.tool_plain | | LangChain / CrewAI | @tool , class MyTool(BaseTool) | | OpenAI Agents SDK | @function_tool | | MCP (Python SDK / FastMCP) | @mcp.tool() , @server.tool() | | MCP (lowlevel server API) | @app.call_tool() , @app.list_tools() | | Semantic Kernel | @kernel_function | | AutoGen | @register_for_llm | Framework attribution uses a confidence-graded resolution chain: direct imports are resolved at 0.95 confidence, inferred instance variables (e.g. weather_agent = Agent[Deps, T](...) ) at 0.80, and unresolvable decorator names fall back to the best available label at 0.60. Python entry points feed into the reachability pass — the call graph is traced from each detected entry point to identify which capabilities the LLM can actually trigger. reachscan scans .ts , .js , .mts , .mjs , .cts , and .cjs files using regex-based pattern matching. No Node.js runtime is required. | Pattern | What it detects | Confidence | |---|---|---| mcp_tool | server.tool("name", schema, handler) — MCP SDK | 0.95 | mcp_tool | server.registerTool("name", schema, handler) — MCP SDK v1.6+ | 0.95 | mcp_tool | server.addTool({ name: "...", ... }) — FastMCP | 0.90 | mcp_tool_definition | { name: "...", description: ..., inputSchema: ... } objects | 0.85 | langchain_tool | new DynamicTool({ name: "...", ... }) | 0.85 | mcp_handler | server.setRequestHandler(Schema, ...) | 0.80 | Both same-line and multi-line registration styles are handled for each pattern. Declaration files (.d.ts ), test files, minified bundles, and node_modules /dist /build directories are automatically excluded. Current limitation: TypeScript and JavaScript function bodies are not capability-analyzed — only entry points are detected. When a project mixes Python and TypeScript, capability findings come from the Python side and TypeScript entry points are listed separately in the report. Agent Capability Report ======================= Python Entry Points (LLM-controlled surface) ---------------------------------------------- • get_lat_lng (pydantic_ai/decorator @ weather_agent.py:50) • get_weather (pydantic_ai/decorator @ weather_agent.py:67) Capabilities ------------ • SEND Combined Risks -------------- None inferred from combined-capability rules. Reachability Summary -------------------- 3 reachable — LLM can trigger these directly 117 unreachable — exist in codebase, not on any LLM call path 3 module-level — execute on import, not on any call path Reachable Findings — LLM can trigger these directly ------------------------------------------------------ [HIGH] SEND via ctx.deps.client.get -> https://api.weather.example.com (network @ weather_agent.py:58) path: get_lat_lng explanation: This