Prism MCP
Server Quality Checklist
This repository includes a README.md file.
This repository includes a LICENSE file.
Latest release: v2.3.38
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.
This repository includes a glama.json configuration file.
- This server provides 31 tools. View schema
No known security issues or vulnerabilities reported.
This server has been verified by its author.
Tool Scores
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses return values ('concept, confidence, distance, ambiguity, convergence steps') which is helpful given the lack of output schema. However, it fails to clarify operational traits: whether this is read-only, if it modifies session state, or what 'policy-gated' enforcement implies for access control.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with three distinct clauses: the transformation action, the return values, and the usage context. The 'v6.5' versioning is specific but justifiable for API targeting. No redundant or filler text is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description appropriately documents the expected return structure. However, with 7 parameters and complex cognitive routing behavior, the description could better contextualize how the 'state', 'role', and 'action' parameters interact (transition binding) or what constitutes valid concept keys.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description mentions 'HDC compositional state' (relating to the 'state' parameter) and implies the purpose of thresholds via 'policy-gated routing', but does not add significant semantic context beyond what the schema already provides for the 7 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the core action ('Resolve an HDC compositional state into a nearest semantic concept') and mechanism ('policy-gated routing'), distinguishing it from simple search tools. However, 'HDC' jargon and lack of explicit differentiation from siblings like 'session_search_memory' prevent 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a specific use case ('Use this for explainable cognitive recall decisions in v6.5'), indicating when to use the tool. However, it lacks explicit guidance on when NOT to use it or how it differs from the numerous sibling search/recall tools available (e.g., 'knowledge_search', 'session_search_memory').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and successfully discloses the critical constraint that 'Importance cannot go below 0,' which prevents invalid expectations. However, it omits reversibility (can it be undone via upvote?), idempotency, or error handling for invalid UUIDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences with zero waste: the first establishes the core operation and resource, while the second provides essential behavioral constraints. Information is perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema, straightforward mutation), the description is sufficiently complete. It covers the primary behavioral boundary (floor at 0) which is essential for correct invocation, though it could optionally clarify the return value or confirmation behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single 'id' parameter ('The UUID of the ledger entry to downvote'), so the description appropriately relies on the schema rather than duplicating parameter details, meeting the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('decrease its importance') on the resource ('memory entry'), using the verb 'downvote' which distinctly contrasts with sibling tool 'knowledge_upvote' and differentiates from 'knowledge_forget' by emphasizing importance adjustment rather than deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly distinguishes this tool from deletion alternatives by specifying 'decrease importance' rather than removal, but lacks explicit guidance on when to choose downvoting over forgetting, purging, or upvoting, and does not mention prerequisites like entry existence.
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 provided, so description carries full burden. It explains how the knowledge base is populated (automatic extraction from saved sessions) and mentions the enable_trace feature for metadata. However, lacks disclosure on safety (read-only vs destructive), rate limits, or what happens when queries match nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences followed by a structured category list. Front-loaded with action verb. Every sentence earns its place: defines operation, explains data source mechanism, and states use case. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for basic usage but gaps remain given complexity. No output schema is provided, yet the description doesn't explain return format (e.g., what constitutes a 'result'). The complex ACT-R spreading activation feature is documented in the schema but not mentioned in the main description, which could overlook this distinctive capability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). Description adds significant value by enumerating all valid category options (debugging, architecture, etc.) since they are not defined as schema enums. It also contextualizes the query parameter by explaining the full-text search mechanism against session summaries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Excellent specificity with verb 'search' and resource 'accumulated knowledge across all sessions'. Explicitly distinguishes from session-specific siblings by emphasizing 'across all sessions' and 'previous sessions'. Also explains the underlying mechanism (keywords extracted from ledgers/handoffs) which clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use ('find related past work, decisions, and context from previous sessions') and implies scope distinction from session-level tools via 'across all sessions'. Lacks explicit when-not-to-use or named sibling alternatives (e.g., contrast with session_search_memory).
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, placing full disclosure burden on the description. The text explains the purpose ('pattern detection') and data structure, but omits operational details critical for a storage tool: persistence guarantees, immutability, rate limits, or side effects of recording events. It mentions the 'why' but not the operational 'how' or durability constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by a formatted list of event types. Every sentence earns its place: the first establishes function and differentiation, the list provides categorical semantics. No redundancy or filler content is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters with complex behavioral implications and zero annotations, the description adequately covers the event taxonomy but leaves operational gaps. It does not address data retention, queryability, or relationships to the 'knowledge_' sibling tools. For a data persistence tool without output schema, it meets minimum viability but lacks architectural context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the input schema has 100% description coverage (establishing a baseline of 3), the description adds significant semantic value by mapping the 'event_type' enum values to concrete behavioral meanings (e.g., 'correction: Agent was corrected by user'). This contextualizes the raw enum values beyond the schema's generic 'Type of behavioral event' description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb 'Record' and resource 'typed experience event', clearly stating the tool's function. It explicitly distinguishes itself from sibling tool 'session_save_ledger' by contrasting 'structured behavioral data for pattern detection' versus 'flat logs', providing clear scope differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit comparative guidance ('Unlike session_save_ledger...'), indicating when to use this tool versus its alternative for flat logging. It enumerates five specific event types with clear behavioral definitions. However, it lacks explicit 'when not to use' exclusions or prerequisites for the recording operation itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and successfully discloses the business logic: the graduation threshold (>=7), the consequence (always surface in behavioral warnings), and the terminology ('graduated' insights). Missing only edge case handling (e.g., max importance limits).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly constructed sentences with zero waste: first establishes the action and mechanism, second explains the graduation rule and consequence. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter mutation tool without output schema, the description adequately covers the essential domain context (graduation system, importance thresholds). Would need explicit return value description or error behavior to achieve a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'id' parameter fully documented as 'UUID of the ledger entry'. The description uses synonymous term 'memory entry' but does not add syntax, format details, or examples beyond what the schema already provides, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Upvote' with clear resource 'memory entry' and distinguishes from siblings via the unique 'graduation' concept (importance >= 7 threshold) and 'behavioral warnings' outcome, clearly differentiating it from downvote or search operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for effects (increasing importance toward graduation, surfacing in behavioral warnings) which implies when to use it, though it does not explicitly name alternative tools like knowledge_downvote or state exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses critical behaviors: 'overwrites the current handoff state' (destructive to current), 'version number moves forward' (versioning semantics), and 'no data is lost' (safety). Git revert analogy adds implementation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences with zero waste. Front-loaded with action ('Restores'), followed by mechanism/safety details, and ends with clear prerequisite. 'Time travel!' hook is appropriate given the function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriately complete for a 2-parameter tool with no output schema. Explains state mutation, versioning behavior, and prerequisites. Lacks only edge case handling (e.g., conflicts, permissions) to achieve 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing baseline 3. Description mentions target_version in workflow context ('Call memory_history first to find the correct target_version'), but this largely restates the schema's '(get this from memory_history)' rather than adding new semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Restores' with clear resource 'project's memory' and scope 'to a specific past version'. Distinguishes from sibling memory_history by implying restoration vs. viewing history. Git analogy clarifies the version control concept.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit prerequisite workflow: 'Call memory_history first to find the correct target_version' establishes sequencing. Missing explicit 'when not to use' or direct comparison to alternatives like session_forget_memory, but the prerequisite provides strong usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full safety disclosure burden. It successfully reveals critical behavioral traits: uses Gemini for summarization, performs soft-delete (archives originals), preserves recent entries based on keep_recent parameter, and operates via a three-step process. Missing minor operational details like idempotency or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Excellent structure with value proposition front-loaded ('prevents the ledger from growing indefinitely'), followed by numbered mechanics, and ending with the dry_run usage tip. No redundant text; every sentence conveys distinct information about mechanism, safety, or usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (AI involvement, data mutation, 4 parameters) and lack of annotations/output schema, the description adequately covers the process flow and side effects (rollup insertion, archiving). Minor gap in not describing the return value or success indicators, though the dry_run behavior implies output preview capability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, establishing a baseline of 3. The description references parameters narratively (threshold, dry_run, keep_recent behavior) but does not add semantic meaning beyond what the schema already provides, nor does it clarify parameter formats or constraints not covered in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Auto-compact old session ledger entries by rolling them up into AI-generated summaries.' This provides a specific verb (compact/roll up), resource (session ledger entries), and mechanism (AI-generated summaries). It distinguishes from siblings like deep_storage_purge by emphasizing rollup/summarization rather than deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage guidance via 'Use dry_run=true to preview what would be compacted without executing' and explains the value proposition (prevents indefinite growth, keeps loading fast). However, it lacks explicit comparison to siblings like maintenance_vacuum or deep_storage_purge to clarify when compaction is preferred over purging.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It successfully explains key behavioral traits: the image is 'copied' (not moved), stored in 'Prism's media vault,' 'indexed in the handoff metadata,' and made available for future sessions. Missing error handling details or idempotency guarantees, but covers the core persistence and indexing mechanics well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences with zero waste: purpose (sentence 1), use cases (sentence 2), behavioral mechanics (sentence 3), and integration point (sentence 4). Information is front-loaded and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with simple string types and no output schema, the description adequately covers functionality, use cases, storage mechanics, and session continuity. Does not describe return values (acceptable without output schema) or error conditions (minor gap).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing detailed descriptions for all three parameters (project, file_path, description). The description adds minimal semantic value beyond reinforcing 'local' for file_path and the vault storage context for project. With schema doing the heavy lifting, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Save a local image file into the project's permanent visual memory') that clearly distinguishes this from sibling tools like session_save_experience (events) and knowledge_search (facts). It explicitly scopes the tool to 'visual memory' and mentions integration with session_load_context, anchoring it within the session management family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete use cases ('UI states, diagrams, architecture graphs, or bug screenshots') and explains the workflow integration ('On the next session_load_context, the agent will see...'). Lacks explicit 'when not to use' exclusions or direct sibling comparisons (e.g., vs session_view_image), but offers strong positive guidance.
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 full burden. It discloses the creation of 'synthesized_from' links and batch processing behavior, but omits critical mutation details: whether the operation is idempotent, reversible, or if duplicate runs create duplicate edges. Missing safety profile for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly constructed paragraphs with zero waste. The first sentence front-loads the core mechanism (scanning embeddings to create links), while the second provides usage cadence guidance. Every clause conveys distinct operational or contextual information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given high schema coverage and the tool's specific scope, the description adequately covers the graph synthesis concept and batch processing nature. Minor gap: no mention of relationship to similar sibling session_backfill_links or behavior when no high-similarity matches exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing baseline 3. The description adds domain context by referencing 'cosine similarity' (aligning with similarity_threshold), 'newest active entries' (context for max_entries), and 'Step 3A' workflow positioning, enriching raw parameter definitions without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool 'Scans recent project entries with embeddings, finds high-similarity but currently disconnected entries, and creates inferred links as synthesized_from', providing specific verbs (scans, finds, creates), resources (entries, links), and distinguishing this graph-mutation function from sibling search/retrieval tools like session_search_memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context with 'Use this tool periodically' and 'On-Demand Graph Enrichment' indicating when to run it (for discovery of semantic relationships), but lacks explicit 'when-not-to-use' guidance or named alternatives (e.g., contrast with session_backfill_links).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden and discloses: permanent deletion ('permanently deletes ledger entries'), default preservation ('Handoff state is preserved unless explicitly cleared'), safety requirements ('requires confirm_all=true'), and operational modes. Missing idempotency or error behavior details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with front-loaded purpose, bulleted modes for scannability, and prominent warning emoji for destructive behavior. The brain metaphor adds slight length but serves an explanatory purpose. No redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a 6-parameter destructive tool without output schema. Covers all parameters via mode descriptions, safety constraints, and state preservation rules. Could improve by describing return value or success indicators.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage (baseline 3). Description adds semantic value by grouping parameters into logical 'Forget modes' (By project/category/age/Full reset) and clarifying interactions (confirm_all as safety flag for full reset, clear_handoff affecting preservation defaults).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with specific verb+resource ('forget (delete) accumulated knowledge entries') and distinguishes scope via 'session entries' vs 'handoff state'. The metaphor aids intuition without obscuring the technical function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use ('remove outdated, incorrect, or irrelevant session entries to keep the knowledge base clean'). Distinguishes handoff preservation vs clearing, hinting at relationship with session_forget_memory. Lacks explicit 'when not to use' or named sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, description carries full burden excellently: discloses file mutation ('writes into target file'), safety boundaries ('content outside sentinels is never touched'), idempotency guarantees, and sentinel marker mechanics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bold headers demarcating purpose, mechanism, requirements, and idempotency. Slightly verbose but every section earns its place given the complexity of sentinel markers and file-writing behavior that must be communicated without annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a file-writing tool with no output schema: covers fetch logic, formatting behavior, file modification mechanics, and dry_run preview functionality. Missing only return value documentation, which is acceptable given no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage. Description references 'repo_path' connecting to the project parameter requirement and mentions target_file defaults, but primarily relies on schema definitions rather than adding semantic context beyond them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Auto-sync' with clear resource 'graduated insights' and destination 'IDE rules file', distinguishing it from sibling knowledge tools which focus on CRUD operations rather than IDE integration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states requirement that 'project must have a repo_path configured in the dashboard' and explains idempotency behavior. Lacks explicit 'when to use vs alternatives' comparison with siblings, though the unique IDE-sync purpose makes this implicitly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and successfully details the four specific integrity checks performed and the repair behavior of auto_fix. However, it lacks safety disclosure (e.g., whether auto_fix is destructive, if checks lock the memory, or performance characteristics) that annotations would typically provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Perfectly structured: analogy upfront, enumerated list for scannable detail, parameter guidance at the end. No wasted words; every sentence conveys specific behavioral or functional information. Effective use of formatting (bold, list) for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive on input/functionality but has critical gaps given no output schema: it fails to describe what the tool returns (list of violations? summary statistics? success boolean?). For a diagnostic tool, return value description is essential. Also lacks safety warnings for the auto_fix mutation capability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage (baseline 3). The description adds valuable semantic mapping by linking auto_fix to specific issues mentioned in the list ('repair missing embeddings and clean up orphans'), helping the agent understand which of the four checks get remediated versus just reported.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Excellent specificity: 'Run integrity checks on the agent's memory' provides clear verb + resource. The fsck analogy immediately distinguishes this from siblings like maintenance_vacuum or session_compact_ledger by positioning it as a diagnostic/verification tool rather than optimization or storage management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context through the fsck analogy (implying maintenance/diagnostic use) and explicit guidance on the auto_fix parameter ('Use auto_fix=true to...'). However, lacks explicit when-to-use guidance versus similar maintenance siblings (e.g., 'Run this before compaction' or 'Use instead of vacuum when checking for corruption').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Critically discloses return format 'Base64 inline content for the LLM to analyze' which compensates for missing output schema. Implies read-only nature via 'Retrieve' but doesn't explicitly confirm no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: purpose (sentence 1), behavior (sentence 2), workflow guidance (sentence 3). Well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for complexity level: 2 simple parameters with 100% schema coverage. Description compensates for missing output schema by detailing Base64 return format. No gaps given the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage (project and image_id fully documented). Description references 'its ID' but adds no semantic detail beyond what schema already provides. Baseline 3 appropriate when schema does heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb (Retrieve) + resource (image from visual memory) + mechanism (using ID). Clear distinction from sibling session_save_image and session_search_memory tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisite workflow: 'Use session_load_context first to see available image IDs.' Provides clear sequencing guidance, though lacks explicit 'when not to use' exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden and effectively explains: soft-deletion (archived) versus hard delete, execution frequency (startup + 12-hour intervals), and important exclusions (rollup/compaction entries never expired). Could clarify whether soft-deleted items are recoverable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Excellent structure with front-loaded purpose statement, bulleted use cases, and a dedicated 'Note' section for exceptions. No filler text; every sentence provides specific behavioral or configurational information. Bold headers improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter configuration tool with no output schema, the description comprehensively covers the policy mechanism, timing, and data exceptions. Minor gap regarding error handling when minimum 7 days is violated (mentioned in schema but not described behaviorally), but sufficient for agent invocation decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing baseline 3. Description adds valuable semantic context through use cases: interpreting 'ttl_days: 90' as '3 months' and explicitly stating that '0' disables auto-expiry, helping agents understand the domain meaning beyond raw integer values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Set') + resource ('automatic data retention policy/TTL') + scope ('project's memory'), clearly distinguishing this configuration tool from sibling deletion tools like 'deep_storage_purge' or 'knowledge_forget' through its focus on automated policy rather than immediate action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete use cases (90 days for 3-month expiry, 0 to disable) and explains the soft-deletion mechanism, implicitly guiding users toward this for automated archival versus manual deletion alternatives. Lacks explicit 'when not to use' or named alternative references, but the behavioral context (automatic vs manual) is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses output structure ('Shows version numbers, timestamps, and summaries') compensating for missing output schema. Implies read-only nature via 'View' but doesn't explicitly state safety or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences structured efficiently: purpose (sentence 1), usage guidance (sentence 2), and behavioral disclosure (sentence 3). Front-loaded with action verb, zero redundancy, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple 2-parameter schema and lack of output schema, description adequately explains return values and sibling relationships. Could improve by mentioning handling of non-existent projects or pagination behavior, but sufficient for tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, documenting both 'project' and 'limit' parameters completely. Description references 'this project' loosely mapping to the project parameter but doesn't add syntax, format details, or examples beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'View' with resource 'timeline of past memory states' and scope 'for this project'. It clearly distinguishes from sibling memory_checkout by contrasting timeline viewing versus version reverting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the sequencing rule 'Use this BEFORE memory_checkout' and explains the specific purpose 'to find the correct version to revert to', providing clear navigation guidance between related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses vector embedding mechanism, pgvector dependency, and advanced features like ACT-R spreading activation and memory trace metadata. Missing only error handling or rate limit details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly structured sentences. First establishes mechanism and requirements; second provides usage guidelines. Zero redundancy—every clause conveys distinct information about functionality, prerequisites, or sibling relationships.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a complex 7-parameter tool with nested objects. Covers search mechanism, infrastructure requirements, and sibling differentiation. Minor gap: no output description (relevant since no output schema exists), though enable_trace parameter partially hints at return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing baseline 3. Description provides conceptual context (semantic vs keyword) that supports understanding the query parameter and mentions spreading activation, but does not add significant parameter-specific semantics beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb ('Search') and resource ('session history semantically'), clearly distinguishing from keyword-based alternatives. Explicitly contrasts vector embeddings vs exact wording matching, establishing precise scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance ('use this when keyword search returns no results or when the query is phrased differently') and names the specific alternative tool (knowledge_search). Also notes prerequisite (pgvector extension).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Excellently discloses: security handling (API keys redacted), scope limitations (visual descriptions without raw files), side effects (auto-generated filenames 'prism-export-<project>-<date>.ext'), and prerequisites (output directory must exist/be writable).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Despite length, every section earns its place. Uses bold headers and bullet points for scannability. Front-loaded with core purpose, followed by content specifications, format comparisons, and prerequisites. No redundant or tautological statements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive coverage of export content, format behaviors, and file system side effects compensates for lack of output schema. Minor gap: does not explicitly state what value the tool returns to the caller (e.g., file path confirmation) after execution.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing baseline 3. Description elevates this by adding rich semantic context for the 'format' enum (explaining Vault format includes YAML frontmatter and Wikilinks for Obsidian/Logseq) and clarifying the filename auto-generation pattern not specified in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with specific verb 'Export' and clear resource 'project's memory to a local file', distinguishing it from sibling tools like session_search_memory (query) or session_forget_memory (deletion). The GDPR Article 20 and 'local-first' portability context further clarifies the unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear contextual guidance for when to use (GDPR data portability requests, static archiving) and extensively documents format selection criteria (JSON for machine import, Markdown for human reading, Vault for Obsidian). Lacks explicit contrast with sibling alternatives like session_save_experience.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure. It reveals critical runtime traits: synchronous execution ('runs synchronously so you will know when it is safe'), duration ('up to 60 seconds'), backend-specific behavior (local vs. Supabase), and mechanical details ('SQLite reclaims page allocations only when explicitly vacuumed').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four tightly focused paragraphs with zero filler: 1) Purpose, 2) Prerequisites/mechanics, 3) Backend exceptions, 4) Performance warning. Every sentence advances understanding; the synchronous warning is bolded for visibility. Excellent information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a maintenance tool with no output schema, the description comprehensively covers prerequisites (deep_storage_purge), execution model (synchronous, 60s duration), environmental constraints (local SQLite vs remote Supabase), and safety implications. No gaps remain for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents the `dry_run` parameter. The main description text does not mention the parameter or add usage examples beyond what the schema provides. Baseline 3 is appropriate when the schema carries the full semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Reclaim disk space') and resource ('SQLite database'), clearly stating the tool performs VACUUM operations. It distinguishes from siblings by explicitly referencing `deep_storage_purge` as the prerequisite operation, clarifying this is a compaction follow-up rather than a general maintenance tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance ('Best called after `deep_storage_purge` removes many entries') and contextual prerequisites. Also clarifies backend limitations ('For remote (Supabase) backends, returns guidance...'), effectively stating when not to use the tool for actual vacuuming and what alternative path to take.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, description carries full burden admirably. Discloses three specific algorithmic strategies (Temporal Chaining, Keyword Overlap, Provenance), implementation safety ('INSERT OR IGNORE'), and idempotency ('safe to re-run multiple times').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Excellent structure with clear sections: purpose statement, enumerated strategies, safety note, and usage guidelines. Markdown formatting aids scannability. Zero redundant content; every sentence provides unique operational context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex graph-building maintenance tool with no output schema, description provides complete operational context: algorithms explained, safety guarantees stated, upgrade scenario documented, and scope limitations clarified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for the single 'project' parameter. Description contextualizes the parameter ('for all existing entries in a project') but does not need to add syntax details given complete schema documentation. Baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb ('Retroactively create') + resource ('graph edges/memory links') + scope ('all existing entries in a project'). Explicitly contrasts with automatic linking of 'new entries' to distinguish from session_save_experience and siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit '**When to use:**' section identifies specific trigger ('after upgrading to v6.0'). Clear negative guidance ('no manual action needed') for new entries, establishing when NOT to use it versus normal save operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, description carries full burden and excels: explains tombstoning mechanism, audit trail retention, search exclusion behavior, irreversibility of hard delete, and GDPR compliance context. No contradictions with missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Excellent structure with markdown formatting: opening purpose statement, bullet points contrasting the two behavioral modes, and a prominent warning emoji for the recommendation. Zero wasted words; every sentence provides actionable guidance or behavioral disclosure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the legal/compliance complexity (GDPR) and lack of annotations, description provides complete behavioral context including reversibility, audit implications, and specific regulatory triggers. No output schema exists, but description adequately covers operational semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, establishing baseline 3. Description references 'by its ID' (memory_id) and GDPR Article 17 (reason parameter), but primarily relies on comprehensive schema descriptions rather than adding significant semantic interpretation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with specific verb ('Forget (delete)') and resource ('specific memory entry by its ID'). The term 'memory' distinguishes this from sibling 'knowledge_forget' and 'deep_storage_purge', while 'by its ID' distinguishes from bulk operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use hard delete ('Use only when GDPR Article 17 requires complete erasure') and explicitly recommends soft delete for 'most use cases'. Notes reversibility as a decision factor ('can be restored in the future').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, description carries full disclosure burden excellently: quantifies storage reclamation (~90%), specifies safety thresholds (7/30 days), guarantees Tier-2 search accuracy (95%+), declares Tier-3 immunity, and explains dry_run preview behavior. Explicitly states 'NEVER touched' entries without compressed blobs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Excellent structure with markdown headers ('When to use', 'Safety') and front-loaded key constraints. Three paragraphs cover: operation mechanics, workflow integration, and safety guarantees without redundancy. Every sentence conveys critical behavioral or workflow information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive storage operation with no output schema, description comprehensively covers workflow prerequisites, accuracy trade-offs, reversibility constraints (dry_run vs execution), and search tier impacts. Missing only explicit output schema details, which don't exist in the definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3. Description adds value by explaining semantic implications: older_than_days protects 'Tier-1 native vector search' for recent entries, and dry_run 'previews impact' before executing. This operational context exceeds raw schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description provides specific verb ('purge') and resource ('high-precision float32 embedding vectors'), clearly distinguishing this storage optimization tool from sibling knowledge/memory management tools. The v5.1 Deep Storage Mode prefix and TurboQuant context establish unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Contains explicit '**When to use:**' section stating prerequisite workflow (after TurboQuant backfill). Names prerequisite tool (session_backfill_embeddings) and establishes clear sequencing. Dry_run recommendation provides clear safety alternative.
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:
Score Badge
Copy to your README.md:
How to claim the server?
If you are the author of the server, you simply need to authenticate using GitHub.
However, if the MCP server belongs to an organization, you need to first add glama.json to the root of your repository.
{
"$schema": "https://glama.ai/mcp/schemas/server.json",
"maintainers": [
"your-github-username"
]
}Then, authenticate using GitHub.
Browse examples.
How to make a release?
A "release" on Glama is not the same as a GitHub release. To create a Glama release:
- Claim the server if you haven't already.
- Go to the Dockerfile admin page, configure the build spec, and click Deploy.
- Once the build test succeeds, click Make Release, enter a version, and publish.
This process allows Glama to run security checks on your server and enables users to deploy it.
How to add a LICENSE?
Please follow the instructions in the GitHub documentation.
Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear on the server after some time, you can manually trigger a new scan using the MCP server admin interface.
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.
Latest Blog Posts
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/dcostenco/BCBA'
If you have feedback or need assistance with the MCP directory API, please join our Discord server