YodMCP

Server Quality Checklist

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

Latest release: v0.4.0
Disambiguation4/5
Most tools target distinct resources (memory, tasks, plan cache, audit, etc.), but there is potential confusion between memory_read and plan_cache_get (both retrievals), and between discover_capabilities and a2a_card (both about agent capabilities). The descriptions help disambiguate, making the set mostly clear.
Naming Consistency3/5
All tools use snake_case, but the verb positioning varies: most follow a noun_verb pattern (memory_write, tasks_create), but discover_capabilities is verb_noun, and echo is a lone verb. The pattern is not uniform, though still readable and predictable within subgroups.
Tool Count4/5
With 17 tools covering multiple domains (plan cache, memory, tasks, discovery, audit, attestation), the count is on the higher side but still justified for a server that acts as a meta-agent. A few tools could be merged, but the overall scope supports the count.
Completeness3/5
The tool set covers core operations for memories (read/write/consolidate/stats) and tasks (create/get/cancel/stats), but lacks deletes for memory, plan cache, and tasks, and has no task listing or update. These gaps are notable and could cause agent failures in typical workflows.
Average 2.4/5 across 17 of 17 tools scored. Lowest: 1.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 45 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It fails to mention whether the tool is read-only or destructive, any authentication needs, rate limits, or side effects. The term 'cMCP-style' is an unexplained jargon that obscures behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (4 words), which is concise but at the cost of informativeness. The lack of detail makes it under-specified rather than efficient, earning a middling score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 optional parameter), the description is severely incomplete. An output schema exists but the description does not hint at what it returns. Sibling audit_recent suggests a temporal audit context, but without clarification, the agent cannot use this tool correctly.
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% and the description adds no meaning beyond the schema. The sole parameter 'limit' has a default of 10 but the description does not explain its purpose or acceptable range. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Recent TRACE claims (cMCP-style).' is vague and lacks a clear verb and resource. It does not specify what action the tool performs (e.g., retrieve, list, fetch), and the term 'TRACE claims' is undefined, making it ambiguous against siblings like audit_recent which likely does something similar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. With siblings like audit_recent and various memory tools, there is no explanation of the specific context, prerequisites, or exclusions needed for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of disclosing behavioral traits such as side effects, authentication needs, or rate limits. It fails entirely: the description is only a name repetition and reveals nothing about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but lacks substance. It is under-specified rather than concisely informative. Every sentence should earn its place; this single sentence does not add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema exists but is not detailed, and there are 16 sibling tools, the description should minimally hint at the tool's role (e.g., retrieving or exposing an agent card). The current description is insufficient to distinguish it from siblings or explain its value.
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 input schema is empty (0 parameters) and schema coverage is 100%, so there is nothing to document. The description does not add meaning but also has no parameters to clarify. Following the guideline, 0 parameters with high coverage baseline is 4; the description does not detract from this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology: 'YodMCP A2A Agent Card' merely restates the tool name 'a2a_card' without adding any concrete information about what the tool does. It does not specify any verb or resource action, making it useless for an AI agent to understand its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when or when not to use this tool. There is no mention of alternative tools, context dependencies, or prerequisites, leaving the agent without decision-making support.
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 provided, the description carries the full burden of behavioral disclosure. It fails to indicate whether this tool is read-only, whether it has rate limits, requires authentication, or what the output structure looks like. The existence of an output schema partially mitigates this, but the description adds no 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short at three words, which on its own is not concise but rather under-specified. It front-loads nothing useful and earns its place very poorly. A score of 3 reflects that brevity is maintained but without substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter, no annotations, but does have an output schema, the description is severely incomplete. It fails to explain what audit events are, how they are ordered (e.g., chronological), the effect of limit, or how this differs from other event-based tools. The output schema exists but is not leveraged by the description.
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%, meaning the schema provides no descriptive text for the 'limit' parameter. The description does not mention or explain the limit parameter at all, so it adds zero value beyond what the schema structure already shows. The agent must guess that limit controls the number of events returned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Recent audit events.' is extremely terse and lacks a specific verb or resource context. It doesn't clarify what kind of events are returned (e.g., system, user, security), making it vague and difficult for an agent to distinguish from sibling tools like 'attestation_recent' which also sounds event-related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as 'attestation_recent' or any other tool. No context about prerequisites, filters, or scope is provided, leaving the agent without any decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It merely states 'Cache statistics' and does not reveal whether the operation is read-only, what side effects exist, or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse (two words) but under-specified, resembling the 'Process' calibration example. It sacrifices substance for brevity, failing to convey necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which could document return format), the description provides no context about what statistics are returned or the tool's purpose. It is insufficient for an agent to understand when to invoke this tool.
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 input schema has zero parameters with 100% schema description coverage. Baseline is 3 for high coverage; the description adds no parameter meaning beyond the schema since there are none to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Cache statistics' is a noun phrase that merely restates the tool name without a verb. It lacks a specific action (e.g., 'retrieve', 'get') and does not distinguish this tool from siblings like 'memory_stats' or 'plan_cache_get'.
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 alternative cache- or statistics-related siblings. The description gives no context for appropriate invocation.
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 provided, the description carries the full burden of behavioral disclosure. It only hints at a 'progressive' nature without explaining what that means (e.g., pagination, incremental results, statefulness). No mention of idempotency, side effects, authentication, or rate limits. This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise. However, it is under-specified for the tool's purpose. Every sentence should earn its place, and this sentence is too vague to be valuable. It is front-loaded but lacks substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 (not shown) and a single optional parameter, the description is overly brief. It does not explain the return format, the meaning of 'progressive', or how the tool fits into the workflow. The agent is left with many unanswered questions, making the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/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 the missing parameter documentation. The description does not mention the single 'query' parameter at all. The agent cannot infer what the query does (e.g., filter, search term, specific capability identifier) or how to use it effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description mentions 'Progressive discovery of tools, skills, tasks, A2A', which gives a general sense of the tool's domain but lacks a specific verb+resource. The term 'progressive discovery' is ambiguous, and the tool could be interpreted as a search or listing mechanism. It is not a tautology, but it is not precise enough to distinguish from siblings like 'skills_list' or 'tasks_create'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. The description does not mention any context, prerequisites, or exclusions. Given the presence of sibling tools like 'skills_list', 'tasks_get', and 'a2a_card', the agent has no way to determine if discover_capabilities should be used first or selectively.
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 present, so the description carries the full burden of behavioral disclosure. It only implies a read operation but does not state whether it is read-only, if it has side effects, requires authentication, or how it handles missing keys. Essential behavioral traits are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse (two words), sacrificing essential detail for brevity. It is not a complete sentence and lacks any structure. While conciseness is valuable, here it undermines clarity and utility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one required parameter, an output schema (not shown), and several sibling tools (including plan_cache_put, cache_stats, memory_read), the description is insufficient. It does not explain what the semantic plan cache is, how this lookup differs from other cache or memory operations, or what the return value represents. The agent cannot fully understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no explanation beyond the parameter name 'task_description' and type 'string'. The tool description does not elaborate on this parameter—no format, semantics, or usage hints. This leaves the agent completely in the dark about how to provide the input correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Semantic plan cache lookup' indicates the tool performs a lookup in a semantic plan cache, which is a generic purpose. However, it lacks specificity about what is retrieved and does not distinguish it from sibling tools like plan_cache_put or cache_stats. The description is a noun phrase rather than a clear verb-object statement.
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 usage guidance is provided. The description does not mention when to use this tool over alternatives such as memory_read or other cache tools. There are no exclusions or context for tool selection.
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 behavior. It only implies a state change ('Cancel') but does not explain idempotency, cascading effects, or permissions required. The output schema exists but is not referenced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (4 words) but at the cost of completeness. It omits critical context, making it under-specified rather than efficiently helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity (1 param, output schema), the description fails to cover basic aspects like return behavior, side effects, or relationship to sibling tools. The output schema exists but the description does not leverage it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the single required parameter 'task_id'. There is no format, example, or constraint given, leaving the agent to guess the expected value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Cancel a task' states the verb and resource clearly, but it is essentially a restatement of the tool name. It does not differentiate from sibling tools like tasks_get or tasks_create, which are distinct operations on the same resource.
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, nor are there prerequisites or conditions for cancellation (e.g., whether a task must be in a specific state).
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 provided, the description carries the full burden of behavioral disclosure. It only states 'Persist into multi-graph hierarchical memory' without clarifying whether this is an append, overwrite, or merge operation, what side effects occur (e.g., triggers consolidation), or any security or rate-limit implications. This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise but not sufficiently informative for a tool with 8 parameters and no schema descriptions. It earns its place by stating the core purpose, but it omits crucial details that could be added without significant bloat. The conciseness is acceptable but at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, 0% schema description coverage, no annotations, and an output schema not explained), the description is drastically incomplete. It fails to cover parameter meanings, behavioral nuances, or return values. This gap makes it difficult for an agent to use the tool correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description does not mention or explain any of the 8 parameters (level, content, agent_id, entities, metadata, importance, session_id, causal_parent). The agent must rely solely on parameter names and titles, which are ambiguous (e.g., 'level' could mean importance or hierarchy depth). The description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool persists into 'multi-graph hierarchical memory,' which identifies the general action and resource. However, the verb 'persist' is vague and less common than 'write' or 'store', and it does not specify what kind of data (content, entities, etc.) is being written. It also fails to distinguish this tool from siblings like memory_consolidate, which may also modify memory. The purpose is barely adequate.
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 usage guidance is provided. The description does not indicate when to use memory_write versus alternative memory tools (e.g., memory_read, memory_consolidate), nor does it mention prerequisites, conditions, or context. The agent receives no help in deciding whether this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only says 'for reuse' but does not explain overwrite behavior, persistence, validation of the plan object, or error conditions. This is severely lacking for a storage/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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (4 words, 1 sentence), which is concise but at the cost of missing critical context. It is front-loaded with the essential action, but fails to earn its place by omitting necessary details for correct usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two required parameters, one a nested object, and an output schema exists, the description is incomplete. It does not explain return values, conflict handling, or the relationship to the sibling 'plan_cache_get' tool. The behavioral gaps are significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, but it adds nothing about the parameters. 'plan' is only implied as a template, and 'task_description' is not mentioned as a key or identifier. The semantic meaning of the parameters is left entirely to the schema structure.
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 uses a clear verb 'store' and resource 'plan template', which aligns with the tool name 'plan_cache_put'. It hints at reuse, distinguishing it from 'plan_cache_get' (retrieval). However, it could be more specific about the type of plan (e.g., task plan) and that it is keyed by task_description.
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 on when to use this tool versus alternatives like 'memory_write' or 'plan_cache_get'. There is no mention of prerequisites, context, or when to avoid using it. The description is purely declarative.
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 provided, the description carries full burden for behavioral disclosure. It describes the action as 'Create durable async task handle', implying a write operation, but does not state behavior such as whether this is idempotent, whether it requires authentication, what the 'durability' entails (persistence, lifecycle, error handling), or return behavior. The gap is significant.
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 a single sentence of 7 words, which is concise. However, it sacrifices clarity and usefulness for brevity. It does front-load the key concept 'Create durable async task handle', but the lack of detail makes it less helpful overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, optional, no schema descriptions) and the presence of an output schema (which the description does not utilize), the description is incomplete. It does not explain what a task handle is, how parameters like ttl_ms affect behavior, or what the output contains. Sibling tools like tasks_get and tasks_cancel suggest a workflow, but no context is provided.
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%, and the description adds no information about parameters. The three parameters (ttl_ms, metadata, tool_name) are not mentioned at all. For instance, the agent cannot infer that tool_name might link to another tool for execution or that metadata is free-form. The description fails to compensate for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create durable async task handle', which specifies the verb 'create' and the resource 'durable async task handle'. While it communicates the basic action, the term 'Tasks extension' is vague and doesn't clearly distinguish this from sibling tools like tasks_get, tasks_cancel, or tasks_stats, which are all related to tasks.
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 like tasks_get or tasks_cancel. There is no mention of prerequisites, context for async task creation, or when to choose this over other tools. The description lacks any explicit or implied usage context.
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 provided, the description carries the full burden of behavioral disclosure. It only states 'poll task status/result' without revealing idempotency, side effects, prerequisites (e.g., task must exist), or what happens if the task is still running. This is insufficient for an agent to understand the tool's behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at four words, which is appropriate for a simple tool. However, the brevity comes at the cost of omitting essential usage and behavioral information. It is front-loaded with the action but lacks structure that would help an agent decide if and how to use it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (1 parameter, output schema exists), the description is incomplete. It does not explain the output contents (status vs. result, when each is available) or handle edge cases like non-existent task IDs or running tasks. The output schema may partially cover return values, but the description lacks important contextual details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning for the single required parameter 'task_id'. It does not explain what constitutes a valid task_id, where to obtain it, or any constraints. The description fails to compensate for the missing schema descriptions, providing no value beyond the parameter name.
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 'Poll task status/result' clearly identifies the tool's action (poll/get) and resource (task status/result). It distinguishes from sibling tools like tasks_create, tasks_cancel, and tasks_stats, which handle different operations. A slightly more precise verb like 'get' would improve clarity, but the purpose is adequately stated.
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 usage guidelines are provided. The description does not indicate when to use tasks_get versus alternatives like tasks_stats (which might also provide status). There are no conditions, prerequisites, or exclusions mentioned, leaving the agent without contextual decision support.
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 behavior, but it only says 'Connectivity probe.' It does not specify whether it makes a network call, echoes the message, or has any side effects. The parameter 'message' suggests echoing, but that information is in the schema, not the description. The description adds little value beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a short phrase 'Connectivity probe' with no wasted words. However, it is under-specified for a tool with a parameter; the brevity is not paired with necessary elaboration. It is not verbose, but it could be more informative while still being concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description lacks important context such as what the tool returns, how to interpret the response, or any prerequisites. Even with an output schema, the description's 'Connectivity probe' does not sufficiently prepare an agent to use the tool effectively. It should at least mention that it echoes the message back or confirms connectivity.
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?
The input schema has one parameter 'message' with default 'ping', but the description does not explain its meaning or usage. Since schema description coverage is 0%, the description should compensate, but it does not. The agent is left to infer from the schema alone, which reduces the description's contribution to parameter understanding.
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 the tool is a 'Connectivity probe,' which clearly conveys its function of testing connectivity. The verb 'probe' and resource 'connectivity' provide a specific purpose that distinguishes it from the unrelated sibling tools. It is not a tautology and offers enough clarity for a simple tool.
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 any alternatives. It doesn't mention exclusions or alternative tools, and the phrase 'Connectivity probe' only implies usage indirectly. An agent would not know when to select this tool over others based solely on this description.
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 of behavioral disclosure. It does reveal that retrieval uses 'embedding similarity', implying a semantic search rather than exact match, which adds useful context. However, it does not mention side effects (likely none), performance considerations, rate limits, or fallback behavior. It also fails to note that the 'limit' parameter controls result count or that the tool can also retrieve by ID ('item_id'). For a read tool with no annotations, this is moderately transparent, hence a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it very concise. However, the structure is minimal—no hierarchical breakdown, bullet points, or separation into sections. For a tool with 7 parameters, the conciseness sacrifices necessary detail. The sentence earns its place but could be expanded without losing efficiency. A score of 3 reflects adequate conciseness but poor structure for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 optional parameters, 0% schema description coverage, and presence of an output schema), the description is far from complete. It fails to explain the two retrieval modes (query-based via 'query' and exact-match via 'item_id'), the role of 'graph' and 'level' in scoping, or the interaction with 'agent_id' and 'session_id'. The output schema exists but is not referenced. The agent cannot fully understand how to use the tool effectively; a score of 2 captures this incompleteness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/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 by explaining the parameters. It does not mention any of the 7 parameters (graph, level, limit, query, item_id, agent_id, session_id), leaving their purpose entirely to the schema. The schema itself lacks descriptions, so the agent receives no guidance on how to use each parameter. This is a critical gap, warranting a score of 1.
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 'Retrieve from multi-graph memory with embedding similarity' clearly states the action (retrieve) and resource (multi-graph memory), and specifies the method (embedding similarity). It distinguishes this tool from siblings like memory_write (write) and memory_consolidate (consolidate). However, it does not specify the exact form of the returned data (e.g., a list of memory items) or differentiate from plan_cache_get, which also retrieves data. While clear, it could be more specific about the output, so a 4 is appropriate.
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. There is no mention of prerequisites, exclusions, or competing tools (e.g., plan_cache_get for plans, or item_id-based vs. query-based retrieval). The agent receives no help deciding between memory_read and other tools, resulting in a score of 2.
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 provided, the description must fully disclose behavioral traits. It does not state if this is a read-only operation, if it has side effects, or if it accesses external storage. The lack of any behavior cues beyond 'stats' is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (three words), but brevity alone is not conciseness—it lacks essential information that warrants expansion. It is front-loaded but misses critical context that should earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no annotations, the description should clarify the output (which appears to have an output schema) and behavior. It fails to describe what the returned statistics include or how they relate to the task store, leaving the agent uninformed.
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 input schema has zero parameters, so parameter semantics are not relevant here. The description does not need to add meaning beyond what the schema provides. Baseline score reflects the schema coverage being 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Task store stats.' vaguely indicates it provides statistics about a task store, but it doesn't specify what specific statistics, the source of the data, or how it distinguishes from sibling tools like cache_stats or memory_stats. The verb is implied (get/retrieve) but not explicitly stated.
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 on when to use this tool versus other stats tools (e.g., memory_stats, cache_stats). No context about prerequisites or intended use cases is 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 provided, the description carries the full burden of disclosing behavioral traits. It does not state whether consolidation is destructive (e.g., removes episodic items), irreversible, or whether it requires certain permissions. The return value or side effects are not described.
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 a single concise sentence that directly states the tool's action. Every word adds value, and there is no redundant information.
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?
Given low complexity (one optional parameter, no nested objects) and the presence of an output schema, the description is mostly adequate. However, a mutation tool that does not disclose side effects or failure modes leaves some completeness gaps.
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 only one parameter ('from_level') with a default value but 0% description coverage. The description implies the parameter's purpose via 'from_level' mapping to 'episodic' items, adding meaning beyond the bare schema. For a nearly trivial single-param tool, this is sufficient.
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 clearly uses a specific verb-resource pair ('Promote ... items into ... graph') and distinguishes the core action from siblings like memory_write or memory_read. However, the term 'semantic graph' may be jargon without further context.
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 like memory_write or when items should be consolidated. There are no prerequisites or exclusions mentioned, leaving the agent to guess the proper invocation context.
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 exist, so the description must disclose behavioral traits. It only states what the tool does (counts) but omits whether it is read-only, what side effects (none expected), performance considerations (e.g., may be expensive on large graphs), or required permissions. The presence of an output schema partially mitigates the need to describe return values, but other transparency aspects are unaddressed.
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 a single concise sentence that clearly communicates the purpose. It is front-loaded with the key action and resource. No unnecessary words are present. A slightly more structured approach (e.g., 'Retrieves...') could improve clarity, but the current form is efficient.
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 has no parameters and an output schema exists, the description adequately covers the core purpose. However, it could benefit from explaining what 'memory levels' and 'graphs' refer to in the context of the system, especially since sibling tools have related but different scopes. The description is minimally complete but enough for a zero-param stats 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 tool has zero parameters and schema coverage is 100% (empty schema). Per guidelines, a baseline of 4 is appropriate when no parameters exist. The description does not need to add parameter information since there are none.
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 provides 'Node and edge counts across memory levels and graphs.' It specifies the verb ('counts') and resource (node and edge counts), and the scope ('across memory levels and graphs') distinguishes it from sibling tools like memory_read (reads specific entries) and tasks_stats (task-specific stats).
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 usage guidelines are provided. The description does not indicate when to use this tool versus alternatives such as memory_read, memory_consolidate, or cache_stats. There is no mention of prerequisites, contexts where this tool is appropriate, or when it should be avoided.
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 carries the full behavioral burden. It indicates a read-only listing operation (no parameters, returns a list), but does not specify details like whether it pulls from a static or dynamic source, or any performance implications. However, the absence of annotations coupled with the simple listing nature makes a mid-score appropriate.
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 a single, concise sentence that directly states the tool's purpose and references the resource hierarchy, with zero wasted words. It is appropriately sized for a simple no-parameter tool.
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 zero-parameter listing tool with no annotations and an output schema (implied by 'Has output schema: true'), the description is sufficiently complete: it names the resource type and structure, which is all an agent needs to invoke it correctly. The absence of details about the output format is justified because the output schema should provide that.
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 input schema has zero parameters and 100% description coverage (no params to describe), so the description adds no parameter info but does not need to. The description's mention of 'skills:// resources' provides meaningful context about what the listing covers, which is valuable.
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 clearly states that the tool lists agent skills, and references the 'skills://' resource hierarchy, providing a specific verb (List) and resource (Agent Skills), which distinguishes it from sibling tools that deal with memory, tasks, plans, or caching.
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?
No explicit guidance on when to use this tool versus alternatives is provided, but its zero-parameter, listing nature implies it's a simple inspection tool without side effects, which is adequate for a straightforward list operation.
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:

[![YodMCP MCP server](https://glama.ai/mcp/servers/ANAMIZED/YodMCP/badges/card.svg)](https://glama.ai/mcp/servers/ANAMIZED/YodMCP)

Score Badge

Copy to your README.md:

[![YodMCP MCP server](https://glama.ai/mcp/servers/ANAMIZED/YodMCP/badges/score.svg)](https://glama.ai/mcp/servers/ANAMIZED/YodMCP)

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/ANAMIZED/YodMCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server