MCP dependency mapping

MCP configuration lives in config files, but the things that actually consume a server (an agent's tool list, a workflow's startup script, a teammate's local dev setup) don't live next to that config. As a team adds servers across repositories, nobody keeps a map of server to consumer by hand, and the config file itself only tells you a server exists, not who relies on it.

A single MCP server can be referenced from multiple repositories under different names, authorized by a credential declared in a completely different file, and consumed by an agent definition that imports it indirectly through a framework (LangChain, CrewAI, the Anthropic or OpenAI Agents SDKs) rather than naming it directly. Grepping for a server name finds the config; it doesn't find every consumer, and it can't tell you whether a match is a real dependency or a stale comment.

Wirecheck parses mcp.json and claude_desktop_config.json as first-class MCP server configuration (stdio, HTTP, and SSE transports), links each server to the credential that authorizes it, and resolves consumers through SDK/framework imports (@modelcontextprotocol/*, OpenAI SDK, Anthropic SDK, LangChain, Vercel AI SDK, CrewAI, AutoGen, Mastra, OpenAI Agents SDK), webhooks, cron, GitHub Actions, and REST/database references. A credential or server referenced by name across multiple connected repositories is merged into one node, so cross-repo usage shows up as one dependency graph, not N separate ones. See Supported detections for the current coverage and its limits.

wirecheck impact zendesk-mcp --json

Returns the component, its known consumers, and any relationship Wirecheck couldn't resolve:

{
  "component": { "name": "zendesk-mcp", "type": "MCP_SERVER", "confidence": "HIGH" },
  "direct_dependants": 3,
  "indirect_dependants": 1,
  "orphaned_integrations": 0,
  "unknown_relationships": 1,
  "direct": [{ "name": "support-bot", "type": "AGENT", "confidence": "HIGH" }]
}

Every edge in the map traces back to a repository, file, and line, with a confidence level, not just a name match. That evidence is what a wirecheck evidence call returns, and it is what the agent workflow commands build on.

A deterministic pass can miss a consumer that references a server through dynamic configuration, an uncommon framework, or a naming convention Wirecheck doesn't yet recognize. Those show up as UNKNOWN rather than being silently dropped, and an LLM classifier only resolves genuinely ambiguous cases, never fabricates a relationship a deterministic pass didn't find.