pathmark

Server Quality Checklist

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

Latest release: v0.1.15
Disambiguation2/5
Several retrieval tools overlap heavily: search_memory, get_context, recall_memory, ask_memory, and chat all serve similar recall purposes, with ask_memory and chat being nearly identical. audit_memory and doctor_memory also share duplicate/stale reporting territory, making misselection likely.
Naming Consistency4/5
Most tools follow a clear verb_noun snake_case pattern such as create_conclusion, approve_conclusion, backup_memory, and export_memory. Minor exceptions like 'remember' and 'chat' are bare verbs, but they are recognizable and do not undermine the overall consistency.
Tool Count3/5
At 25 tools, the server is at the heavy end of the borderline range. Many tools cover distinct lifecycle, audit, and maintenance operations, but the sheer number may overwhelm agents and increases the chance of selecting the wrong tool.
Completeness4/5
The tool surface is very comprehensive, covering raw capture, conclusion workflows, recall, audit, maintenance, backup, and export. Minor gaps exist, such as no explicit import counterpart to export_memory and no direct get-by-id tool, but agents can work around these with search and update operations.
Average 3.2/5 across 25 of 25 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 72 commits in the last 12 weeks
- Last stable release on September 4, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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?
With no annotations, the description must disclose behavioral traits. It only says 'compact local memory context' without specifying if it is read-only, what side effects exist, or what 'compact' entails (e.g., summarization). This is insufficient for informed selection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but too terse for the tool's complexity. It omits essential details about parameters and use cases, making it under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, no output schema, and many sibling tools, the description is grossly incomplete. It does not explain what the tool returns, how to use parameters, or how it relates to siblings like 'search_memory' or 'recall_memory'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about any of the 5 parameters. Schema coverage is only 20% (only 'query' has a description). The agent must infer the meaning of 'kind', 'tags', 'limit', and 'namespace' from the schema alone, which is insufficient.
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 ('Return') and resource ('compact local memory context') for a task or question. It differentiates from siblings like 'search_memory' by specifying 'compact' context, but does not fully clarify how it differs from 'recall_memory' or 'ask_memory'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool vs alternatives like 'search_memory' or 'recall_memory', nor any conditions or limitations.
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?
The term 'soft-delete' hints at non-destructive behavior, but with no annotations, the description should more clearly explain what happens to the memory (e.g., is it recoverable? Does it affect related conclusions?). It does not address side effects, authorization needs, or data retention.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it lacks structure. It fits for a simple tool, but could benefit from additional context about the soft-delete behavior or return format.
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 low complexity (one required parameter, no output schema), the description should cover basics like what the 'id' refers to and what happens after deletion. It mentions 'soft-delete' but omits details about restoration or confirmation, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single parameter 'id' with no description. The tool description says 'by id' but does not clarify whether this is a memory ID, conclusion ID, or something else. With 0% schema coverage, the description fails to add meaning beyond the schema, leaving agents uncertain about acceptable values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('soft-delete') and identifies the resource ('memory or conclusion by id'), making the tool's action clear. It distinguishes from siblings like 'create_conclusion' and 'list_conclusions', but could be more explicit about its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as when a hard delete might be needed or how it differs from 'remember' or 'ask_memory'. The description lacks context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions a key behavioral trait: preserving prior versions in history. However, with no annotations, it fails to disclose other important aspects such as idempotency, error handling (e.g., memory not found), or return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the core function. It is well-structured and front-loaded, though it could be slightly expanded without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no output schema, and no annotations, the description is grossly incomplete. It lacks information about return values, side effects, prerequisites, or behavior for edge cases, leaving the agent with significant uncertainty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and no parameter details in the description, the agent receives no added meaning beyond the raw schema field names. The description does not explain the purpose or constraints of any of the 6 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'correct' with the resource 'memory', clearly indicating the action of updating an existing memory. It distinguishes from siblings like 'delete_memory' and 'supersede_memory' by implying a less destructive operation, but could be more explicit about what 'correct' entails.
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 its siblings. For example, there is no comparison with 'supersede_memory' or 'delete_memory' to help the agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks any behavioral details (e.g., search algorithm, scope, side effects). The description is too minimal to be useful.
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 front-loaded sentence, which is concise. However, the brevity comes at the cost of missing critical details.
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?
With 5 parameters and no output schema or annotations, the description is insufficient. It omits return format, how to use kind/tags/namespace, and other essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only query has a description). The description does not add meaning for kind, tags, limit, or namespace, leaving most parameters unexplained.
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 'Search saved local memories and conclusions' clearly states the action and resource, but fails to distinguish from sibling tools like recall_memory or ask_memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as recall_memory or ask_memory, nor any exclusions or prerequisites.
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 mentions 'preserving history' but does not detail side effects, authorization needs, or what happens to the old memory (e.g., archived, linked). Lacks transparency on behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, which is brief but severely underspecified. It sacrifices clarity and completeness for brevity, making it insufficient for an agent to use effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, the description is highly incomplete. It does not cover parameter usage, return values, or edge cases, leaving the agent with insufficient information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fails to explain any of the 7 parameters (id, text, kind, tags, source, expiresAt, namespace). It adds no meaning beyond the schema, which is sparse. Essential information like required fields is missing.
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 it replaces an outdated memory with a linked current record while preserving history. The verb 'replace' and resource 'memory' are specific, and it distinguishes from siblings like update_memory by emphasizing history preservation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for outdated memories that need replacement while keeping history, but it does not explicitly state when to use this tool over alternatives like update_memory or delete_memory. No exclusions or scenarios are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context: the prioritization of approved conclusions and the return format including provenance and recallId. However, it does not disclose read-only nature, permissions, rate limits, or any side effects, leaving gaps for a query tool without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose and return values. It is efficiently worded with no filler, though it could benefit from a structured breakdown of parameters and usage guidance.
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 5 parameters, no annotations, and no output schema, the description is far from complete. It omits parameter semantics, usage alternatives, error conditions, and any safety or permission context. An agent would be under-equipped to invoke this tool correctly without opening the schema and guessing at parameter meaning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It fails to explain any of the 5 parameters: 'kind', 'tags', 'limit', 'namespace', and even 'question' is only implied by the tool name. The phrase 'scoped or explicitly requested raw evidence' hints at scoping but does not map to specific parameters like tags or namespace. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool asks memory, specifying an order ('approved conclusions first, then scoped or explicitly requested raw evidence') and the return fields ('answer, exact provenance, recallId'). It is a specific verb+resource, but does not explicitly differentiate from sibling tools like search_memory or recall_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 implies this is the primary ask tool but provides no explicit guidance on when to use it versus alternatives like search_memory or recall_memory. It mentions an ordering of retrieval but not when this tool is preferred over others, and no exclusions or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully cover behavioral traits. It states 'point-in-time copy' but does not disclose whether the operation is safe, requires permissions, or affects the original store. Minimal 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?
One sentence, zero waste. Concise and front-loaded with the key action.
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, schema description, and output schema, the description is too brief. It does not explain return values, format, or side effects, leaving the agent with incomplete information for a backup operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'destination' has no schema description (0% coverage) and the description does not explain its meaning (e.g., file path, URL). The agent cannot infer how to set this parameter correctly.
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 ('create') and resource ('point-in-time copy of the canonical local JSONL store'), distinguishing it from siblings like export_memory and purge_memory. However, 'canonical local JSONL store' could be more explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., export_memory) or when not to use it. The description provides no context about prerequisites 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?
Annotations are all false (readOnlyHint false, destructiveHint false, etc.), so the description must carry behavioral disclosure. It implies a write operation (attaching labels) but doesn't explain side effects, reversibility, or response format. The link to audit_memory suggests downstream effects but lacks detail.
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, compact sentence with no fluff. It front-loads the primary action. However, it could be structured to include more critical details without losing conciseness, such as clarifying the purpose of relevant/irrelevant IDs.
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 4 parameters, no output schema, and minimal annotations, the description is inadequate. It doesn't explain what a 'Pathmark recall' is, how relevantIds and irrelevantIds should be populated, or what the tool returns. An agent would struggle to invoke it correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only recallId has a description). The description does not explain note, relevantIds, or irrelevantIds beyond the vague 'relevance labels'. With low coverage, the description should compensate but doesn't, leaving agents guessing about parameter meaning and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (attach relevance labels) on a specific resource (one exact Pathmark recall) and ties it to audit_memory's precision reporting. This is clear enough to understand the core function, though it doesn't explicitly differentiate from siblings like recall_memory or update_memory.
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. The mention of audit_memory implies a workflow but doesn't state when to choose rate_recall over other memory operations or what conditions warrant it. No exclusions or alternative tools are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only says 'List', omitting any behavioral details like whether it returns all conclusions, pagination behavior, or side effects. Agent has to infer from name alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely terse at 3 words, it is under-specified rather than concise. A minimal description may omit critical information needed for correct usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and undocumented parameters, the description is insufficient. It only states the basic function, lacking details on how parameters affect output or what the response contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage and the description adds no information about the three parameters (tags, limit, namespace). Agent must rely on parameter names, which are somewhat clear but lack usage context.
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?
Description clearly states the verb 'List' and resource 'saved durable conclusions', making the tool's purpose immediately understandable and distinct from siblings like create_conclusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings such as recall_memory or search_memory. The description does not provide any 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.
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 the retrieval precedence (approved conclusions before raw), the fallback condition, and the return components (answer, provenance, recallId). It does not mention side effects, permissions, or failure modes, but it covers the most relevant behavioral aspects for a chat 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 sentence with no redundant wording. It front-loads the core purpose and includes return information, which is efficient. It is appropriately concise, though the brevity contributes to the lack of parameter coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters, no schema descriptions, no output schema, and no annotations, the description is far from complete. It does not explain how to construct a valid request (e.g., what 'kind' options mean, how 'limit' behaves, or what 'namespace' refers to), leaving an agent without enough information to call the tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions none of the five parameters (kind, tags, limit, question, namespace). The agent receives no guidance on how to fill these fields, making the tool difficult to invoke correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Chat') and resource ('Pathmark'), and specifies a behavioral nuance ('using approved conclusions first... raw fallback'). It conveys the tool's function but does not explicitly differentiate from sibling tools like search_memory or recall_memory, so it is clear but not maximally distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'using approved conclusions first and only scoped or explicitly requested raw fallback' implies when to use this tool (when a conversational answer grounded in approved conclusions is needed). However, it does not state when not to use it or name alternatives, so guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions 'scoped, mergeable' without disclosing behavioral traits such as whether the export is destructive, authentication needs, rate limits, or 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words, but given the tool's complexity (6 parameters), slightly more structure would improve clarity without sacrificing 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?
With 6 parameters, low schema coverage, no output schema, and no annotations, the description is insufficient to fully define the tool's behavior, especially compared to 17 sibling tools that may overlap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one of six parameters (encrypted) has a description in the schema; the description does not explain parameters like 'kind', 'tags', or 'namespace', failing to compensate for the 17% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear action ('export'), resource (memory), output format ('JSONL bundle'), and target ('another Pathmark installation or trusted sync transport'), distinguishing it from siblings like backup_memory or compact_memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for exporting to another Pathmark installation but does not specify when to use this tool over alternatives like backup_memory or recall_memory, nor provide conditions or 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?
Annotations already indicate idempotentHint=true, readOnlyHint=false, and destructiveHint=false. The description adds valuable behavioral context: 'Proposals are never auto-approved' and the dependency on server synthesis configuration. This goes beyond annotation disclosure without contradicting it.
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 two sentences, front-loaded with the primary action, and avoids unnecessary detail. It is concise and structured, though it sacrifices some explanatory depth for 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?
With 7 parameters, no output schema, and low schema coverage, the description is insufficient for an agent to call this tool correctly. It does not explain the meaning of the parameters, the expected return structure, or the conditions under which staging occurs. Significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29% (only apply and cursor have descriptions). The tool description fails to explain any of the parameters (days, tags, namespace, maxProposals, evidenceLimit), leaving the agent without meaning beyond the schema. Given the low coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: preparing a bounded unsynthesized evidence batch and optionally previewing/staging proposals. It distinguishes from sibling tools like create_conclusion and approve_conclusion by emphasizing staging and no auto-approval. However, terms like 'unsynthesized' are somewhat jargon-heavy but still convey a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a conditional context ('when server synthesis is configured') but does not explicitly state when to prefer this over alternatives like create_conclusion or list_pending_conclusions. It implies staging use but lacks explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It clearly states the approval requirement and the durable nature of the conclusion, which is valuable. However, it does not mention what happens on rejection or if the conclusion can be edited, but the core behavior is transparent enough for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose and then adds the approval condition. It is efficient with no filler, making it easy to parse. However, it is very brief and could potentially include more context without becoming verbose.
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?
With six parameters, no annotations, and no output schema, the description is too sparse to be complete. It does not explain the significance of namespace, source, expiresAt, or evidenceIds, nor does it clarify how the approval workflow integrates with sibling tools like approve_conclusion. An agent would likely need additional context to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 33%, and the tool description does not mention any of the parameters. It fails to explain tags, source, expiresAt, namespace, or evidenceIds, leaving the agent without guidance on how to use these fields. The description adds no semantic value beyond what the schema already provides for the text parameter.
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 proposes a durable, higher-signal conclusion, using a specific verb (propose) and resource (conclusion). It distinguishes itself from sibling tools like remember or recall_memory by focusing on conclusions rather than raw memories, though it could be more explicit about the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that approval is required by default before recall, which implies it is for long-term conclusions needing review. However, it does not explicitly state when to use this tool over alternatives like remember or list_conclusions, nor does it name specific alternatives or conditions for choosing them.
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?
Annotations already cover readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's main contribution is the 'bounded' nature and the restriction to 'approved canonical conclusions only'. It adds useful behavioral context without contradicting the annotations, though it does not describe return format or edge cases.
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 sentence with no waste. It front-loads the primary action and scope, making it easy to parse quickly. 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 large sibling set and the lack of parameter semantics and usage guidance, the description is not complete enough for an agent to confidently choose and invoke this tool. The core purpose is clear, but the absence of parameter explanations and differentiation from alternatives leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full responsibility for explaining the three parameters (tags, charLimit, namespace). The description mentions none of them, leaving the agent to infer meaning from parameter names alone. This is a significant gap for a tool with three optional parameters.
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 states a specific verb ('Generate') and resource ('snapshot') with clear scoping ('USER/PROJECT/AGENT') and a precise constraint ('approved canonical conclusions only'). This clearly distinguishes it from siblings like search_memory or recall_memory, which may include unapproved content, and from creation 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 does not provide any guidance on when to use this tool versus the many sibling tools (e.g., get_context, recall_memory, search_memory). It implies a use case through the 'approved conclusions only' clause, but there is no explicit when-to-use or when-not-to-use guidance, nor any mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It conveys that the tool is a read-like operation ('recall') and that it shows which memories were used, which is the core behavior. However, it does not mention potential side effects, performance implications, or any caveats (e.g., the unbounded includeRecords parameter), leaving some behavioral ambiguity.
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 two sentences with no fluff, front-loading the core purpose and then the usage context. It is appropriately concise, though the first sentence ('Transparent recall for any MCP-capable harness') is slightly abstract and could be more concrete without losing 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 tool has 7 parameters, no output schema, and no annotations, the description is too sparse. It does not explain what the return structure looks like, the role of namespace or kind, or any prerequisites. An agent would likely struggle to use this tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 57%, meaning several parameters (kind, limit, namespace) lack descriptions in the schema. The tool description adds no parameter-level meaning; it only states the overall purpose. Since it does not compensate for the undocumented parameters, it scores low on this dimension.
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: to recall memories and show exactly which ones were used, with a specific usage context ('at task start or before answering'). This is a clear verb-resource-purpose combination, but it does not explicitly distinguish itself from siblings like search_memory or get_context, so it misses the top score.
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?
It gives explicit timing guidance ('Use this at task start or before answering'), which is a clear context for when to use it. However, it does not mention when not to use it or name any alternative tools, so it falls short of the 5-point requirement for 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?
In the absence of annotations, the description discloses key behaviors: the tool can preview or permanently remove records, and it creates a backup before an applied purge. It does not, however, detail the permanence of removal or the recovery process from backup, but overall transparency is good.
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 two sentences: the first states the purpose, the second adds a critical behavioral detail (backup). It is front-loaded, efficient, and contains no redundant 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?
With 6 parameters, no output schema, and no annotations, the description is too brief. It does not explain what the preview returns, behavior with no matching records, the backup process, or constraints on filters. More detail is needed for adequate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17% (only 'confirm' has a description). The tool description adds the concept of 'matching records' to imply filtering, but it does not explain the semantics or formats of the other five parameters (id, tags, before, source, namespace). This leaves significant ambiguity for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb-resource pair ('Preview or permanently remove matching records from the canonical store') making the tool's core action clear. However, it does not explicitly distinguish itself from sibling tools like 'delete_memory' or 'compact_memory', which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a two-step workflow (preview with confirm=false, apply with confirm=true) but provides no explicit guidance on when to use this tool over alternatives (e.g., delete_memory) or conditions to avoid using it. No exclusions are mentioned.
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?
Adds meaningful context beyond annotations: the fact that pending records are never returned by normal memory search is a useful behavioral caveat. With readOnlyHint, idempotentHint, and destructiveHint already set, the description enriches understanding by clarifying scope and visibility, though it omits pagination or ordering 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, no filler. The extra sentence adds a valuable behavioral distinction without verbosity.
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?
Adequate for a simple list operation given annotations cover safety, but lacking parameter semantics and explicit sibling differentiation. An agent could call it correctly with defaults, but would be unsure about filtering options and when to prefer it over list_conclusions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not compensate. It fails to explain any of the four parameters (tags, limit, offset, namespace), leaving an agent with no guidance on how to filter or paginate. This is a significant gap given the low 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?
States a specific verb 'List' and a resource 'bounded approval-gated conclusion proposals', which clearly conveys the core function. The added note that pending records are never returned by normal search helps distinguish it from search_memory, but it does not explicitly differentiate from sibling list_conclusions, leaving slight ambiguity about the exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies this is the tool for pending conclusions via the phrase 'approval-gated' and the note about normal search, but provides no explicit when-to-use vs alternatives like list_conclusions. It does not state exclusions or conditions that would guide selection between sibling tools.
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?
Discloses preview vs apply modes and backup creation, which are important behavioral traits. However, lacks detail on side effects (e.g., irreversibility after apply beyond backup, performance impact). No annotations provided, so description carries full burden; this is adequate but not comprehensive.
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?
Two sentences, front-loaded with key action and followed by critical side-effect (backup). No redundant phrasing; 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 no annotations, no output schema, and 0% schema coverage, the description should provide more operational context (e.g., how retentionDays interacts with time, preview vs apply behavior, confirmation steps). Current description leaves agents guessing about parameter details and tool 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?
With 0% schema description coverage, description adds meaning by linking 'deduplication' to the dedupe parameter and 'deleted-record purging' to dropDeleted. retentionDays is mentioned but not explained (no unit or effect). confirm parameter is entirely absent from description, leaving its purpose unclear.
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?
Description clearly states verb 'Preview or apply' and resource 'memory store', listing specific operations: deduplication, expired-record removal, retention, and deleted-record purging. It distinguishes from siblings like purge_memory (all-out removal) and doctor_memory (checkup) by specifying exact compaction actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for cleaning up memory through deduplication and retention, but no explicit when-to-use or when-not-to-use. With many sibling tools (e.g., purge_memory, doctor_memory), more guidance on choosing this over alternatives would improve usability.
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?
Annotations already cover read-only, destructiveness, and idempotency, but the description adds 'atomic and auditable' traits that are not in the annotations. This provides useful behavioral context beyond the structured metadata.
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?
Two sentences with no waste. The core action is front-loaded, and the optional correction detail follows naturally. The structure is tight and efficient.
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 six parameters and no output schema, the description is too thin. It omits required parameter semantics (especially id), optional fields like note and decidedBy, and any error or edge-case behavior. The low schema coverage makes this a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for parameter meaning. It mentions 'text or tags' but leaves id, note, decidedBy, and namespace unexplained. This is a partial but insufficient compensation for a 6-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Approve') and the resource ('one pending conclusion'), and distinguishes it from siblings like reject_conclusion or list_pending_conclusions. It also notes optional corrections, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies when to use it (to approve a pending conclusion) but does not explicitly state when not to use it or name alternatives such as reject_conclusion or create_conclusion. The guidance is clear but not explicit about 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing the safe, non-mutating nature. The description adds value by detailing what behavioral aspects it measures (capture-to-recall behavior, duplicate rate, stale raw hits), which is context beyond the annotations. It does not contradict any annotation and provides a clearer picture of the tool's analytical focus, though it stops short of describing output structure or 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the primary action ('Measure') and lists the key metrics immediately. There is no filler or repetition. It earns every word and remains easily scannable, ideal for an AI agent parsing tool definitions.
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 three parameters, no output schema, and zero schema coverage, the description leaves critical gaps. It lists what metrics are measured but does not specify the return format, how parameters affect the results, or what constitutes a valid invocation. An agent cannot confidently construct a request without additional external knowledge. The complexity is moderate, but the lack of parameter and output documentation makes this incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the three parameters (days, tags, namespace). It does not explain what these parameters control or how they influence the audit. The parameter names are somewhat intuitive, but without semantic detail an agent cannot determine how to set values to achieve a desired audit scope. This is a significant gap given no output schema exists either.
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 states a specific verb ('Measure') with a clear resource ('memory') and enumerates concrete metrics (capture-to-recall, unused records, recall age, etc.). It also explicitly distinguishes itself by noting 'without changing memory,' which sets it apart from mutation tools like update_memory or delete_memory. This gives an agent an unambiguous understanding of the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a usage context (auditing memory metrics) but does not explicitly state when to prefer this over siblings like get_memory_snapshot or search_memory. It lacks a 'when not to use' or alternative tool references, leaving the agent to infer that this is for analytical insights rather than retrieving raw data. The phrase 'without changing memory' hints at a read-only analysis use case, but no direct routing guidance is provided.
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?
Annotations already declare destructiveHint=true, but the description adds critical nuance: the conclusion is not deleted but retained in the audit trail and excluded from recall. This is valuable behavioral context beyond the annotation, clarifying the exact 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every clause adds meaning: the action, the target, and the two key side effects (audit trail retention and recall exclusion).
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?
While the core behavior is stated, the description omits parameter semantics and does not mention prerequisites like the id being required or the conclusion being pending. For a destructive tool with no output schema, this is insufficient for an agent to call it correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not mention any of the three parameters (id, note, decidedBy). The agent is left without any meaning for these fields, which is a significant gap for a destructive operation that requires an id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (reject), resource (pending conclusion), and the specific behavior: retaining it in the canonical audit trail and excluding from recall. This distinguishes it from siblings like approve_conclusion, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for pending conclusions that need rejection, but it does not explicitly contrast with approve_conclusion or other alternatives. No when-to-use or when-not-to-use guidance is provided, leaving the routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear full weight. It discloses that the audit trail is bounded and includes redacted outputs, suggesting read-only behavior. However, it does not mention auth needs, rate limits, or whether session data might be destroyed. The description is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core information without waste. Every part is substantive.
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?
The tool has 3 parameters and no output schema. The description lists some return elements but does not specify return format, error behavior (e.g., missing sessionId), or how the bounding works. Adequate for a straightforward tool, but additional detail would improve it.
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 67%, with descriptions for sessionId and includeOutputs. The tool description adds no additional parameter context. The 'limit' parameter lacks a schema description, and the description does not compensate. Baseline is 3 for this coverage level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows a bounded chronological audit trail for a session, specifying its contents (prompts, memory IDs, redacted inputs/results, answers). This distinguishes it from memory management and chat siblings, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting session history, which is clear given the sibling context. However, it does not explicitly state when not to use it or provide alternatives, though the purpose is self-evident.
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?
Explicitly declares read-only behavior ('without changing data'), which is critical. Lists specific categories reported, though does not detail what 'index health' means or any performance considerations.
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 of 9 words, perfectly concise and front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers the tool's purpose and scope given its simplicity (0 params, no output schema). Lists all reported categories, though lacks definitions for each metric.
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?
No parameters exist; schema coverage is 100%. Description adds no parameter info as none are needed, meeting baseline for zero-parameter tools.
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?
Clearly states verb 'report' and resource 'memory store health counts' for specific categories (duplicate, deleted, etc.), distinguishing from siblings that perform different operations like deletion or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies diagnostic use via 'report' and 'without changing data', but lacks explicit when-to-use guidance compared to alternative tools like ask_memory or 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 present, so the description carries the full burden. It adds useful behavioral context by calling the memory 'raw' and 'searchable' and implying this path is not the approval-gated one. However, it does not disclose return behavior, persistence semantics, idempotency, or whether saves are immediately visible to recall tools.
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?
Two short sentences with the core action front-loaded and the routing guidance immediately after. There is no filler or redundant restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter and full schema coverage, the description is largely complete. Minor gaps remain around return values and post-save behavior, but the absence of an output schema lowers that requirement. The lack of annotations is partly mitigated by the clear 'save' and 'searchable' framing.
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 five parameters. The description adds only the general 'raw evidence' framing and does not add parameter-specific meaning beyond the schema, matching the baseline of 3.
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 states a specific verb-object pair, 'Save raw searchable evidence,' which clearly identifies the action and resource. It also differentiates from the conclusion workflow, so an agent can tell it apart from siblings like create_conclusion without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence gives an explicit when-not rule: durable intent should use the approval-gated conclusion workflow instead. This provides clear routing guidance for choosing between this tool and the conclusion-based alternative.
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 are provided, but the description fully discloses the tool's read-only behavior: it shows configuration data. There are no hidden or destructive actions, and the description is truthful and complete for a simple informational 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, concise sentence that immediately conveys the tool's purpose. It is front-loaded with the action and resource, containing no fluff or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and no annotations, the description adequately covers what the tool returns (store location and enabled optional features). However, it could be slightly more specific about what optional features are included, but overall it is sufficient for an agent to understand the tool's output.
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 no properties, so there are no parameters to describe. With 0 parameters, the baseline score is 4, and the description does not need to add parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows the local Pathmark Memory store location and enabled optional features, using a specific verb 'show' and resource 'configuration'. It distinguishes itself from sibling tools that focus on memory operations (e.g., ask_memory, delete_memory, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for retrieving configuration information. While it does not explicitly mention when not to use it or alternatives, the context is sufficient for a simple getter tool with no parameters.
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:

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

Score Badge

Copy to your README.md:

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

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/hacksurvivor/pathmark'

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