🚀 NEW: Build dependency graph for the entire codebase. Call this once after indexing to enable smart context features. Required for get_function_with_context and get_dependency_tree to work.
AI agents invoke build_dependency_graph to trigger actions in MCP Context Manager. What it does depends on the arguments the agent supplies, and its effects often reach beyond the immediate call — builds kicked off, notifications sent, workflows started.
This tool triggers a processing/analysis operation across the entire codebase to construct and store a dependency graph. It is not a passive read — it actively builds and persists graph data, and enables other features. It runs an operation whose effects (populating the graph) depend on the codebase contents, making it Execute rather than a simple Read.
From the tool's definition 'Build dependency graph for the entire codebase' and 'Call this once after indexing to enable smart context features. Required for get_function_with_context and get_dependency_tree to work.'
Risk signalsBulk/mass operation — affects multiple targets
Documented attack patterns abuse exactly the kind of access build_dependency_graph gives an agent:
PolicyLayer is an MCP gateway — it sits between your AI agents and MCP Context Manager, and nothing reaches the server without passing your rules. This is the rule we recommend for build_dependency_graph:
{
"version": "1",
"default": "deny",
"tools": {
"build_dependency_graph": {
"limits": [
{
"counter": "build_dependency_graph_rate",
"window": "minute",
"max": 10,
"scope": "grant"
}
]
}
}
}build_dependency_graph stays usable, but rate-capped — a runaway agent can't fire it dozens of times a minute. Everything else on the server is denied unless you say otherwise.
Free to start. No card required.
🚀 NEW: Build dependency graph for the entire codebase. Call this once after indexing to enable smart context features. Required for get_function_with_context and get_dependency_tree to work. It is categorised as a Execute tool in the MCP Context Manager MCP Server, which means it can trigger actions or run processes. Use rate limits and argument validation.
Register the MCP Context Manager MCP server in PolicyLayer and add a rule for build_dependency_graph: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches MCP Context Manager. Nothing to install.
build_dependency_graph is a Execute tool with high risk. Execute tools should be rate-limited and have argument validation enabled.
Yes. Add a rate_limit block to the build_dependency_graph rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for build_dependency_graph. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
build_dependency_graph is provided by the MCP Context Manager MCP server (transparentlyok/mcp-context-manager). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
Start from MCP Context Manager, add the rest of your stack, and see everything your agents can call. Then put policy on all of it.
Free to start. No card required.
21 MCP Context Manager tools catalogued and risk-classified — across an index of 43,000+ MCP servers.