Cursor10x MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between 'storeAssistantMessage'/'storeUserMessage' and 'endConversation'/'initConversation', which bundle similar operations. The 'manageVector' tool is broad but clearly defined, while others like 'getRecentEpisodes' and 'getRecentMessages' target different memory types, reducing confusion.
Naming Consistency3/5
Naming is mixed with camelCase (e.g., 'checkHealth') and snake_case (e.g., 'store_assistant_message'), though most tools use a verb_noun pattern. Inconsistencies like 'diagnoseVectors' vs. 'manageVector' and variations in verb usage (e.g., 'get', 'store', 'record') detract from a uniform convention.
Tool Count4/5
With 18 tools, the count is slightly high but reasonable for a memory system server covering health, diagnostics, conversation management, and multiple memory types (short-term, episodic, long-term). It avoids being overwhelming by grouping related operations, though some tools could be consolidated.
Completeness5/5
The tool set comprehensively covers the memory system domain, including initialization, conversation handling, message storage, episode recording, milestone/requirement/decision tracking, vector management, health checks, diagnostics, and context retrieval. There are no obvious gaps, supporting full lifecycle operations for memory management.
Average 3/5 across 18 of 18 tools scored.
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 MIT License.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves context but doesn't clarify whether this is a read-only operation, what permissions might be needed, how results are formatted, or any performance implications (e.g., latency, rate limits). This leaves significant gaps for a tool that presumably accesses multiple systems.
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, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded with the core action, though it could be slightly more specific to improve clarity without sacrificing brevity.
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 lack of annotations and output schema, the description is incomplete for a tool that retrieves 'comprehensive context.' It doesn't explain what 'comprehensive' means, what systems are involved, the format of returned data, or any limitations, making it inadequate for an agent to understand the full scope and behavior.
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 description coverage is 100%, with the single parameter 'query' documented as optional and for semantic search. The description adds no additional meaning beyond this, such as examples of queries or how they influence retrieval. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 action ('Retrieves') and target ('comprehensive context from all memory systems'), which is clear but vague. It doesn't specify what 'comprehensive context' entails or how it differs from sibling tools like getRecentEpisodes or getRecentMessages, leaving room for ambiguity about scope and content.
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. With siblings like getRecentEpisodes and getRecentMessages that might retrieve specific subsets of context, the description lacks any indication of appropriate use cases, prerequisites, or exclusions, leaving the agent to guess based on the tool name alone.
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 carries the full burden of behavioral disclosure. It states the tool 'Records an episode', implying a write operation, but doesn't cover critical aspects like permissions needed, whether it's idempotent, error handling, or what happens upon success (e.g., confirmation). This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Records an episode (action) in the episodic memory'. It's front-loaded with the core action and resource, with no wasted words, though it could be slightly more specific to enhance clarity without losing conciseness.
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 as a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'episodic memory' entails, how episodes are used, or what the tool returns, leaving the agent with insufficient context for reliable invocation.
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 100% description coverage, clearly documenting all 5 parameters (action, actor, content, context, importance) with their types and purposes. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without extra 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 states the tool 'Records an episode (action) in the episodic memory', which provides a clear verb ('Records') and resource ('episode in episodic memory'). However, it doesn't distinguish this tool from its siblings like 'storeUserMessage' or 'storeAssistantMessage', which might also record memory-related actions, making the purpose somewhat vague in 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?
The description offers no guidance on when to use this tool versus alternatives. With siblings like 'storeUserMessage', 'storeAssistantMessage', and 'storeDecision' that might handle similar memory storage, there's no indication of specific use cases, prerequisites, or exclusions for 'recordEpisode'.
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 but is minimal. It implies a logging/monitoring function ('tracks') but doesn't disclose behavioral traits such as whether this is a read-only operation, if it stores data persistently, requires specific permissions, or has side effects like updating a database. The description lacks details on what 'tracks' entails beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence that efficiently states the tool's purpose without unnecessary words. It's front-loaded with the core function, though it could be slightly more informative without losing conciseness.
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 complexity (3 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what the tool returns, how tracking is implemented, or interactions with sibling tools (e.g., 'getActiveFiles' for retrieval). For a tool that likely involves state changes or logging, more context is needed to guide effective use.
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?
Schema description coverage is 100%, so the schema already documents all parameters (action, filename, metadata) with clear descriptions. The description adds no additional meaning beyond what the schema provides, such as explaining the relationship between parameters or typical use cases, meeting the baseline for high 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 the tool 'tracks an active file being accessed by the user', which provides a basic purpose (verb+resource). However, it's vague about what 'tracks' means operationally and doesn't differentiate from sibling tools like 'getActiveFiles' or 'recordEpisode', which may have overlapping functionality with file tracking or logging.
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 offers no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., real-time monitoring vs. logging), or exclusions, leaving the agent to infer usage from the name and parameters alone.
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 carries full burden. It states 'Retrieves' implying a read operation, but doesn't disclose behavioral traits like permissions needed, rate limits, or what 'active files' entails (e.g., format, freshness). This is a significant gap for a tool with no annotation coverage.
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, efficient sentence with zero waste. It's appropriately sized and front-loaded, clearly stating the core purpose without unnecessary elaboration.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'active files' are, their format, or return values, leaving gaps in understanding for a tool that retrieves data from memory.
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 description coverage is 100%, so the schema already documents the 'limit' parameter fully. The description adds no additional meaning beyond what the schema provides, such as context on how 'active files' are determined or filtered, resulting in the baseline score.
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 the verb ('Retrieves') and resource ('active files from the short-term memory'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'trackActiveFile' or 'getRecentEpisodes', which might have overlapping functionality, preventing a perfect score.
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. With siblings like 'getComprehensiveContext' and 'getRecentMessages', there's no indication of context, prerequisites, or exclusions, leaving usage ambiguous.
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 carries the full burden of behavioral disclosure. It states the tool retrieves data but lacks details on permissions, rate limits, error handling, or what 'recent' means (e.g., time-based vs. count-based). This leaves gaps in understanding how the tool behaves in practice.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and easy to parse, though it could be slightly more informative without sacrificing brevity.
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 no annotations and no output schema, the description is minimal but covers the basic purpose. It lacks details on behavioral traits and output format, which are important for a retrieval tool. However, the schema provides good parameter coverage, making it adequate but with clear gaps in completeness.
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?
Schema description coverage is 100%, with clear parameter documentation in the input schema. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't explain 'context' filtering further or 'recent' criteria). Baseline 3 is appropriate as the schema handles parameter semantics adequately.
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 the action ('Retrieves') and resource ('recent episodes from the episodic memory'), making the tool's purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'getRecentMessages' or 'getComprehensiveContext', which might also retrieve memory-related data, leaving some ambiguity about when to choose this specific 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 alternatives. With siblings like 'getRecentMessages' and 'getComprehensiveContext' that likely handle similar memory retrieval, the agent has no explicit direction on selection criteria, such as based on recency, context filtering, or data type.
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 carries full burden. It mentions behavioral outcomes (storing, generating, retrieving) but lacks critical details: whether this is a write operation (implied by 'storing'), permission requirements, rate limits, or what 'retrieving context' entails. The multi-operation nature suggests complexity that isn't fully disclosed.
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?
Single sentence efficiently conveys the core functionality with zero wasted words. It's front-loaded with the main action ('initializes a conversation') followed by key operations.
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?
For a tool with no annotations, no output schema, and performing multiple operations (store, generate, retrieve), the description is insufficient. It doesn't explain the banner format, what context is retrieved, how results are returned, or error handling. The complexity warrants more disclosure.
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?
Schema description coverage is 100%, so the schema fully documents all 3 parameters. The description adds no parameter-specific information beyond implying 'content' is the user message. This meets the baseline for high schema coverage.
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 the tool's purpose with specific verbs ('initializes', 'storing', 'generating', 'retrieving') and identifies the resource ('conversation'). It distinguishes from siblings like 'storeUserMessage' or 'generateBanner' by combining multiple operations, but doesn't explicitly contrast them.
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 explicit guidance on when to use this tool versus alternatives like 'storeUserMessage' + 'generateBanner' + 'getComprehensiveContext'. The description implies it's for starting conversations, but lacks context on prerequisites, timing, or exclusions.
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. While it lists operations, it doesn't describe what 'manage' entails - whether operations are atomic, have side effects, require specific permissions, have rate limits, or what happens on failure. For a multi-operation tool with 8 parameters and no annotation coverage, this is a significant gap.
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, efficient sentence that communicates the core purpose. It's appropriately sized for a multi-operation tool, though it could be slightly more structured by separating operation types or adding brief 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?
For a complex tool with 8 parameters, multiple operations, no annotations, and no output schema, the description is inadequate. It doesn't explain return values, error conditions, operation interdependencies, or how this fits within the broader vector management system alongside tools like 'diagnoseVectors'.
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?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it mentions operations but doesn't clarify parameter dependencies or operation-specific requirements. Baseline 3 is appropriate when the schema does the heavy lifting.
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 this is a 'unified tool for managing vector embeddings' with specific operations listed (store, search, update, delete), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'diagnoseVectors' or explain how this differs from other vector-related operations that might exist in the 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?
The description mentions the four operations but provides no guidance on when to use this tool versus alternatives like 'diagnoseVectors' or other sibling tools. There's no indication of prerequisites, constraints, or typical use cases for each operation type.
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 carries the full burden of behavioral disclosure. It states the tool stores data in 'long-term memory', implying persistence, but lacks details on permissions, idempotency, error handling, or what constitutes a 'project decision'. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'long-term memory' entails, how decisions are retrieved or updated, or the implications of storage. Given the complexity and lack of structured data, more context is needed.
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?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no additional meaning beyond implying storage of 'project decision' data, which aligns with parameters like 'title' and 'content'. This meets the baseline for high schema coverage.
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 the action ('Stores') and the resource ('a project decision in the long-term memory'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'storeMilestone' or 'storeRequirement', which appear to be similar storage operations, preventing a perfect score.
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. With sibling tools like 'storeMilestone' and 'storeRequirement' that might serve similar purposes, there's no indication of context, prerequisites, or exclusions to help an agent choose appropriately.
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 carries the full burden of behavioral disclosure. It states the tool stores data in 'long-term memory', implying persistence, but doesn't clarify what 'long-term' entails (e.g., durability, retrieval mechanisms), whether it's a write operation with potential side effects, or any error conditions. For a storage tool with zero annotation coverage, this is a significant gap in 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 a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence earns its place by conveying essential information.
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 complexity of a storage operation with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after storage (e.g., success/failure indicators, return values, or how to retrieve the milestone later). For a tool that modifies state, more behavioral context is needed to guide the agent effectively.
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 100% description coverage, with clear documentation for all 4 parameters (title, description, importance, metadata). The description adds no additional meaning beyond what the schema provides, such as explaining how parameters interact or their impact on storage. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
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 the action ('Stores') and resource ('a project milestone in the long-term memory'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'storeAssistantMessage', 'storeDecision', or 'storeRequirement', which also store different types of data in memory, so it doesn't fully distinguish its purpose from alternatives.
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. It doesn't mention when to choose 'storeMilestone' over other storage tools like 'storeDecision' or 'storeRequirement', nor does it specify any prerequisites or exclusions for usage. This leaves the agent without 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool stores data in 'long-term memory', implying persistence, but doesn't cover critical aspects like whether this requires specific permissions, how data is retrieved or updated, potential rate limits, or error handling. For a storage tool with zero annotation coverage, this is a significant gap.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized for its function, with no wasted content.
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 (storage operation with 4 parameters, no output schema, and no annotations), the description is incomplete. It doesn't explain what 'long-term memory' entails, how to retrieve stored requirements, or potential side effects, making it inadequate for an agent to use effectively without additional context.
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 100% description coverage, so the schema already documents all parameters (title, content, importance, metadata). The description adds no additional meaning beyond what the schema provides, such as examples or context for parameter use. Baseline 3 is appropriate when the schema does the heavy lifting.
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 the action ('Stores') and the resource ('a project requirement in the long-term memory'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'storeAssistantMessage', 'storeUserMessage', 'storeDecision', or 'storeMilestone', which all store different types of data in memory, so it lacks sibling distinction.
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. It doesn't mention prerequisites, context for storing requirements, or how it differs from other storage tools like 'storeDecision' or 'storeMilestone', leaving usage ambiguous.
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. While 'Stores' implies a write operation, it doesn't specify whether this is persistent, reversible, or has side effects. It mentions 'short-term memory' but doesn't explain retention policies, capacity limits, or how this interacts with other memory tools like 'getRecentMessages'.
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, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a straightforward storage tool and front-loads the essential information.
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?
For a write operation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after storage (e.g., confirmation, error handling), how to retrieve stored messages, or integration with related tools. The mention of 'short-term memory' is vague without operational details.
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?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no additional parameter information beyond what's in the schema, maintaining the baseline score for high schema coverage.
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 the action ('Stores') and resource ('a user message in the short-term memory'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'storeAssistantMessage' or 'storeDecision', but the specificity of 'user message' provides some implicit distinction.
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 like 'storeAssistantMessage' or 'storeDecision', nor does it mention prerequisites or context for usage. It simply states what the tool does without indicating appropriate scenarios.
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 states what the tool does but doesn't describe how it behaves: no information about what 'health' means, what metrics are checked, whether it performs any operations, what the output format might be, or any error conditions. For a diagnostic tool with zero annotation coverage, this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a simple diagnostic tool and front-loads the essential information. Every word earns 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 annotations, no output schema, and the description provides minimal behavioral context, this is incomplete for a diagnostic tool. The agent knows what to call but not what to expect in return or how the tool behaves. For a health check that could return various status indicators, more context about output format or meaning would be helpful.
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 description coverage is 100%. The description doesn't need to explain parameters, and it correctly doesn't mention any. The baseline for zero parameters with full schema coverage is 4, as there's no parameter information to add beyond what's already documented.
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 the tool's purpose with a specific verb ('checks') and resource ('health of the memory system and its database'). It distinguishes from most siblings like 'getMemoryStats' or 'diagnoseVectors' by focusing on overall system health rather than specific metrics or diagnostics. However, it doesn't explicitly differentiate from all potential health-related tools.
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. It doesn't mention prerequisites, appropriate contexts, or compare it to siblings like 'getMemoryStats' or 'diagnoseVectors' that might provide related information. The agent must infer usage from the purpose alone.
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. While 'Run diagnostics' implies a read-only analysis operation, it doesn't specify whether this is a lightweight check or intensive scan, what permissions are required, whether it affects system performance, what format the results take, or if it has rate limits. The description is too vague about the actual behavior beyond the basic purpose.
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, efficient sentence that communicates the core purpose without any wasted words. It's front-loaded with the main action and target, making it immediately clear what the tool does. Every element of the sentence contributes meaningfully to understanding the tool's function.
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?
For a diagnostic tool with no annotations and no output schema, the description is insufficient. It doesn't explain what kind of issues are identified, what the diagnostic output looks like, whether it returns structured data or logs, or how results should be interpreted. Given the complexity of vector storage systems and the lack of structured output information, the description leaves too many open questions about what the tool actually produces.
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 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't mention parameters since none exist. This meets the baseline expectation for a parameterless tool, though it doesn't add any additional context about why no parameters are needed.
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 the action ('Run diagnostics') and target ('on the vector storage system'), with the specific goal 'to identify issues'. It distinguishes from generic health checks like 'checkHealth' by focusing specifically on vector storage. However, it doesn't fully differentiate from 'manageVector' which might also involve vector system operations.
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 like 'checkHealth' (general health) or 'manageVector' (vector management). There's no mention of prerequisites, triggers, or scenarios where this diagnostic should be preferred over other tools. The agent must infer usage context from the tool name alone.
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 carries the full burden. It states the tool generates a banner but doesn't disclose behavioral traits such as whether it's read-only or mutative, what format the banner is in, if there are rate limits, or any side effects. This leaves significant gaps in understanding how the tool behaves.
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, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to understand at a glance.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the generated banner looks like, its format, or how it differs from raw data provided by sibling tools. For a tool that outputs information, more context on the output is needed.
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 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter information, but that's appropriate here, as there are no parameters to explain.
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 the verb 'generates' and the resource 'banner containing memory system statistics and status', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'getMemoryStats' or 'getComprehensiveContext', which might provide similar information in different formats.
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. It doesn't mention when this banner generation is appropriate compared to other tools that retrieve memory statistics or context, leaving the agent without 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 mentions retrieving from 'short-term memory', which implies a read-only operation, but doesn't specify permissions, rate limits, or what 'recent' means (e.g., time frame). This leaves gaps in understanding the tool's behavior beyond basic functionality.
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, efficient sentence that directly states the tool's purpose without any unnecessary words. It is appropriately sized and front-loaded, making it easy to understand at a glance.
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 the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on usage context, behavioral traits, or output format, leaving room for improvement in completeness.
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 100% description coverage, clearly documenting both parameters (importance filter and limit). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for adequate coverage without extra value.
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 the verb ('retrieves') and resource ('recent messages from the short-term memory'), making the purpose understandable. However, it doesn't distinguish this tool from potential sibling tools like 'getRecentEpisodes' or 'getComprehensiveContext', which might also retrieve memory-related data, so it doesn't reach the highest score.
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 like 'getRecentEpisodes' or 'getComprehensiveContext', nor does it mention any prerequisites or exclusions. It simply states what the tool does without contextual usage information.
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 states the tool 'Stores' data, implying a write operation, but doesn't clarify persistence characteristics (e.g., how long messages are retained, storage limits), whether this requires specific permissions, or what happens on success/failure. For a write operation with zero annotation coverage, this leaves significant behavioral gaps.
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, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a simple storage operation and front-loads the essential information without unnecessary elaboration.
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 the tool's moderate complexity (write operation with 3 parameters including nested objects) and no annotations or output schema, the description is minimally adequate but incomplete. It identifies what the tool does but lacks crucial context about behavioral traits, usage scenarios, and return values. The 100% schema coverage helps, but for a write operation with no output schema, more behavioral context would be beneficial.
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?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
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 the action ('Stores') and the resource ('an assistant message in the short-term memory'), making the purpose immediately understandable. It distinguishes from siblings like 'storeUserMessage' by specifying 'assistant' message type. However, it doesn't fully differentiate from other storage tools like 'storeDecision' or 'storeMilestone' in terms of what kind of content is appropriate for each.
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 like 'storeUserMessage', 'storeDecision', or 'storeMilestone'. There's no mention of prerequisites, appropriate contexts, or exclusions. The agent must infer usage from the tool name alone, which is insufficient for optimal 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves statistics, implying a read-only operation, but doesn't specify what statistics are included, format, or any constraints like rate limits or permissions needed. This leaves significant gaps in understanding how the tool behaves.
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, clear sentence that directly states the tool's function without any unnecessary words. It's front-loaded and efficient, making it easy to parse quickly, which is ideal for a tool with no parameters.
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 the tool has no parameters and no output schema, the description is minimally adequate but lacks depth. It doesn't explain what statistics are retrieved or the return format, which could be important for an agent to use the tool effectively. With no annotations and simple schema, more context 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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, but it could have mentioned if any implicit parameters exist (e.g., time range). Since there are no parameters, a baseline of 4 is applied, as the description doesn't need to compensate for missing schema info.
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 the tool's purpose with a specific verb ('Retrieves') and resource ('statistics about the memory system'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'getActiveFiles' or 'getRecentEpisodes', which prevents a perfect score.
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. With sibling tools like 'checkHealth' or 'diagnoseVectors' that might relate to system monitoring, there's no indication of when 'getMemoryStats' is the appropriate choice, leaving usage context unclear.
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 of behavioral disclosure. While it mentions three operations performed, it doesn't describe what 'logging an episode' entails, whether this operation is reversible, what permissions might be required, or how errors are handled. For a tool that appears to perform multiple write operations, this is insufficient 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the main purpose and then lists the three operations performed. Every word earns its place with no redundancy or unnecessary elaboration.
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 tool with 5 parameters (3 required), no annotations, and no output schema, the description provides adequate purpose clarity but lacks sufficient behavioral context. It doesn't explain what happens after the conversation ends, what 'logging an episode' means, or what the tool returns. The combination of multiple operations without behavioral details creates gaps in understanding.
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?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting for parameter documentation.
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 specific action ('Ends a conversation') and lists the three operations performed (storing assistant message, recording milestone, logging episode). It distinguishes this tool from siblings like storeAssistantMessage, storeMilestone, and recordEpisode by combining these functions into one 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 description implies this tool should be used at the conclusion of a conversation to wrap up multiple tasks simultaneously. It doesn't explicitly state when NOT to use it or name specific alternatives, but the context suggests it's for finalizing conversations rather than intermediate steps.
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:

[![cursor10x-mcp MCP server](https://glama.ai/mcp/servers/aiurda/cursor10x-mcp/badges/card.svg)](https://glama.ai/mcp/servers/aiurda/cursor10x-mcp)

Score Badge

Copy to your README.md:

[![cursor10x-mcp MCP server](https://glama.ai/mcp/servers/aiurda/cursor10x-mcp/badges/score.svg)](https://glama.ai/mcp/servers/aiurda/cursor10x-mcp)

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/aiurda/cursor10x-mcp'

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