The Agent Context MCP Server provides a portable, local memory and code structure graph for agentic AI coding tools, enabling context persistence and codebase analysis across sessions and tools.
Working Context Management
Create tasks – Start a new working context task tracked by a unique task ID
Log progress – Append progress entries of types: step_done, error_hit, next_step, or note
Log decisions – Record technical decisions with reasoning and optional code symbol references
Manage open questions – Add and resolve open questions during development
Resume work – Retrieve the full state of an active task (progress, decisions, questions) to pick up where you left off
List tasks – View all tasks filtered by status: active, done, blocked, or abandoned
Code Structure Graph
Index files – Parse Python, JavaScript, and TypeScript files using tree-sitter to extract classes, functions, and methods locally, with incremental indexing via content-hashing
Look up symbols – Retrieve a specific symbol's file path and line numbers
Trace call chains – Follow inbound or outbound function call relationships for a given symbol within a file
Get architecture overview – View a high-level summary of the parsed codebase including files, symbol counts, and entry points
Project Lifecycle
Export project context – Create a compressed zip backup of the entire .agentctx/ directory for storage or sharing
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 MCP Server resume my last task"
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.
A portable, tool-agnostic memory and code structure graph for agentic AI coding tools (OpenCode, Antigravity, Claude Code, etc.).
Agentic AI tools typically keep their memory locked inside a single session. When you run out of context tokens or switch to a different AI tool, you lose:
What you were currently working on (tasks, pending steps).
Why past technical decisions were made.
The structural architecture of the codebase.
Related MCP server: Memory MCP
The Agent Context Server is an MCP (Model Context Protocol) server that tracks working context and code structure in a lightweight, local SQLite database (.agentctx/context.db). It provides a single, portable memory that follows the project rather than the tool.
You can start a task in one AI tool, hit a context limit, open a completely different AI tool, and resume exactly where you left off.
Working Context Engine: Tracks active tasks, decisions, progress logs, and open questions across sessions.
Code Structure Graph: Uses tree-sitter to parse and map Python, JavaScript, and TypeScript files, extracting classes, functions, and methods without sending your code to external APIs.
Incremental Indexing: Smart content-hashing ensures only modified files are re-indexed.
Project Export: Built-in tools to instantly zip and backup your agent's memory state.
Fully Local & Private: No LLM calls inside the server; all state is kept entirely locally via SQLite.
uv (Fast Python package and project manager)
Clone this repository to your machine:
git clone (replace with your own repo URL once you push this to GitHub)
cd agent-context-mcp-serverThe project uses uv for dependency management. The required packages (mcp, tree-sitter, tree-sitter-python, tree-sitter-javascript, tree-sitter-typescript) will be automatically managed when you run the server.
To use this server with your preferred agentic AI tool (like Google Antigravity, OpenCode, or Claude Code), add the following to your MCP configuration settings:
{
"mcpServers": {
"agent-context-server": {
"command": "uv",
"args": [
"--directory",
"/absolute/path/to/agent-context-mcp-server",
"run",
"server.py"
]
}
}
}Note: Replace
/absolute/path/to/agent-context-mcp-serverwith the actual path where you cloned this repository. The server will dynamically create the.agentctx/directory in whatever project folder your AI agent is currently working in.
Once connected, your AI agent will have access to the following tools:
start_task(title): Creates a new working context task.
log_progress(task_id, entry, entry_type): Appends a progress log (step_done, error_hit, next_step, note).
log_decision(task_id, decision, reason, symbol_ref): Logs technical decisions and the reasoning behind them.
add_question(question) / resolve_question(question_id): Manages open questions.
resume(task_id?): Retrieves the full state of the active task to seamlessly pick up work.
list_tasks(status?): Lists active, done, blocked, or abandoned tasks.
graph.index(path, languages?): Parses a file (.py, .js, .ts, .jsx, .tsx) and extracts structural symbols.
graph.get_symbol(name): Retrieves a specific symbol's file path and line numbers.
graph.trace_calls(symbol_name, direction): Traces inbound or outbound function calls within the same file.
graph.get_architecture(): Returns a high-level overview of the parsed codebase, including files, symbol counts, and root entry points.
project.export(): Zips the entire .agentctx/ directory for safe backup and sharing.
MIT License
Adds an unresolved open question to the context.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It only implies mutation ('adds') but does not disclose side effects, idempotency, return value, or state changes. No mention of whether adding duplicates is allowed or what context means.
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?
Extremely short, but under-specified. A single sentence lacks crucial details; it sacrifices informativeness for brevity. Could be expanded slightly without losing 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?
Given the tool's simplicity (one parameter, no annotations), the description is borderline adequate. However, it does not mention output schema (which exists) or clarify how the added question interacts with other tools like 'resolve_question'. Missing behavioral context lowers 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?
Schema coverage is 0%, so description must explain the 'question' parameter. It does not specify format, length constraints, examples, or expected content (e.g., natural language vs structured). The word 'question' is reused without added meaning.
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 ('adds') and the resource ('an unresolved open question to the context'). It distinguishes from sibling tools like 'resolve_question' by specifying 'unresolved'. However, 'context' is vague and could be more specific.
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 'resolve_question' or 'log_decision'. There is no mention of prerequisites, order of operations, or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a basic high-level overview of the parsed codebase, including files, symbol counts, and entry points.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description implies a read-only operation ('Returns') but does not explicitly state non-destructiveness, side effects, or permissions. With no annotations, the description should carry this burden but falls short.
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?
Single, clear sentence front-loading the purpose and key outputs. No wasted words.
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?
Tool has no parameters and an output schema exists (not shown). Description explains return content adequately for a simple overview tool. However, it lacks detail on scope (e.g., entire codebase vs subset) and does not clarify relationship to siblings like graph.index.
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?
Input schema has no parameters (100% coverage implicitly). Description adds no extra parameter context because none exist. Baseline for zero-param tools is 4, but description could clarify why no parameters are needed (e.g., 'Always returns the full codebase overview'). It does not, so 3 is appropriate.
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?
Description clearly states the tool returns a high-level overview of the parsed codebase, listing specific content (files, symbol counts, entry points). It distinguishes from siblings like graph.get_symbol by indicating it is high-level rather than detailed.
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 (e.g., graph.get_symbol). No explicit context or prerequisites given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves a symbol's info, file, and line numbers from the database.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral transparency. It states 'retrieves' (implying read-only) and mentions 'from the database,' but does not disclose permissions, side effects, or the nature of the returned data beyond basic fields. The agent is left to assume safety and 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 no unnecessary words. It is efficiently structured for quick comprehension. However, it lacks any structural elements like examples or parameter definitions that could enhance clarity without increasing verbosity significantly.
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 a single required parameter and an output schema, the complexity is low. The description mentions what data is returned (info, file, line numbers), which is helpful. But it omits parameter semantics and any edge-case behavior. It is adequate but not thorough for a tool with zero schema descriptions.
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 has 0% property descriptions, so the description should compensate. It only says 'retrieves a symbol's info' without explaining what the required 'name' parameter represents (symbol name? file path?). The output schema exists but is not referenced. Minimal value added beyond the schema itself.
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 retrieves a symbol's info, file, and line numbers. The verb 'retrieves' and the specified data types make the purpose clear. However, it does not explicitly differentiate from sibling tools like graph.trace_calls or graph.get_architecture, though the resource (symbol) is distinct.
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, limitations, or recommended scenarios. The description lacks any contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parses a given file path and saves the extracted symbols to the symbols table.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| languages | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions parsing and saving, implying mutation, but does not disclose whether existing symbols are overwritten or appended, error conditions, or authorization needs. With no annotations, the description bears full responsibility but falls short.
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 conveys the core purpose without unnecessary words. However, it could be slightly more structured to include guidance or parameter hints.
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 minimal for a tool with two parameters and an output schema. It does not explain what the output schema contains, side effects, or how it relates to sibling tools, leaving gaps for the 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?
The description only clarifies the 'path' parameter by mentioning 'file path'. The 'languages' parameter is not explained at all, and no valid values or default behavior are described. Given 0% schema coverage, more detail is needed.
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: parsing a file path and saving extracted symbols to a symbols table. It uses specific verbs and nouns (parse, saves, extracted symbols) and distinguishes itself from sibling tools like graph.get_symbol or graph.trace_calls by focusing on indexing.
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. It does not specify prerequisites, limitations, or contexts where it is appropriate, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the inbound or outbound call chain for a given symbol. direction: 'inbound' or 'outbound'
| Name | Required | Description | Default |
|---|---|---|---|
| direction | Yes | ||
| symbol_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, yet it only states it 'returns' the call chain. It does not mention side effects, permissions, rate limits, or the structure of the output, leaving the agent with minimal behavioral context.
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 very short and front-loaded, but it is overly concise, lacking necessary elaboration. It earns its place but 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 tool has an output schema and two required parameters, the description is incomplete. It does not explain return values or provide enough context for correct usage. The lack of behavioral detail and parameter guidance makes it insufficient for a well-informed tool 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?
Schema description coverage is 0%, so the description must compensate. It mentions 'direction: inbound or outbound' but does not explain what these mean, nor does it define 'symbol_name'. The description adds very little meaning beyond the 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 the tool returns the inbound or outbound call chain for a given symbol, with a specific verb ('Returns') and resource ('call chain'). It distinguishes from sibling tools like graph.get_architecture and graph.get_symbol, which have different purposes.
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 mentions the direction parameter with 'inbound' or 'outbound' values, implying usage, but does not explain when to use each direction or when to choose this tool over siblings. No explicit exclusions or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists tasks, optionally filtered by status (active, done, blocked, abandoned).
| Name | Required | Description | Default |
|---|---|---|---|
| status | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose behavioral traits such as side effects, permissions, rate limits, pagination, or result ordering. Only states it lists tasks, which is minimal for a read operation.
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 a single, well-structured sentence that is concise and front-loaded. However, it could be more informative without adding much length.
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?
With only one optional parameter and an output schema (not shown), the description covers the basic purpose. However, it lacks details on return format, ordering, or any edge cases, making it moderately complete but not fully informative.
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 has 0% description coverage and no enum values. Description adds the allowed status values (active, done, blocked, abandoned), providing essential meaning beyond the 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?
Description clearly states verb 'Lists tasks' and resource, with optional filtering by status. It distinguishes from other tools like add_question or graph.*, but does not explicitly differentiate from any sibling list tools.
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. It only says tasks can be filtered, but does not mention prerequisites, when not to use, or recommend other tools for different needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Logs a technical decision with its reason to the context.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | Yes | ||
| task_id | Yes | ||
| decision | Yes | ||
| symbol_ref | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral traits such as persistence, authorization needs, or side effects. The phrase 'to the context' is vague and does not clarify whether the log is ephemeral or stored.
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 and front-loaded with the core purpose.
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 4 parameters (3 required, 1 optional), no schema descriptions, and no annotations, a single sentence is insufficient. The description does not address the output schema or the meaning of 'context'. It lacks completeness for effective use.
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 provides no additional meaning for any of the 4 parameters (task_id, decision, reason, symbol_ref). It does not explain what each parameter represents or how to use them, especially the optional symbol_ref.
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 logs a technical decision with its reason to the context. The verb 'logs' and resource 'technical decision' provide specific purpose. It is distinguishable from sibling tools like add_question or log_progress which have different actions.
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 not to use it, or how it differs from similar tools like log_progress or add_question.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Appends a progress log entry to the task.
Valid entry_type values: step_done, error_hit, next_step, note
| Name | Required | Description | Default |
|---|---|---|---|
| entry | Yes | ||
| task_id | Yes | ||
| entry_type | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description mentions 'appends' but does not disclose side effects, idempotency, or other behavioral traits beyond the basic action.
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?
Two sentences, no redundancy, directly communicates purpose and valid values. Efficient.
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?
Covers basic purpose and parameter constraints for entry_type, but lacks usage guidelines and behavioral details. Adequate for a simple tool.
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%. The description adds valid entry_type values but does not explain task_id or entry parameters, relying on schema field 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?
Clearly states the tool appends a progress log entry, with valid entry_type values listed. However, it does not differentiate from sibling tool log_decision.
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 log_progress versus alternatives like log_decision or other tools. The description only states what the tool does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a compressed zip backup of the entire .agentctx/ directory.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It states the outcome (zip backup) but omits behavioral details: destructiveness (does it modify the directory?), permissions needed, error handling, or side effects like overwriting existing backups. Very limited transparency.
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?
Single sentence that is front-loaded and direct. No wasted words; every word contributes to conveying the tool's purpose 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 presence of an output schema, return values need not be explained. However, the description lacks broader context like naming convention of the zip, storage location, or expectations about .agentctx/ directory state. Adequate but not rich.
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 zero parameters, so schema coverage is 100% and the description naturally doesn't add parameter info. Per guidelines, baseline is 4 for 0-param tools, and the description does not contradict or miss any required semantics.
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 explicitly states the action ('creates a compressed zip backup') and the specific resource ('entire .agentctx/ directory'). It clearly differentiates from sibling tools like 'add_question' or 'graph.get_architecture' by being the only backup/export tool.
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 over alternatives, no prerequisites, no mention of when not to use it. The description is purely functional without context on ideal usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Marks an open question as resolved.
| Name | Required | Description | Default |
|---|---|---|---|
| question_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states it marks as resolved, but lacks details on reversibility, permissions, side effects, or return 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?
Single sentence, front-loaded, no unnecessary words. Efficient for a simple mutation.
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?
Despite having an output schema, description does not explain return values. For a simple tool, it could include confirmation or error information. Incomplete.
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?
With 0% schema description coverage, the tool description should elaborate on question_id but does not. The param name is self-explanatory, but no format, example, or validation hints provided.
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 ('Marks as resolved') and the resource ('open question'), distinguishing it from siblings like add_question or log_decision.
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, no prerequisites or conditions mentioned. Usage is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the full state of a task (or the most recent active one if not provided):
active task details, recent progress, decisions, and open questions.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return content (active task details, progress, decisions, open questions) and the fallback behavior. Without annotations, it adequately covers the read-only nature and scope, though it does not mention error conditions or performance characteristics.
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 that efficiently conveys purpose and key details. Every element earns its place, with no wasted words.
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 simple one-parameter read tool with an output schema, the description is largely complete. It specifies the return contents and fallback behavior, though it could mention error cases or authentication requirements for full 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?
Despite 0% schema description coverage, the description fully explains the single parameter's behavior: if task_id is provided, returns that task's state; if omitted, returns the most recent active task. This adds crucial meaning beyond the schema's nullable string.
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 the full state of a task, listing specific components (active task details, progress, decisions, open questions). It distinguishes from siblings like list_tasks by specifying 'full state' and including the fallback to the most recent active task.
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 implies when to use this tool (when needing a detailed task state) and implicitly contrasts with lighter alternatives. However, it lacks explicit guidance on when not to use it or direct references to sibling tools, which would make it clearer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new working context task and returns the task ID.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It only states it creates a task, without mentioning side effects, auth requirements, or idempotency. Minimal disclosure for a mutation tool.
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?
Single sentence, 10 words, front-loaded with verb. Efficient and to the point, though slightly terse.
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 one parameter and an output schema, the description covers the basic purpose but lacks details on context needed, such as whether the task is immediately usable or any constraints on the title.
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%, yet the description does not explain the single parameter 'title' beyond what the schema provides. The description adds no semantic value to the parameter.
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 verb 'creates', the resource 'working context task', and the result 'returns the task ID'. It distinguishes from sibling tools like list_tasks or log_progress by focusing on creation.
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 does not mention prerequisites, when not to use, or suggest other tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0add_questiongraph.get_architecturegraph.get_symbolgraph.indexgraph.trace_callslist_taskslog_decisionlog_progressproject.exportresolve_questionresumestart_taskTools are clearly separated into graph analysis (graph.*) and context management (add_question, log_decision, etc.), each with distinct purposes. No overlap between tools.
Uses a mix of plain snake_case (add_question, list_tasks) and dotted hierarchical names (graph.get_architecture, project.export). Consistent within subgroups but inconsistent across the whole set.
12 tools cover the main functionalities of code graph analysis and task/context management without being excessive. Well-scoped for the server's domain.
Core operations are present but missing lifecycle actions: no update/delete for tasks, decisions, or questions. Graph tools lack search or listing capabilities.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Give your AI agent a persistent map of your project's structure, dependencies, and bugs.
Project memory, semantic code search, and grounded agent context.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Project memory for coding agents: requirements, decisions, code graph and delivery telemetry.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Arunavo-ProjectIdea/Agent-Context-MCP-Server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server