ProjectContext

by asd-noor

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.9/5 across 11 of 11 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under GPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![projectcontext MCP server](https://glama.ai/mcp/servers/asd-noor/projectcontext/badges/card.svg)](https://glama.ai/mcp/servers/asd-noor/projectcontext)

Score Badge

Copy to your README.md:

[![projectcontext MCP server](https://glama.ai/mcp/servers/asd-noor/projectcontext/badges/score.svg)](https://glama.ai/mcp/servers/asd-noor/projectcontext)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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