Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@agent-context-graph Show blast radius for the User model"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
agent-context-graph is a local MCP server for AI coding agents. It helps tools such as Antigravity, Codex, Claude Code, and Cursor understand a project before editing it.
It provides:
a local code knowledge graph
scope checks before file edits
append-only reasoning logs
local best-practice notes for testing, security, APIs, auth, and architecture
Everything runs on your machine. There is no SaaS backend, telemetry, analytics, GitHub API call, or runtime network call.
flowchart LR
App["Your project"] --> MCP["agent-context-graph MCP server"]
Antigravity["Antigravity"] --> MCP
Codex["Codex"] --> MCP
Claude["Claude Code"] --> MCP
Cursor["Cursor"] --> MCP
MCP --> Graph["Graph JSONL"]
MCP --> Logs["Reasoning logs"]
MCP --> Scope["Scope lock"]Node.js 20 or newer
npm
Git
Windows, macOS, or Linux
Related MCP server: codeweave-mcp
Clone this tool anywhere convenient, not inside every app project but in user-profile for global access
git clone https://github.com/Raviraj2024/Agent-Context-Graph.git
cd Agent-Context-Graph
npm install
npm run build
npm test
npm linkAfter npm link, this command should work from any folder:
agent-context-graph statusRecommended folder layout:
Projects/
Agent-Context-Graph/ # this tool
my-app/ # your real projectGo to the project you want an AI tool to work on:
cd /path/to/my-app
agent-context-graph init
agent-context-graph statusThis creates:
my-app/
.agent-context-graph/
config.json
graph/
logs/Run agent-context-graph init once per project.
Use Antigravity's MCP config format:
{
"mcpServers": {
"agent-context-graph": {
"command": "agent-context-graph",
"args": ["serve"],
"env": {
"AGENT_CONTEXT_GRAPH_ROOT": "/absolute/path/to/my-app"
}
}
}
}Windows example[RECOMMENDED]:
{
"mcpServers": {
"agent-context-graph": {
"command": "agent-context-graph",
"args": ["serve"],
"env": {
"AGENT_CONTEXT_GRAPH_ROOT": "C:/Users/<USER-PROFILE>/.../my-app"
}
}
}
}If you do not use npm link, use Node directly:
{
"mcpServers": {
"agent-context-graph": {
"command": "node",
"args": [
"C:/Users/<USER_PROFILE>/agent-context-graph/dist/bin/agent-context-graph.js",
"serve"
],
"env": {
"AGENT_CONTEXT_GRAPH_ROOT": "C:/Users/<USER-PROFILE>/.../my-app"
}
}
}
}Restart Antigravity after saving the MCP config.
Inside your target project, run only the command for the platform you use:
agent-context-graph connect codex
agent-context-graph connect claude-code
agent-context-graph connect cursorThese commands write project-local MCP config files:
Codex: .codex/config.toml
Claude Code: .claude/mcp.json
Cursor: .cursor/mcp.json
Use this kind of prompt in Antigravity or any other coding agent:
Use the agent-context-graph MCP server before editing.
First inspect the project graph, refresh it, query relevant best practices,
declare the task scope, check scope before edits, and record every change.
Before your final answer, run the actual app/test command yourself.
If the command fails because a dependency is missing, fix it if safely in scope
or report the exact blocker. Do not give me an untested run command.
Now implement: <your task>The MCP server tells the agent to:
inspect the project graph
refresh stale graph data
read relevant best-practice notes
declare what files or nodes it plans to change
check scope before every write
ask the user before sensitive or out-of-scope edits
record each change with reasoning
run the real app/test command before final response
The server cannot force every AI platform to obey, but these instructions are exposed through MCP so the agent can follow them automatically.
agent-context-graph init
agent-context-graph status
agent-context-graph serve
agent-context-graph reset
agent-context-graph connect codex
agent-context-graph connect claude-code
agent-context-graph connect cursorinit: build the graph for the current project
status: show graph/cache status
serve: start the MCP server
reset: rebuild the local SQLite cache
connect: add MCP config for a supported client
The server exposes these tools:
get_project_overview
init_or_refresh_graph
get_node_context
get_blast_radius
get_definitive_path
query_best_practices
declare_task_scope
check_scope
record_change
get_node_history
Commit these files from your target project:
.agent-context-graph/config.json
.agent-context-graph/graph/nodes.jsonl
.agent-context-graph/graph/edges.jsonl
.agent-context-graph/logs/*.jsonl
.agent-context-graph/change-index.jsonIgnore these files:
.agent-context-graph/cache.sqlite
.agent-context-graph/cache.sqlite-*
.agent-context-graph/.lockCurrent indexing support:
TypeScript and TSX
JavaScript and JSX
Python
The graph stores signatures, docstrings, line numbers, tags, and hashes. It does not store full source code bodies.
agent-context-graph command not foundRun this from the cloned tool repo:
npm linkOr use the direct Node command shown in the Antigravity setup.
Check this value:
"AGENT_CONTEXT_GRAPH_ROOT": "/absolute/path/to/my-app"It must point to the project you want Antigravity to edit.
Run this inside your target project:
agent-context-graph initRun:
agent-context-graph resetThis only removes the rebuildable SQLite cache. It does not delete graph snapshots or logs.
npm install fails on better-sqlite3Use Node.js 20 or newer. If npm tries to compile better-sqlite3, install your platform's normal C/C++ build tools and rerun:
npm installnpm install
npm run build
npm testMIT
Classify proposed changes against a declared scope.
| Name | Required | Description | Default |
|---|---|---|---|
| scopeId | Yes | ||
| proposedChanges | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says 'classify' without specifying outcome types, side effects, or permissions. Behavioral traits beyond the basic action are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very short but lacks needed detail. While concise, it under-specifies the tool's behavior and parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and the description omits crucial context such as return format, error handling, or preconditions. For a classification tool, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; description does not explain the meaning of scopeId or proposedChanges. No additional semantics beyond parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it classifies proposed changes against a declared scope, using specific verb and resource. However, it doesn't differentiate from sibling tools like get_blast_radius or get_definitive_path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like declare_task_scope or get_blast_radius. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Declare task scope before edits.
| Name | Required | Description | Default |
|---|---|---|---|
| taskDescription | Yes | ||
| targetIdentifiers | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'declare task scope', which hints at a preparatory action, but does not disclose if it modifies state, requires permissions, or has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one short sentence, but it is not well-structured for an AI agent. It lacks any organizational cues or elaboration beyond the bare minimum.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two required parameters and no output schema, the description fails to provide sufficient context for an AI agent to understand the tool's full behavior, return values, or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters. The names 'taskDescription' and 'targetIdentifiers' give hints but lack detail about format, constraints, or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as declaring task scope before edits, which is a clear verb+resource. However, it does not differentiate from sibling tools like check_scope, and the scope of 'task scope' is vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., check_scope). The description implies it should be used before edits, but no exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return reachable nodes through calls/imports/inherits up to maxDepth.
| Name | Required | Description | Default |
|---|---|---|---|
| maxDepth | Yes | ||
| identifier | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool traverses calls, imports, and inherits relationships up to maxDepth, which is transparent. However, it does not mention safety aspects like read-only behavior or potential performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence with no filler, front-loading the key action and result.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two required parameters, no output schema, and no annotations, the description is sparse. It fails to specify the output format, inclusion of starting node, or edge cases. Sibling tools like get_definitive_path suggest more context is needed for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It clarifies that maxDepth limits the traversal depth, but 'identifier' is only implied as a starting node without further detail. This adds minimal meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Return' and the resource 'reachable nodes through calls/imports/inherits', clearly indicating the tool's function. However, it does not explicitly differentiate from sibling tools like get_definitive_path or get_node_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any exclusion criteria or context hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return minimal ordered files/nodes for an intended change.
| Name | Required | Description | Default |
|---|---|---|---|
| changeType | Yes | ||
| identifier | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether the operation is read-only, has side effects, requires specific permissions, or has rate limits. The description only states what it returns, not behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, which is front-loaded. However, it is too terse to be fully informative. It sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and parameter descriptions, the description is incomplete. It does not explain what 'minimal ordered files/nodes' means or how the change type affects the output, leaving the agent without enough context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters (identifier, changeType) or how they affect the result. The description adds no meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'minimal ordered files/nodes for an intended change', specifying both the action and the context. However, the term 'minimal ordered files/nodes' is somewhat ambiguous and does not fully distinguish it from sibling tools like get_node_context or get_blast_radius.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, when to use, or when not to use, despite having sibling tools with overlapping purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a node and its immediate one-hop edges.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the basic function without disclosing whether it is read-only, any authentication requirements, or potential side effects. The description is insufficient for behavioral awareness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and no output schema, the description provides the basic operation. However, the agent likely needs more context (e.g., return format, edge direction) to use it correctly, especially alongside sibling tools. It is minimally complete but not more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds no information about the required 'identifier' parameter. The agent must guess what format or type of identifier is expected (e.g., node ID, name). This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a node and its immediate one-hop edges, specifying both the resource (node and edges) and the scope (one-hop). This distinguishes it from sibling tools like get_blast_radius (multi-hop) and get_definitive_path (pathfinding).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools for graph traversal, the agent would benefit from explicit conditions or exclusions, but none are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return compacted change history for a node or path.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read-only operation but does not disclose what 'compacted' means, whether the operation is destructive, or any other behavioral traits (e.g., rate limits, permissions).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key action and resource. It is efficient but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a retrieval tool. It does not explain what the output looks like, whether results are paginated, or if date ranges apply. Given the lack of output schema, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'identifier' is described as a node or path, adding context beyond the schema's bare type. However, the description does not cover format, constraints, or examples, and schema coverage is 0%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Return') and the resource ('compacted change history for a node or path'), distinguishing it from sibling tools like get_node_context or get_definitive_path. However, it does not explicitly differentiate from other history-related tools if any exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It lacks context such as prerequisites, typical use cases, or suggestions for when to prefer other tools like get_node_context for current state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return root node, detected tech stack, entry points, and graph counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states what is returned. It lacks information on side effects (likely read-only), permissions, rate limits, or any constraints. For a tool with no parameters, more context on its behavior is expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the return values. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is somewhat incomplete. It does not explain what 'graph counts' means or the context of the returned data. Additional context like 'provides a high-level project summary' would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema coverage is 100% (vacuously). The description adds no parameter information since there are none, but the baseline for zero parameters is 4, and it does not detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly lists what the tool returns (root node, tech stack, entry points, graph counts), using a specific verb 'Return'. It distinguishes from sibling tools like 'get_node_context' which focus on individual nodes, but could be more explicit about providing a project-level overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'get_blast_radius' or 'get_node_context'. The description does not mention any prerequisites or context where this tool is most appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build or refresh the project graph.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits, but it only states 'Build or refresh the project graph' without explaining what that entails, side effects, permissions, or state changes. This is a severe omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It earns its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and minimal description, the tool is severely underspecified. An agent cannot determine how the graph is built/refreshed, what inputs are needed, or what the output looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100% by default. The description adds the purpose, which is the only meaningful information for an agent. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Build or refresh') and resource ('project graph'), making the purpose clear. However, it does not differentiate from sibling tools like 'get_project_overview' or 'check_scope', so it loses a point for lack of distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites or conditions mentioned. The agent is left to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return bundled best-practice nodes for a domain.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavioral traits. It merely states it returns nodes, with no mention of side effects, permissions, cost, or failure modes. This is insufficient for an agent to predict behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with 7 words. It is concise and front-loaded, but some might consider it too brief. It earns its place by stating the core action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should provide more context about the return value or behavior. It does not mention if the result is a list, a node ID, or structured data, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only specifies 'domain' as a string with no further constraints. The description adds no additional meaning about valid values, format, or semantics of the domain parameter. With 0% schema description coverage, the tool relies entirely on the description, which is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Return' and specifies the resource 'bundled best-practice nodes' and scope 'for a domain'. However, it does not differentiate this tool from siblings like get_node_context or get_definitive_path, which also return nodes in some sense.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives, nor does it mention any preconditions or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record an actual file mutation immediately after it happens.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| scopeId | Yes | ||
| summary | Yes | ||
| filePath | Yes | ||
| reasoning | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It lacks details on permissions, side effects, or error states. The minimal description conveys only the basic action, leaving behavioral traits largely undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the core purpose. It is appropriately sized but could be slightly expanded to cover key details without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 required parameters and no output schema or annotations, the description is too brief. It fails to explain the return value, state after recording, or how it fits with sibling tools, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 5 parameters. The enum 'action' is not described, and required fields like 'scopeId', 'filePath', 'summary', 'reasoning' are left entirely to the schema without additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records a file mutation immediately after it happens, using a specific verb and resource. It distinguishes from siblings like 'get_node_history' which likely queries historical data. However, it could be more explicit about what constitutes a 'mutation'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'check_scope' or 'get_blast_radius'. The description implies immediate recording after mutation, but doesn't specify prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct operation: scope management, graph queries, best practices, and change recording. No overlapping purposes.
All tool names follow a consistent verb_noun pattern with underscores, using clear verbs like check, declare, get, init, query, record.
10 tools is appropriate for a graph context server, covering initialization, exploration, scope, and recording without being excessive.
The set covers key operations for graph management and change analysis, though missing a direct tool for deleting or updating nodes (but not essential for the stated purpose).
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that gives your AI access to the source code and docs of all public github repos
MCP server for building and testing AI agents with multi-model experimentation and insights.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Raviraj2024/Agent-Context-Graph'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
