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., "@ProjectContext create agenda for homepage redesign"
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.
Improved Successor of AgentMemory
A high-performance MCP (Model Context Protocol) server providing long-term memory storage with semantic and keyword search capabilities, along with a structured agenda engine for task management.
Fast Semantic Search: Uses fastembed with BAAI/bge-small-en-v1.5 for fast startup and low memory usage
Hybrid Search: Combines keyword (FTS5) and vector search using Reciprocal Rank Fusion (RRF)
Agenda Engine: Task management with full-text search for plans and todo lists
MCP Prompts: Specialized workflows for onboarding, feature planning, and memory maintenance
Persistent Storage: SQLite-based storage with sqlite-vec extension
Sub-200ms Queries: Keeps embedding model in memory for fast response times
MCP Native: Exposes tools, resources, and prompts natively for AI agents
Related MCP server: elephantasm-mcp
# Clone the repository
git clone <repo-url>
cd projectcontext
# Install dependencies with uv
uv sync
# Or install globally
uv pip install -e .# Run directly
projectcontext
# Or with uv
uv run projectcontextAdd to your MCP client configuration (e.g., mcp.json):
{
"mcpServers": {
"projectcontext": {
"command": "uv",
"args": ["run", "projectcontext"],
"cwd": "/path/to/projectcontext"
}
}
}Or using the installed script:
{
"mcpServers": {
"projectcontext": {
"command": "projectcontext"
}
}
}save_memory: Save a memory with category, topic, and content.
query_memory: Search memories using hybrid semantic/keyword search.
update_memory: Modify an existing memory by ID.
delete_memory: Remove a memory by ID.
create_agenda: Create a new multi-step plan or todo list.
list_agendas: Show all active or inactive agendas.
get_agenda: Retrieve detailed task information for a specific agenda.
search_agendas: Search plans by title or description.
update_task: Mark tasks as completed or pending.
update_agenda: Modify agenda metadata or add new tasks.
delete_agenda: Remove inactive agendas.
projectcontext://usage-guidelinesProvides comprehensive documentation for AI agents on how to effectively use the Memory and Agenda engines, including categorization best practices and hallucination prevention.
projectcontext://schemas/{tool}Provides the JSON schema for a specific tool. This is useful for AI agents to understand the required and optional parameters for each tool.
ProjectContext includes built-in prompts to guide AI agents through complex workflows:
setup_project_context: Templates for initializing a new project's tech stack, goals, and conventions.
plan_feature_implementation: A structured workflow for searching existing context and creating a multi-step agenda for new features.
summarize_and_remember: Distills conversation history into structured memories while avoiding duplicates.
debug_with_history: A troubleshooting workflow that leverages past bug_fix memories and system context.
maintain_memory_health: A proactive maintenance workflow for identifying and cleaning up outdated or redundant information.
Framework: FastMCP (Python MCP library)
Embeddings: fastembed (BAAI/bge-small-en-v1.5, 384-dim)
Database: SQLite with sqlite-vec and FTS5 extensions
Communication: JSON-RPC over stdio
The databases are stored in the .ctxhub/ directory in the git root (or current working directory).
memory.sqlite: Memory Engine database
agenda.sqlite: Agenda Engine database
projectcontext/
├── src/
│ └── projectcontext/
│ ├── __init__.py # Package initialization
│ ├── server.py # MCP Server (Tools, Prompts, Resources)
│ ├── memory.py # Memory Engine Logic
│ ├── agenda.py # Agenda Engine Logic
│ └── database.py # Database Utilities
├── pyproject.toml
└── .ctxhub/ # Databases# Quick start: runs main tests and offers to start server
./quickstart.sh
# Run specific tests manually
uv run python tests/test_server.py
uv run python tests/test_updates.pynpx @modelcontextprotocol/inspector uv run projectcontextGPL-3.0-or-later
Create a new agenda (plan/todo list).
Args:
tasks: List of task dicts. Each task should have:
- details: str (required)
- is_optional: bool (optional, default False)
- acceptance_guard: str (optional)
title: Optional title for the agenda
description: Optional description for the agenda
Returns:
A dictionary with status and agenda_id
| Name | Required | Description | Default |
|---|---|---|---|
| tasks | Yes | ||
| title | No | ||
| description | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses the return format (a dict with status and agenda_id) and the required task structure. However, it does not elaborate on side effects, error behavior, or permissions, leaving some uncertainty for a write 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?
The description is structured with clear 'Args' and 'Returns' sections, front-loading the purpose. It is concise and free of filler, though some repetition occurs with 'Optional'.
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 low complexity and presence of an output schema, the description adequately covers the parameters and return value. It explains the task structure but lacks details on validation or status codes, which is a minor gap. Overall, it is sufficiently complete for an agent to invoke the 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?
The schema has 0% description coverage, but the description compensates by explaining each parameter. It specifies tasks as a list of dicts with required 'details' and optional 'is_optional' and 'acceptance_guard'. It also clarifies title and description are optional, adding meaning beyond the bare 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 clearly states the tool's purpose: 'Create a new agenda (plan/todo list).' The verb 'Create' and the resource 'agenda' are explicit, distinguishing it from sibling update/delete tools. The parenthetical clarifies what an agenda is.
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 usage through the verb 'Create' but does not explicitly mention alternatives or when not to use it. It provides no exclusions or reference to other tools like update_agenda. The context is clear enough for a create operation, but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an agenda and its associated tasks.
Args:
agenda_id: The ID of the agenda to delete
Returns:
A dictionary with status and message
| Name | Required | Description | Default |
|---|---|---|---|
| agenda_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the burden of behavioral disclosure. It does disclose a side effect (deleting associated tasks) and the return type (dictionary with status and message), but omits important destructive-operation details such as irreversibility, permission requirements, or error handling. This is partial 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?
The description is concise and well-structured with Args and Returns sections. Every sentence serves a purpose, though the parameter description is slightly redundant with the parameter name. It is appropriately sized for the tool's simplicity.
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 tool, the description covers the main action, the side effect on tasks, and the return type. However, it lacks essential context for a destructive operation (permanence, error scenarios) and does not clarify its relationship to sibling tools like create_agenda or update_agenda. The presence of an output schema lessens the need to describe return structure, but key contextual gaps remain.
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 for parameter meaning. However, it only restates the parameter name ('The ID of the agenda to delete') with no added value like format, constraints, or examples. The compensation is minimal and barely exceeds 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 action ('Delete an agenda') and the specific resource ('an agenda and its associated tasks'), distinguishing it from sibling tools like delete_memory. The verb and object are explicit and unambiguous.
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, when not to use it, or any prerequisites. It only describes the mechanism of deletion without contextualizing the choice of this tool over other agenda-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a memory by ID.
Args:
doc_id: The ID of the memory to delete
Returns:
A dictionary with status and message
| Name | Required | Description | Default |
|---|---|---|---|
| doc_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states it deletes a memory but does not disclose irreversibility, permission requirements, or behavior when doc_id is not found. The return type is vaguely described as 'a dictionary with status and message' without specifics.
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 and structured with Args and Returns sections. It contains no redundant sentences and is appropriately sized for a simple delete operation.
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 delete tool with one parameter, the description covers purpose, parameter, and return. However, with no annotations, it lacks important context about permanence and error conditions, making it only minimally complete. It does not reference the existing output schema (if any) or provide example usage.
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 no description for doc_id (0% coverage). The description compensates by explaining 'The ID of the memory to delete', adding meaning beyond the schema's bare integer type. However, it does not specify format or constraints beyond that.
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 'Delete a memory by ID', using a specific verb ('Delete') and resource ('memory'), which distinguishes it from siblings like save_memory and update_memory. The scope is precisely defined by ID.
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 explicitly state that this is for permanent removal or mention any prerequisites or conditions. Sibling tools (update_memory, query_memory) are not referenced as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about an agenda, including its tasks.
Args:
agenda_id: The ID of the agenda to retrieve
Returns:
A dictionary with agenda details and tasks
| Name | Required | Description | Default |
|---|---|---|---|
| agenda_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It does disclose the return format ('A dictionary with agenda details and tasks'), which is useful. However, it does not mention error behavior (e.g., agenda not found), permissions, or side effects, though the 'get' wording implies a read-only 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?
The description is concise and well-structured with Args and Returns sections. Every sentence is informative, and there is no fluff 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?
For a simple single-parameter getter with an output schema, the description covers the essential return value and parameter. It does not discuss error cases, but given the tool's simplicity and the presence of sibling tools for other operations, the context is sufficiently complete.
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% description coverage, but the description fully explains the parameter: 'agenda_id: The ID of the agenda to retrieve'. This adds clear meaning beyond the schema's bare integer type, compensating for the lack of schema-level description.
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 'Get' and the resource 'agenda', with explicit mention of including tasks. This distinguishes it from sibling tools like list_agendas (which lists all) and search_agendas (which searches), as it targets a specific agenda by ID.
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 usage is implied: use when you need detailed information about a specific agenda by its ID. However, there is no explicit guidance on when to prefer this over alternatives or any exclusions. The distinction from list_agendas/search_agendas is implicit but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all agendas.
Args:
active_only: If True, only show active agendas (default: True)
Returns:
A list of agendas
| Name | Required | Description | Default |
|---|---|---|---|
| active_only | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the active_only filter and returns a list, but it does not state whether the operation is read-only, describe error conditions, or note ordering/pagination. This is a significant gap for a tool with no annotation support.
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 compact and well-structured with an Args/Returns layout, containing no redundant text. The opening 'List all agendas' closely mirrors the tool name, but the parameter explanation earns its place, making it appropriately concise.
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 list tool, the description covers the main action and parameter, and the output schema likely handles return structure. However, it fails to provide usage context relative to related tools (e.g., search_agendas) and omits edge-case behavior, leaving gaps for a tool in a broader set of siblings.
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 no description for active_only (coverage 0%), so the description's 'If True, only show active agendas' adds useful meaning beyond the schema's title. However, it is minimal and does not define 'active' or provide additional format details, offering limited compensation for the schema 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 states a clear verb+resource ('List all agendas'), which identifies the tool's purpose. However, it does not explicitly distinguish itself from sibling 'search_agendas' or 'get_agenda', so it lacks full sibling differentiation.
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 such as search_agendas or get_agenda. The description only explains the active_only parameter but gives no context for selection decisions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query memories using semantic and keyword search.
Args:
query: Natural language search string
top_k: Number of results to return (default: 3)
Returns:
A list of matching memories with similarity scores
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the search method (semantic and keyword) and the return format (list with similarity scores). While it doesn't explicitly state read-only behavior, the word 'query' implies no mutation, and the description adds useful context beyond a simple 'Query memories.'
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 compact and well-structured with a clear one-sentence purpose followed by Args and Returns sections. Every sentence provides necessary information with no redundancy or fluff.
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 2-parameter query tool with an output schema, the description covers all essential aspects: purpose, parameter semantics, and return value shape. No additional context is needed for an agent to correctly select and invoke the 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?
The input schema has 0% description coverage, but the description fully compensates by defining each parameter: query as 'Natural language search string' and top_k as 'Number of results to return (default: 3).' This adds semantic meaning beyond the schema's type and default.
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's function: 'Query memories using semantic and keyword search.' It specifies a specific verb (query), resource (memories), and distinguishes itself from sibling tools like save_memory and delete_memory by focusing on retrieval.
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 usage for searching memories but provides no explicit guidance on when to use this tool versus alternatives like search_agendas. It lacks exclusions or conditions, leaving the agent to infer based on the name and resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a memory to the long-term storage.
Args:
category: The category of the memory (e.g., "architecture", "preference", "fix")
topic: A short descriptive title for the memory
content: The detailed memory/decision text
Returns:
A dictionary with status, doc_id, topic, and category
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| content | Yes | ||
| category | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return format (a dictionary with status, doc_id, topic, category) but does not mention side effects beyond saving, potential overwrites, idempotency, or error behavior. This is adequate but not rich.
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 succinct and well-structured: a one-sentence purpose, followed by a clear Args list and a Returns line. No extraneous information is present; every sentence earns its place.
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 tool is relatively simple with three string parameters and no enums. The description covers purpose, all parameters, and returns. However, it omits edge-case behavior (e.g., what happens if a memory with the same topic exists) and does not leverage the output schema to further clarify, making it slightly 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?
The description compensates for the schema's 0% parameter coverage by explaining each parameter: category with examples, topic as a short title, and content as detailed text. This adds meaningful insight beyond the bare schema types.
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 saves a memory to long-term storage, using a specific verb ('save') and resource ('memory'). It distinguishes from sibling tools like delete_memory, update_memory, and query_memory by indicating a write/create operation.
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 context of 'save a memory to long-term storage' clearly implies when to use this tool (creating a new memory). However, it does not explicitly mention alternatives or when not to use it, such as referring to update_memory for modifications, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search agendas by title or description.
Args:
query: The search query string
limit: Maximum number of results to return (default: 10)
Returns:
A list of matching agendas
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | 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. It discloses that search is by title or description and returns a list, but does not mention read-only nature, matching semantics, result ordering, or behavior with no results. These are significant gaps for a search 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?
The description is compact and well-structured with Args and Returns sections. Every sentence is informative, with no redundant or wasteful content.
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 search tool with an output schema, the description covers the essential behavior and parameter semantics. However, it lacks explicit read-only disclosure and differentiation from sibling list/search tools, which 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 schema has no descriptions, so the description must compensate. It provides helpful definitions for both parameters: 'query: The search query string' and 'limit: Maximum number of results to return (default: 10)'. This adds meaning beyond the raw schema, though query formatting details are absent.
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's purpose: 'Search agendas by title or description.' This is a specific verb+resource+scope that distinguishes it from siblings like list_agendas (which lists all) and get_agenda (which retrieves a single agenda).
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 usage for finding agendas matching a query, but it does not explicitly state when to use this tool over alternatives or provide exclusions. The 'Search' verb gives context, but no alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an agenda's status, details, or add new tasks.
Args:
agenda_id: The ID of the agenda to update
is_active: Set to False to deactivate the agenda (irreversible).
new_tasks: Optional list of new task dicts to add (only if agenda is active).
title: New title (optional)
description: New description (optional)
Returns:
A dictionary with status and message
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | ||
| agenda_id | Yes | ||
| is_active | No | ||
| new_tasks | No | ||
| description | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits: deactivation via is_active=False is irreversible, and new_tasks can only be added if the agenda is active. Since no annotations are present, this provides much-needed transparency. It does not describe other side effects or error conditions, but the key behaviors are covered.
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 well-structured with a one-sentence summary followed by a clear Args list and Returns note. It is concise but includes necessary constraints. Minor redundancy with schema titles does not hurt clarity.
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 five parameters and no annotations, the description covers the core semantics, key behavioral caveats, and return type. It could be improved by clarifying whether title/description updates are allowed on inactive agendas, but overall it is sufficiently complete.
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 Args section explains every parameter beyond the schema types. It adds meaning by stating that is_active=False deactivates irreversibly and that new_tasks is only accepted on active agendas. This fully compensates for the 0% schema description coverage.
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 begins with 'Update an agenda's status, details, or add new tasks,' which clearly identifies the verb (update), resource (agenda), and scope (status, details, new tasks). It distinguishes itself from sibling tools like create_agenda, get_agenda, delete_agenda, and update_task by explicitly targeting the agenda resource.
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 usage when one needs to modify an agenda, but it does not explicitly state when to use it over alternatives such as update_task nor provide exclusions. The caution about irreversible deactivation is useful but not enough to reach the explicit-usage level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a memory by ID.
Args:
doc_id: The ID of the memory to update
category: New category (optional)
topic: New topic (optional)
content: New content (optional)
Returns:
A dictionary with status and updated details
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | ||
| doc_id | Yes | ||
| content | No | ||
| category | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states it updates by ID and returns a status dictionary, but misses crucial behavior such as handling of non-existent IDs, whether unspecified fields are left unchanged, or error conditions. This is a significant gap for a mutating 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?
The description is concise and well-structured: a one-sentence purpose, followed by an Args section for each parameter and a Returns section. No redundancy, every sentence adds value.
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 update tool, the description covers purpose, parameters, and return format. It misses edge-case behavior like invalid IDs, but given the presence of an output schema and simple params, it's largely complete. A 4 reflects minor gaps.
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 explains each parameter with clear semantics: doc_id is the target, and category/topic/content are optional new values. Since the schema has no descriptions (0% coverage), the description provides complete parameter 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?
The description clearly states 'Update a memory by ID' with a specific verb and resource, distinguishing it from sibling tools like save_memory and delete_memory by focusing on modification of existing memories.
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 usage for modifying an existing memory but doesn't explicitly say when not to use it or name alternatives. It provides no comparison with sibling tools like save_memory for creation, making usage context implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a task's completion status.
If all non-optional tasks are completed, the agenda will be marked as inactive.
Args:
task_id: The ID of the task to update
is_completed: True if the task is finished, False otherwise
Returns:
A dictionary with status and message
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | ||
| is_completed | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses a meaningful behavioral trait: the agenda becomes inactive when all non-optional tasks are completed. It also states the return type. However, it omits error behavior or edge cases, which would enhance 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?
The description is concise and well-structured: purpose, side-effect, args, and returns in a clean format. Every sentence contributes, with no fluff or redundancy.
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 two-parameter tool with an output schema, the description is sufficiently complete. It covers what it does, side-effects, parameter meaning, and return shape. Missing details like error handling are minor given the tool's simplicity and the existence of an output schema.
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 no descriptions (0% coverage), so the description's parameter explanations add value, especially clarifying that 'is_completed' means 'True if the task is finished'. However, 'task_id' explanation is minimal, and the semantics largely duplicate what the schema's type and name already imply.
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 ('Update a task's completion status') with a specific verb and resource. It also explains an important side-effect on the agenda, distinguishing it from sibling tools focused on agendas and memory.
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 purpose is obvious but there is no explicit guidance on when to use this tool versus alternatives, nor any exclusions. The side-effect note implies a condition, but no clear context or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool clearly targets either the memory resource (save/delete/update/query) or the agenda resource (create/list/get/search/update/delete). Even update_task is distinct from update_agenda as it operates on a sub-resource, eliminating any real ambiguity.
All tools follow a consistent verb_noun pattern with snake_case, using clear verbs like save, delete, update, query, create, list, get, search. The pluralization of list_agendas vs get_agenda is a minor stylistic variation but consistent throughout.
11 tools is well within the ideal 3-15 range, covering two distinct domains (memory and agenda) without bloat or thinness. Each tool earns its place in the set.
Memory has full CRUD plus semantic search, and agenda has create/read/update/delete plus task management. The only noticeable gap is the lack of a list_memories tool, but query_memory serves as a search-based alternative. Task deletion is also not available, but tasks can be added and marked complete, so the core lifecycle is covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP memory server. One memory your agents share — across models, devices and apps.
Shared, governed long-term memory for AI agents across tools and sessions via MCP and REST.
Cloud-hosted MCP server for durable AI memory
Shared memory for all your AI agents, your whole team and every MCP client — save, search, recall.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/asd-noor/projectcontext'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
