MEMO MCP Server
Server Quality Checklist
Latest release: v4.10.0
- Disambiguation4/5
Most tools have clearly distinct purposes, though the retrieval-related tools (memo_search, memo_context, memo_search_trace, memo_rerank, memo_ask, memo_chat_ask, memo_evidence_pack) cluster tightly and could be confusing for an agent to choose between. Other groups like save (memo_save, memo_save_text) and operational state are well-separated.
Naming Consistency5/5All tools follow a consistent memo_verb_noun or memo_verb pattern, making the set predictable. The naming is uniform and descriptive, with no mixing of conventions.
Tool Count2/555 tools is excessive for a memory management server. While each tool has a specific role, many are very granular (e.g., separate tools for embedding queries vs. documents, multiple search variants). The tool count feels bloated and would benefit from consolidation into fewer, more general tools.
Completeness5/5The tool set covers the full lifecycle of memory management: CRUD, search, retrieval, conflict resolution, session tracking, focus, handoffs, attention, profiling, review, invalidation, and federation. No obvious gaps for the stated domain.
Average 4.3/5 across 55 of 55 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1537 commits in the last 12 weeks
- Last stable release on
- 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.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
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
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide some coverage: idempotentHint=true aligns with the 'idempotent' trait in the description, and destructiveHint=false suggests a safe write. The description adds 'durable' and mention of epoch/fence semantics are NOT in the description. However, with idempotentHint already in annotations, the description adds modest context by describing the write as idempotent, but largely restates annotation info rather than revealing behavior like return semantics or what 'stale epochs rejected' means for the caller.
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?
One concise sentence, no filler or fluff. Accurate for its limited scope, though it sacrifices explanatory depth for brevity. The sentence earns its place but doesn't add behavioral richness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a write operation with no annotations on error conditions, side effects, or return value. While an output schema exists and parameters are covered, the description doesn't clarify the semantic model of a 'watcher' or how this differs from related tools (memo_signal_list, memo_state). The term 'operational watcher' is unexplained domain jargon that the description assumes the reader knows.
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%, so the schema documents all 5 parameters with reasonable descriptions (epoch as monotonic watcher with stale rejected, fence as leadership token, marker as stable idempotency key, etc.). The description adds minimal parameter insight beyond the schema; the only added semantic is that 'marker' serves as a 'stable idempotency marker,' which partially overlaps with the schema. Baseline 3 is correct given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it remembers a 'durable, idempotent operational watcher marker,' which names the resource (marker) and some traits (durable, idempotent) but uses jargon-heavy terms ('operational watcher marker') that are ambiguous without further context. It doesn't clearly distinguish this from the many sibling memo_* tools like memo_signal_list or memo_state, nor explain what a 'watcher' is in this domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use vs alternatives guidance is given in the description. The name and sibling list suggest this is related to signal management (memo_signal_list exists), but nothing states when to prefer this over memo_signal_list or other tools. 'Operational watcher marker' implies a niche use case but the description provides no context on triggers or scenarios.
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?
Annotations already declare the tool as read-only and idempotent. The description adds that it performs verification, which is consistent. However, it doesn't disclose what happens during verification or potential outcomes.
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 extremely concise, one sentence. It front-loads the purpose but may be too terse for clarity. However, it contains no 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?
Given the tool has an output schema (not provided), the description could be larger. It lacks context about verification scope, process, or return values. Adequate but leaves gaps.
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?
The tool has no parameters, and schema coverage is 100%. While the description could explain why no parameters are needed, it's not required. Baseline 4 is appropriate.
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 'Verify every native operational hash chain' uses a specific verb ('verify') and resource, clearly distinguishing it from other memo tools. However, it could be more explicit about what 'native operational hash chain' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus siblings or its prerequisites. No context about typical use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which fully covers the safety profile of this read-only list operation. The description adds the ordering behavior ('newest epoch first'), which is useful, though it doesn't disclose pagination behavior, output size expectations, or whether this returns signals the agent itself created.
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?
A single declarative sentence that fully communicates the purpose and ordering behavior. There is zero wasted content, and the most important information (what it lists and the sort order) is front-loaded in the first few words.
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?
The tool has an output schema (context signal), 100% param coverage in the schema, and comprehensive annotations. For a simple read-only list operation with all parameters documented and an output schema present, the description covers the essential purpose. The main gap is lack of usage differentiation, but the operation is simple enough that this is a minor omission rather than a critical one.
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%, so all three parameters (limit, marker, min_epoch) are documented in the schema with descriptions. The description adds no additional semantic value beyond the schema, which sets the baseline at 3. The schema descriptions themselves are adequate but not enriched by the tool description.
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 uses a specific verb+resource combo ('List durable watcher markers') with an ordering note ('newest epoch first'), which clearly identifies the action and result. It doesn't explicitly distinguish from siblings, but the 'markers' resource is reasonably unique among the sibling list tools (memo_terminal_list, memo_list, etc.), and its uniqueness is partially evident from the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs alternatives like memo_signal_remember or memo_terminal_list. The description states 'durable watcher markers' but doesn't explain what these markers represent, when an agent should query them, or situations where another tool (e.g., memo_list or memo_stats) would be more appropriate.
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?
Annotations provide no safety profile (all false). Description adds that it creates a durable memory and rejects sources not meeting thresholds, but does not disclose other side effects like whether source memories are modified or deleted. More behavioral context would be helpful.
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?
Two concise sentences. First states purpose, second adds rejection detail. No wasted words, but could be slightly more structured with bullet points.
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?
With 6 parameters and an output schema (not shown), the description does not explain return value or effect on source memories. It says 'creates a new durable memory' but not whether sources remain unchanged. Adequate but not complete.
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?
Input schema covers 100% of parameters with descriptions. Tool description adds little beyond schema (e.g., repeats threshold condition for 'kind'). Schema does the heavy lifting, so 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?
Description clearly states the action: 'Promote grounded memories into a reusable procedure/failure pattern.' It uses specific verb and resource, and distinguishes from siblings like memo_procedure_candidates which likely lists candidates rather than creating the promotion.
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 mentions that sources must meet thresholds based on 'kind', but does not explicitly state when to use this tool vs alternatives (e.g., memo_procedure_candidates, memo_outcome_record). No guidance on when not to use.
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 and idempotentHint=true. Description adds that results are bounded by budget_chars and include stable/active sections with evidence metadata, providing useful behavioral nuance beyond annotations.
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?
Description is a single sentence that conveys the core function efficiently. However, it uses jargon ('bounded stable and active memory') that may require prior context; a slightly more structured breakdown could improve clarity.
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 presence of an output schema and detailed parameter descriptions, the description is mostly complete. However, it does not explain what 'stable' vs 'active' memory means or how evidence metadata is structured, which could be ambiguous for an agent.
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%; each parameter is well-documented in the schema. The description does not add additional meaning beyond what is already in the schema, so a baseline score of 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?
Description clearly states it returns bounded stable and active memory with evidence metadata. This is specific to the tool's function and distinguishes it from siblings like memo_search (search) and memo_context (context retrieval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 memo_context or memo_unified_briefing. No indication of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior; the description adds filtering conditions but omits details like default sorting (covered in schema) or record scope (e.g., excludes deleted records).
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?
Single sentence, 10 words, no redundancy – highly concise and 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?
Covers the essential purpose and conditions; output schema likely documents return values; slight omission of ordering or pagination details, but overall adequate.
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 covers all parameters with descriptions (100% coverage); the tool description adds no further meaning beyond 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?
Clearly states the tool lists records with specific conditions (passed review date or open conflict), distinguishing it from generic list/search tools among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like memo_list or memo_search; the description only implies its purpose.
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 destructiveHint=true. The description adds valuable context: 'Only the old record is modified' clarifies the scope of destruction, and the constraint on close time prevents confusion. This goes beyond annotations without contradicting them.
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 extremely concise—two sentences, no filler, and perfectly front-loaded. Every word adds value.
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?
The description explains the core behavior and constraints. With an output schema present, return format is not needed. However, it omits details like the effect on the new record, side effects, or ordering requirements. Minor gap, but generally sufficient.
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 clear descriptions for all three parameters. The description does not add any additional parameter-level detail beyond what the schema provides. Baseline score of 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 clearly states the action ('Close the old memory') and the specific condition ('at the successor's validity start'). It identifies the resource (memory) and implicitly distinguishes from other memo tools by describing a unique supersede operation. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It simply describes the operation without contextual hints about use cases.
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, covering the safety profile. The description adds meaningful behavioral context: that the result is conditional on legacy TTY input being enabled ('empty while legacy TTY input is disabled'), which is exactly the kind of behavioral quirk an agent needs to know. This adds value beyond the annotations.
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?
A single, short sentence delivers the purpose plus a critical conditional caveat. There's some ambiguity in the phrase 'empty while legacy TTY input is disabled' that could be clearer, but no wasted words are present. It's economically written and front-loaded with the verb and resource.
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?
The output schema exists, so return values need not be described. The description flags the key caveat (empty when legacy TTY disabled) which is the main behavioral context an agent needs. For a zero-parameter read tool with annotations fully covering the safety profile, the description is sufficiently complete.
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?
The tool has 0 parameters and 100% schema coverage (as nothing exists to document). The description adds no parameter information since there are none. With no parameters, the baseline is 4 per the rubric, and the description's note about the legacy TTY state effectively explains the tool's input-free nature as a state readout.
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 names a specific resource ('deliverable terminals') with the verb 'list', making the purpose clear. It doesn't explicitly distinguish from siblings, but the term 'deliverable terminals' is a distinct concept among the many memo_* tools, and the description differentiates by noting it returns 'deliverable' terminals specifically, which is narrowly scoped enough.
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 alludes to when it's useful via 'empty while legacy TTY input is disabled', implying this tool reflects legacy terminal state. However, it doesn't explicitly state when to use this tool versus alternatives like memo_get or memo_list, and offers no explicit exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it mentions journaling with the acting agent's identity and that the change replaces the previous focus. Annotations already indicate idempotent and non-destructive, and the description reinforces idempotency by stating 'safe to repeat'. This adds useful context about journaling.
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 three concise sentences. The first sentence states the primary action, and subsequent sentences add key behavioral details (replaces, journaled, safe to repeat). No unnecessary words, 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?
Given the tool's low complexity, the presence of full schema descriptions, and an output schema (not shown but present), the description is complete. It covers the core behavior, idempotency, and journaling, which suffices for this straightforward mutation tool.
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%, so the baseline is 3. The description does not add parameter-level information beyond what the schema provides (e.g., project, summary, actor_id). It only elaborates on the overall behavior, not individual 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 'Set the current focus for a project' with a specific verb and resource. It explains that it replaces previous focus, but it does not explicitly differentiate from the sibling tool memo_focus_clear, which clears focus. Thus, purpose is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for setting focus and notes it is safe to repeat, which provides some guidance. However, it does not explicitly state when to use this tool versus alternatives like memo_focus_clear or when not to use it. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate idempotency (idempotentHint=true) and non-destructiveness (destructiveHint=false). The description adds valuable context by explaining that retries with identical evidence and actor are a no-op, which enhances transparency. It does not contradict any 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?
The description is extremely concise with only two sentences. The first sentence states the purpose, and the second addresses idempotency. Every sentence earns its place without any filler.
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 has three parameters, an output schema, and annotations, the description provides sufficient context: purpose, idempotency, and a note on evidence sanitization. It does not fully explain 'verify the memory' or 'schedule its next review', but these are likely detailed in the output schema or elsewhere, so completeness is adequate.
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?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds extra meaning by noting that evidence is sanitized before being persisted, which is not in the schema. This additional detail justifies a slightly higher score.
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 tool records review evidence, verifies the memory, and schedules the next review. It uses a specific verb ('Record') and resource ('review evidence'), making the purpose clear. However, it does not explicitly differentiate from sibling tools like 'memo_review_due' or 'memo_get'.
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 implies the tool is used when reviewing a memory, but it provides no explicit guidance on when to use it versus alternatives, nor does it mention any prerequisites or exclusions. The usage context is implied but not detailed.
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?
Annotations already indicate read-only and idempotent behavior. The description adds context about the specific subset of memories returned, but no additional behavioral traits (e.g., pagination, auth requirements) beyond 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?
The description is a single, lean sentence with no wasted words. It is front-loaded with the key action and criteria.
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 output schema exists and annotations cover safety, the description sufficiently explains the tool's purpose. It is complete for a simple filtered-list tool with no hidden 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 coverage is 100%, so parameters are well-documented. The description does not add any parameter-level details beyond what the schema provides, meeting the baseline for full coverage.
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's function: listing memories that are 'outcome-backed' and 'ready for procedural promotion'. It uses specific verbs and resource, and distinguishes itself from siblings like memo_list (generic list) and memo_procedure_promote (promotion action).
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?
No explicit guidance on when to use this tool versus alternatives. The naming and sibling list imply that it is a precursor to memo_procedure_promote, but the description does not state this or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description does not contradict and adds no further behavioral context beyond what is returned.
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?
Single sentence, front-loaded with purpose, no extraneous words. Efficient and clear.
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 zero-parameter read-only status tool, the description fully explains the output. No additional detail needed given the annotations and output schema.
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?
No parameters exist, so the description does not need to add parameter details. Baseline for 0 params is 4, and the description clearly states what the tool returns.
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?
Describes a specific verb 'Return' and resource 'process-local MCP write queue' with explicit attributes (depth, waits, rejections). Uniquely identifies the tool among many siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. Lacks context such as diagnostic scenarios or frequency of use.
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?
Extends beyond the idempotentHint annotation by detailing the exact return values for known/unknown/already acknowledged cases. This helps the agent understand the tool's exact behavior.
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 concise sentences, front-loaded with the main purpose, and no wasted words. Efficient and clear.
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 enough for a simple idempotent acknowledgment tool with output schema and annotations. Slightly lacking in connecting 'attention item' to broader context, but still good.
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 covers both parameters with 100% description coverage. The description adds no additional parameter semantics beyond the schema, so a baseline score of 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 states a specific verb 'Acknowledge' and resource 'attention item', and explains the effect 'stops being surfaced'. It is clear and distinguishable from sibling tools.
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?
No explicit guidance on when to use or alternatives are provided. The purpose is clear but an agent might benefit from knowing this is for dismissing attention items rather than other actions.
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?
Annotations indicate it is a write operation (readOnlyHint false) and not destructive. The description adds that it journals the record and rejects invalid severities, providing extra context beyond 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?
Two sentences with no wasted words; the critical information is front-loaded and easily parsed.
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?
The tool has an output schema (not shown) so return values are documented. The description covers purpose, constraints, and severity validation, but does not mention prerequisites or duplicate behavior for a simple add operation.
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 with descriptions for all three parameters. The description adds value by explicitly stating that severities outside the allowed set are rejected, which is not 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 verb ('Add') and the resource ('item that must be surfaced to later agents'), specifying it writes a journaled attention record. This distinguishes it from siblings like memo_attention_ack.
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 implies usage when a later agent needs to see an item, but does not explicitly state when to avoid using it or mention alternatives like memo_attention_ack for acknowledging.
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 a safe, read-only, idempotent operation. The description adds context about ACL authorization and signed bundles, enhancing understanding of the tool's behavior without contradicting 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?
The description is a single, concise sentence that immediately conveys the tool's purpose with no unnecessary words.
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?
Combined with the input schema and annotations, the description provides sufficient context. The output schema further aids completeness. Minor clarification linking the principal to the ACL would improve it.
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 already describes the 'principal' parameter thoroughly. The tool description does not add extra meaning beyond the schema, so parameter semantics are adequately covered.
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's purpose: to preview which memories an ACL would allow into a signed bundle. The verb 'Preview' and specific resource 'exact memories' make it distinct from sibling tools.
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 implies the tool is used for previewing memories under ACL constraints, but it provides no explicit guidance on when to use this tool over others or when not to use it.
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 value beyond annotations by stating idempotency and return behavior when no focus was set, though annotations already cover idempotency.
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 sentences, no redundant information, action 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?
Adequate for a simple tool with full schema, annotations, and output schema; could add more context about prerequisites.
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%, description adds no extra meaning beyond schema; baseline 3.
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 'Clear a project's current focus' uses a specific verb and resource, clearly distinguishing from sibling tools like memo_focus_set.
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?
No explicit guidance on when to use this tool versus alternatives; usage is implied but not stated.
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 provide idempotentHint=true, and the description adds concrete behavior details: idempotent, returns {'consumed': false} for unknown/already consumed, and true only on first consume. This enriches the behavioral model beyond annotations. Score 4 because it does not cover all possible side effects (e.g., what happens to other agents seeing the handoff).
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 extremely concise: one sentence for purpose, one paragraph for behavioral details. Every sentence is informative and necessary. No redundant or vague language.
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 tool's simplicity, the presence of an output schema (so return values need not be fully detailed), and the behavioral explanation, the description covers all necessary aspects for correct usage. It is complete and self-contained.
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 covers 100% of parameters with descriptions. The tool description does not add additional meaning to parameters beyond what is already in the schema. Baseline score of 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 clearly states the action ('mark a handoff consumed'), the resource ('handoff'), and the purpose ('stops surfacing to later agents'). It effectively distinguishes from sibling tool memo_handoff_create, which creates handoffs.
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 implies usage context (consuming handoffs to stop surfacing) but does not explicitly state when to use or not use this tool, nor provide any alternatives. It lacks explicit guidance on when-not or comparison to siblings.
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 read-only, idempotent, and non-destructive. The description adds value by detailing the type of metadata returned and noting that unknown ids return null, which is consistent with 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?
Two sentences: first clearly states purpose, second provides usage context and specifics. Every word is valuable; no redundancy or filler.
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 output schema exists, the description sufficiently covers what the tool does, when to use it, and what it returns (provenance metadata). It addresses the key use case without missing critical details.
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 schema description for the 'id' parameter is already detailed (full 32-char hex or unique prefix, git-style, returns null for unknown). The description repeats this without adding meaningful new information, so baseline 3 is appropriate.
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 tool returns provenance metadata for a memory, specifying the kinds of information (origin, lineage, file path, audit details). It mentions usage before trusting, editing, or citing, but could more explicitly distinguish from similar tools like memo_get or memo_history.
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 guidance on when to use: with a full id or unique prefix when needing audit details before trusting, editing, or citing. This sets context, though it doesn't explicitly mention when not to use or offer direct sibling comparisons.
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. Description adds context about client sampling and synthesizer field, and reinforces read-only nature. No contradictions.
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, front-loaded with purpose, followed by usage guidance and parameter roles. No fluff, every sentence adds value.
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 7 parameters and presence of output schema, description covers core functionality, usage context, read-only nature, parameter tuning, and client sampling. Missing specifics on return format, but output schema exists to fill that 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 coverage is 100%, baseline is 3. Description adds context for some parameters (k, type, snippet_chars, source) but does not explain all (e.g., session_id, include_repos). Schema descriptions are already comprehensive.
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?
Clearly states the tool answers a question using memo retrieval and citations. Distinct from sibling tools like memo_search which return raw hit lists.
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 when to use 'synthesized answer grounded in durable memories instead of raw hit lists'. Mentions parameter tuning but does not explicitly list when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations, noting that the tool writes to a hash-chained journal and that resolution is human-only. Annotations already indicate non-destructive write operations, so the description aligns and adds value without contradiction.
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 very concise with three sentences, front-loading the purpose and then adding key details about the journal and resolution. Every sentence is informative with no fluff.
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 role in conflict management, the description adequately covers the core workflow and mentions the journal's auditability. It does not detail the output schema, but that is acceptable since an output schema exists. Minor gaps in expectations about 'open a conflict' are acceptable.
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%, so the schema already explains all parameters well. The description does not add new information about parameters beyond what the schema provides, meeting the baseline expectation.
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's purpose: 'Open a local, auditable reality conflict.' It specifies that it writes a 'detected' conflict record to a hash-chained journal, distinguishing it from siblings like memo_conflict_resolve which handles human resolution.
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 implies when to use this tool (to open a conflict) and mentions memo_conflict_resolve for resolution, providing an alternative. However, it lacks explicit guidance on when not to use it or specific prerequisites.
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 and idempotentHint=true. The description adds valuable behavioral details: citations are memo://, abstention policy based on min_coverage. No contradictions.
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, no unnecessary words. The key one-liner is front-loaded, making it easy for an AI to quickly grasp the tool's purpose.
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 complexity (6 parameters, high schema coverage, output schema exists), the description covers the essential behaviors (citations, abstention). Could be slightly more explicit about output format, but output schema likely compensates.
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 clear parameter descriptions. The description does not add significant meaning beyond the schema, so a baseline score of 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?
Clearly states the tool returns bounded, cited evidence for a question or an explicit abstention. This distinguishes it from sibling tools like memo_search or memo_ask which may not provide citations or abstention.
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 usage context: use for cited evidence, expects abstention when coverage is low. However, it does not explicitly contrast with alternatives like memo_search or memo_ask, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: notes that the handoff is journaled, durable, and surfaces in operational state until consumed. Annotations are minimal, but the description compensates 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?
The description is concise with two sentences: one for primary purpose, one for key behavioral details. No extraneous 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 the schema completeness and presence of output schema, the description explains the lifecycle (created, persists until consumed) and purpose. Minor omission: no mention of effects on operational state beyond surfacing.
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 parameter descriptions already clear. The tool description provides high-level context (e.g., 'for another agent or session') but does not add significant per-parameter meaning.
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 creates a durable handoff for another agent or session. It uses specific verbs and resources, and the distinction from the sibling 'memo_handoff_consume' is evident.
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 implies the tool should be used to pass work to another agent, but lacks explicit when-not-to-use or alternatives. However, the sibling context provides differentiation.
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, idempotentHint, and destructiveHint false, covering safety. The description adds valuable behavioral context: it returns only open items unless include_closed is set, enforces a per-section limit, and explains why unbounded snapshots accumulate context cost.
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 two sentences: a crisp summary of what is read, then a concise explanation of snapshot behavior, defaults, and cost rationale. No filler or redundancy; the key action is 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?
With a rich output schema and parameter descriptions, the description adequately captures the tool's scope without needing return-value details. Its prose list omits 'signals' (present in the schema's limit description), but this is minor and readily filled by the schema.
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?
Parameter schema coverage is 100%, with each parameter already documented (limit default 20, project scoping, include_closed false). The description references 'include_closed' and 'limit' but adds no new syntactic meaning; it reinforces the reason for the limit but does not expand on parameter semantics.
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 'Read current focus, handoffs, attention items, conflicts, and outcomes,' clearly specifying the action and resource. This distinguishes it from sibling mutation tools like memo_focus_set or memo_handoff_create, which modify those items rather than read them.
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 establishes a clear read-only snapshot use case and explains default behavior (open items only, limited entries) and the cost rationale. It does not explicitly name alternatives or state when not to use the tool, but the read-only nature and aggregate scope make the intended context obvious.
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 declare idempotentHint=true, and the description elaborates on the mechanism: 'Idempotent per idempotency_key,' explaining that retries replay the stored outcome and reusing the key with a different payload is rejected. This adds useful detail beyond the annotation, though no other behavioral traits (e.g., side effects beyond stat updates) are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and followed by key context. Every sentence adds value, and there is no wasted text.
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 has 6 parameters (4 required) and an output schema exists, the description covers the essential purpose and idempotency. The mention of procedure promotion provides necessary context. It does not explain the output, but the schema covers that. Overall, it is sufficiently complete.
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 each parameter already has a description. The description only adds context about idempotency_key's role in safety, but does not elaborate on other parameters like actor_id or artifacts. Thus, it adds marginal semantic value beyond 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 action ('record') and the resource ('whether recalled memories helped a task succeed'). It distinguishes itself from sibling tools by explicitly mentioning its role as the signal for procedure promotion, setting it apart from related tools like memo_procedure_promote.
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 implies usage after recalling memories for a task, stating it 'feeds success/failure back into each cited memory's outcome stats.' While it does not explicitly list when not to use it, the context is clear. It would benefit from an explicit note that this is for outcome tracking, not for initial memory creation.
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?
Description adds value beyond annotations by explaining that cwd biases project context and source attributes consult logs. It also states 'Read-only' matching annotations, but does not cover other behavioral aspects.
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?
Extremely concise: three sentences that front-load the main purpose and immediately provide usage guidance. No wasted words.
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 presence of an output schema (not shown but indicated), the description covers purpose, usage, parameters, and behavioral traits adequately for a read-only briefing tool.
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%, but description adds extra context: cwd 'biases project context' and source 'attributes consult logs.' This clarifies parameter roles beyond the schema descriptions.
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 it loads a 'compact startup briefing' from Memo's durable and operational state. It's a specific resource, but does not explicitly differentiate from siblings like memo_get or memo_context.
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 guidance given: 'Call before deciding or answering so prior durable facts can ground the task.' This provides clear context on when to use, but no mention of when not to use or alternative 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?
Annotations already indicate read-only and non-destructive nature. The description adds 'Short ids are resolved safely,' a useful behavioral detail beyond annotations. No contradictions.
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 sentences, front-loaded with primary purpose followed by direct use guidance. No redundant or irrelevant phrasing. Every sentence adds value.
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 tool's simplicity (read-only history listing with three optional filters), the description fully covers purpose, usage context, and key behavioral traits. Output schema exists to handle return format details, so no further completeness needed.
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 detailed descriptions. The description reiterates filtering by op and id and notes short id resolution but does not add significant new meaning or constraints beyond the schema. Baseline score 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?
Clearly states 'List recent memory history events' and contrasts with other tools by specifying its role for audit trails and filtering by operation or memory id. Differentiates from siblings like memo_list (current memories) and memo_get (single memory), making selection unambiguous.
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 guides usage: 'Use for audit trails across the corpus or filter by op and memory id when investigating a specific write, update, delete, forget, or reindex action.' Does not explicitly state when not to use, but the purpose is clear enough for an agent to infer alternatives from sibling 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?
Annotations already indicate destructiveHint=true, but description adds that the record is retained and readable, and that invalid_at is set in frontmatter and index. This context goes beyond the annotation to clarify non-destructive nature of the mutation.
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 sentences with no fluff. Purpose is front-loaded. Every sentence adds necessary detail.
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 output schema exists and schema coverage is full, description adequately covers the tool's behavior, side effects, and parameter semantics.
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 value by explaining the effect of parameters: 'at' defaults to now, 'reason' is sanitized and logged. This supplements the schema descriptions.
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 clearly states the action: 'Close one memory's truth-validity interval without deleting it.' It uses a specific verb-resource pair and distinguishes from siblings like memo_delete by noting the record is retained.
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?
Implies usage as an alternative to deletion ('without deleting it') but provides no explicit guidance on when to choose this over related tools like memo_forget, memo_supersede, or memo_update. No 'when not to use' or comparison.
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, idempotentHint, and destructiveHint, but the description adds that the tool returns None for unknown session IDs, which is behavioral context not captured in annotations. The description also states 'Read-only', confirming the safety profile.
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 three sentences, front-loaded with the purpose, followed by a concise usage directive. No extraneous information; every sentence adds value.
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 presence of an output schema and 100% schema coverage, the description adequately covers the tool's purpose, usage context, and return behavior for unknown IDs. No gaps are evident.
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%, with the parameter description explaining prefix matching and null returns. The main tool description does not add new information about the parameter beyond what the schema provides, so baseline score applies.
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 fetches metadata for one memo session. It specifies the resource ('tracked memo session') and the action ('Fetch metadata'), and distinguishes from siblings by mentioning when to use it (after memo_session_list or memo_start_session).
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 usage context: 'Use after memo_session_list or memo_start_session when you need the stored transcript path, project, checkpoints, or other session details.' It does not list explicit when-not-to-use scenarios, but the guidance is clear and helpful for the agent.
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, destructiveHint=false, idempotentHint=true. The description adds 'Read-only' and mentions the purpose of finding session data for capture/inspection, providing behavioral context beyond the 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?
Three sentences: first declares the action, second explains use case and output fields, third explains parameters. No wasted words, front-loaded with key 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?
With an output schema present (not shown), the description need not detail return values. It covers the tool's purpose, read-only nature, output fields (session ids, transcript paths, project context), and parameter usage. For a list tool with good annotations and schema, this is complete.
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 detailed descriptions for both parameters (limit: 'sorted by most recently updated first (no clamp)'; project: 'Exact project-name filter…'). The main description only briefly mentions 'project narrows results and limit caps the number of sessions returned', adding minimal extra meaning beyond 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 starts with 'List tracked memo sessions', a clear verb+resource. It distinguishes from sibling 'memo_session_get' (single session) and other list tools like 'memo_list' (memos vs sessions). It also specifies what the list contains: session ids, transcript paths, and project context.
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 states it is read-only and used for finding recent sessions. It explains how to narrow results with 'project' and cap with 'limit'. It does not explicitly mention alternatives or when not to use, but provides clear 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?
Annotations already indicate destructiveHint=true, so description adds value by noting versioning (memo_version_rollback), exact-match requirement for replace_old, and byte-identical preservation. This clarifies behavioral traits beyond annotations.
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?
Single paragraph packs essential information, front-loaded with the main action. Could be slightly more structured (e.g., bullet list), but no wasted words and all key points are covered efficiently.
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 output schema exists, description covers input semantics thoroughly, including constraints on replace_old occurrence and versioning. No critical missing information, though it could mention return behavior or error cases.
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 context: tags are lower-cased/deduplicated, type must be valid, mutual exclusivity between content/replace/append. This adds meaningful guidance beyond 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?
Description clearly states it patches fields on a memory, lists three distinct update modes (content replacement, surgical edit, append), and mentions versioning. This provides a specific verb-resource-action scope and distinguishes it from sibling tools like memo_save or memo_get.
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?
Description explains when to use each parameter (content for full replacement, replace_old+replace_new for exact edits, append for adding a paragraph) and notes mutual exclusivity. However, it does not explicitly contrast with siblings or provide conditions for when not to use this tool.
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 and destructiveHint=false. The description reinforces this with 'Read-only' and adds context about synthesis running on the calling model with client sampling, which is beyond 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?
The description is very concise: four sentences, front-loaded with the core purpose, and no unnecessary words. Every sentence adds value.
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?
With 8 parameters (1 required) and an output schema, the description covers the main purpose and key distinctions. It doesn't detail every parameter, but the schema does, and the description adds the conversational context and guidance vs memo_ask.
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. The description adds meaning by explaining that history is a list of chat messages, session_id links the answer to a tracked session, and context is used for synthesis. This enriches the schema descriptions.
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 answers a conversational question with optional history and context. It distinguishes itself from the sibling memo_ask by specifying when to use this tool instead, mentioning prior turns or explicit context shaping retrieval.
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 guidance on when to use this tool over memo_ask: when prior turns or explicit context should shape retrieval. It also hints at client sampling and synthesizer field but doesn't give exhaustive usage scenarios.
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 (readOnlyHint=false) already indicate write operation. Description adds that it 'returns the saved memory id' and title is optional, providing useful behavioral context beyond 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?
Concise with front-loaded purpose 'Save a memory from text.' followed by clear details. Every sentence adds value with no redundancy.
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?
With 2 params, high schema coverage, and presence of output schema, description explains purpose, return value, and parameter behavior adequately. Could mention that it's a simple save without conflict handling, but that is already implied by comparison with memo_save.
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 baseline is 3. Description adds that title is optional and auto-generated from first line, but this info is also in the schema description. No significant additional meaning beyond 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 clearly states 'Save a memory from text' and 'Persists one plain note from text and returns the saved memory id.' It distinguishes from siblings by explicitly mentioning memo_save for more options and memo_idle_capture for transcripts.
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 this tool: 'Use for quick client-agnostic saves when you already have the exact content to remember.' Also provides alternatives: 'Prefer memo_save when you need tags... Prefer memo_idle_capture for transcript-derived session insights.'
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 readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds behavioral context beyond annotations: that it returns a command string for human execution and does not resolve anything itself. No contradiction.
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 sentences, each adding value. The first states the primary purpose, the second clarifies behavior (read-only, returns command). No unnecessary words, front-loaded with the key action.
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 low complexity (1 param, clear annotations, output schema present), the description is fully sufficient. It explains the tool's purpose, limitation, and output nature. No gaps.
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 one parameter 'id' described as 'Id of the conflict to resolve.' The description does not add meaningful new semantics beyond the schema; baseline 3 applies.
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 'reports the local human action required to resolve a conflict'. It uses a specific verb ('report') and resource ('local human action'), and distinguishes from siblings by emphasizing it does not resolve conflicts itself, unlike other conflict-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Read-only: never resolves anything itself' and that it returns a command for a human to run. This gives clear context on when to use it (to get the resolution command) and implies when not to (when actual resolution is needed, use another tool). However, it doesn't name specific 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?
Beyond the destructiveHint annotation, the description adds crucial behavioral details: irreversibility (no trash), confirmation behavior for elicitation-capable clients, safe ambiguous-id resolution with errors, and cross-reference warnings. This far exceeds what annotations alone 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?
The description is four sentences, each earning its place: main purpose, destructive irreversibility, confirmation nuance, and safety behavior. It is front-loaded with the core action and avoids redundancy.
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 tool with one parameter and an output schema, the description is remarkably complete. It covers irreversible side effects, confirmation flows, error handling for ambiguous ids, and reference warnings, leaving little ambiguity for the agent about what to expect.
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?
The schema already fully describes the 'id' parameter (100% coverage). The description adds valuable context about prefix ambiguity resolution and error behavior, which helps the agent understand how the parameter is interpreted without guessing.
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 states a specific verb+resource+scope: 'Permanently delete one memory by id or unique prefix.' This clearly distinguishes it from sibling tools like memo_forget (which likely implies a soft delete) and other memory operations.
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 implies usage through the phrase 'permanently delete' and mentions confirmation behavior, but it does not explicitly contrast with alternatives such as memo_forget or memo_unforget, nor does it state when not to use the tool.
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?
Adds context beyond annotations: confirms read-only, explains empty list returns no vectors without error, and notes it uses the same internal embedder. No contradictions with 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?
Two concise sentences (plus one clarifying) that are front-loaded. Every sentence adds value without redundancy.
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 simple one-parameter tool with output schema, the description covers purpose, usage context, behavior, and parameter semantics adequately.
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 detailed description of the 'texts' parameter. The description adds no significant new information 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?
Clearly states action (embed), resource (document strings), and context (same embedder model as memo). Implicitly distinguishes from query embedding sibling by mentioning document strings.
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 says when to use: for diagnostics or external indexing when document vectors are needed. Does not specify when not to use or alternatives, but context 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by specifying the exact information returned (model id, dimensions, normalization, provider) and its relevance to semantic search. No contradictions with 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?
The description is three sentences, front-loaded with the main action ('Return the active embedding model profile') followed by read-only note and detailed use case. Every sentence contributes value with no redundancy.
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 zero parameters, comprehensive annotations, and existence of an output schema, the description fully explains the tool's purpose and the kind of data returned. It also provides context on when to use it (compatibility verification), making it complete.
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?
The tool has zero parameters, so baseline is 4. The description does not need to explain parameters, but it effectively explains what the output contains, which adds meaning beyond the input 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 it returns the active embedding model profile and lists specific fields (model id, vector dimensions, normalization, provider). This directly addresses the tool's purpose and distinguishes it from siblings, as no other tool retrieves embedder profile details.
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?
It explicitly says 'Read-only' and provides use cases: inspecting model details and verifying compatibility with stored vectors or external retrieval components. While it doesn't list when not to use it, the context is clear and sufficient for a simple read-only tool.
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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavior beyond annotations: results are grouped, capped per category, scale with corpus size, and could exceed response budgets if not limited. This explains the limit parameter's rationale without contradicting 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?
Three sentences, each earning their place: purpose, return characteristics plus rationale, and usage guidance. No redundant phrasing or filler. Front-loaded with the core verb and resource.
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 an output schema exists, the description is complete for a read-only lint tool with one optional parameter. It covers what is returned (grouped findings), key constraints (limit, scaling, response budget), and the follow-up action (use other tools to fix). No important gaps remain.
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% for the single 'limit' parameter, which already explains its default and the 'counts' field. The description reinforces the cap behavior but adds little novel meaning beyond the schema. 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 uses a specific verb ('Inspect') and resource ('memory corpus') with a clear scope ('maintenance issues'). It distinguishes itself from siblings by focusing on audit/lint findings rather than retrieval, updates, or deletion, and explicitly names the categories of findings (malformed metadata, cleanup needs).
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?
The description explicitly directs the agent to use memo_update, memo_delete, or vault edits separately to fix findings, making clear that this tool is for inspection only. This provides a strong usage guideline and differentiates it from mutation 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?
The description states 'Writes only derived index state; markdown remains the source of truth,' which aligns with non-destructive and idempotent annotations. It adds behavioral context beyond the annotations by reinforcing that the markdown is unchanged.
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 concise with three sentences, front-loading the main purpose. Every sentence adds value without redundancy.
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 simple tool with one parameter and existing output schema annotations, the description covers purpose, usage, and parameter details comprehensively. No gaps remain.
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?
The description adds a clear explanation of the force parameter: 'reprocesses records even if memo thinks they are current,' which complements the schema's description. With 100% schema coverage, the parameter semantics are well-supported.
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 verb 'Rebuild', the resource 'memo's searchable index', and the source 'markdown vault'. It distinguishes this tool from siblings like memo_list or memo_get by focusing on index rebuilding.
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 explicitly says 'Use after hand-editing vault files or changing indexing behavior,' providing clear guidance on when to invoke the tool. It does not mention when not to use it, but the context is sufficient.
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 mark the tool as read-only and idempotent. The description adds value by confirming 'Read-only' and describing the return format ('raw ranked hits — source records with ids, dates, tags, and excerpts'). No contradiction with 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?
Two sentences plus a list of alternatives. Every sentence is substantive and earns its place. The core purpose is front-loaded, and the alternatives are clearly enumerated. No wasted words.
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 tool's complexity (11 parameters, no enums, has output schema), the description is fully adequate. It covers purpose, read-only nature, return type, and provides clear links to siblings. The output schema handles return value details, so the description doesn't need to.
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%, so the description carries minimal parameter burden. It does not repeat or augment schema details, which is appropriate. Baseline score of 3 is correct.
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 pair ('Search durable memories') and immediately distinguishes the tool from siblings by naming three alternative tools (memo_context, memo_search_trace, memo_rerank). This meets the highest standard.
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?
The description explicitly states when to use this tool ('for raw ranked hits') and directs the agent to three alternatives for different use cases (prompt-ready pack, diagnostics, reordering). This is exemplary 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?
Annotations already convey readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's job is lighter. It adds valuable context: 'Read-only. Debug variant... Returns the same style of hits as memo_search plus trace metadata that explains how candidates were selected and scored at each stage.' This enhances transparency without contradicting 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?
The description is two sentences long, front-loaded with the core purpose, and each sentence adds value. There is no fluff or redundancy. It is appropriately sized for a targeted debug tool variant.
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 tool's complexity (6 parameters with 100% schema coverage, output schema present, and a clear sibling relationship), the description is complete. It explains the purpose, usage context, and what distinguishes the output. No critical information is missing.
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%, so the baseline is 3. The description does not elaborate on individual parameters beyond what the schema provides; it only mentions the output (trace metadata). No additional parameter semantics are added, so the score remains at 3.
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 starts with 'Search memories and include retrieval trace diagnostics,' specifying the verb (search) and resource (memories) with a clear differentiator (trace diagnostics). It also explicitly distinguishes from the sibling tool memo_search by calling itself a 'debug variant' and stating its specialized use case.
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?
The description gives explicit guidance: 'use it when investigating ranking, filters, or recall misses rather than for normal lookup.' This directly tells the agent when to choose this tool over memo_search, satisfying the dimension's requirement for context and exclusion.
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 readOnlyHint, idempotentHint, and no destructive behavior. The description adds value by specifying the exact type of version info returned (package version and backend protocol version), which is beyond 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?
Two concise sentences with no wasted words. The key information is front-loaded: 'Get memo version info' immediately states the purpose.
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 tool has no parameters and an output schema exists, the description sufficiently explains what the tool returns and when to use it. No gaps.
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?
No parameters exist, so schema coverage is 100%. The description does not need to add parameter info; baseline 4 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 clearly states the verb 'Get' and the resource 'memo version info', specifying the package and backend protocol versions. It is distinct from sibling tools, which are mostly for data operations or queries.
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 says 'Use this to check which version of memo is running', providing clear when-to-use guidance. No exclusion or alternatives needed for such a simple tool.
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 readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description reinforces 'Read-only' and adds useful behavioral details: rejects empty text, and returns vector, dimension, and model id. No contradictions, but the description mainly confirms annotations with small additions, so a 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences that front-load the core purpose, then add usage context and return behavior. Every sentence adds value, with no wasted words. It is highly compact yet informative.
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 a simple tool with one parameter and an existing output schema, the description covers all necessary aspects: purpose, usage context, parameter semantics, and return value structure (vector, dimension, model id). It is fully sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'text'. The description for this parameter adds key context: 'instruction-prefixed for asymmetric retrieval' and clarifies that empty/whitespace-only input raises an error. This meaningfully extends beyond the schema's basic type 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 clearly states the tool embeds one query string using memo's query embedding path, and specifies it's for diagnostics or integrations needing the exact vector for retrieval queries. This verb+resource+scope is specific and distinguishes it from sibling tools like memo_embed_batch.
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 explicitly says 'Read-only' and 'Use for diagnostics or integrations that need the exact vector memo would use for retrieval queries.' It also notes that empty text is rejected. However, it does not mention alternatives (e.g., memo_embed_batch for batch processing) or when not to use it, which would improve clarity.
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 readOnlyHint, idempotentHint, and destructiveHint, but the description adds valuable behavioral context: the read-only nature, the ambiguity error, and the MEMO_EMITTED_LEDGER recovery counting. It goes beyond the structured safety hints without contradicting them.
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 front-loaded with the core purpose, then gives edge cases and usage guidance. The final paragraph about MEMO_EMITTED_LEDGER is detailed and possibly overlong, but it is relevant to behavioral transparency and does not repeat structural data.
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?
The tool has a simple schema, rich annotations, and an output schema. The description covers purpose, edge cases (None, ambiguity), alternatives, and advanced ledger behavior, leaving no significant gaps for an agent to invoke it correctly.
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 schema already provides 100% coverage for the single 'id' parameter, including the format ('Full 32-char memory id or a unique prefix'). The description does not add meaning beyond the schema; it reinforces the same idea but does not introduce new semantic details.
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 and resource: 'Fetch one memory by id or unique id prefix.' It clearly distinguishes from sibling tools like memo_search and memo_list by focusing on retrieval by identifier, and it explicitly states the possible return outcomes (full record, None, ambiguity error).
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?
The description explicitly states when to use alternatives: 'Use memo_search or memo_list first when you do not know the id.' This gives clear contextual guidance for choosing the right tool and when not to use memo_get.
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?
Description adds behavioral context beyond annotations: it is a write tool that saves to memo records, and dry_run prevents writing. No contradiction with annotations (destructiveHint=false, etc.). Minor gap: does not discuss rate limits or auth, but adequate given 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?
Efficient and front-loaded: first sentence states action and type ('Write tool'). Subsequent sentences provide usage guidance and dry_run behavior. No unnecessary 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?
Covers purpose, usage, and parameter behavior. Assumes knowledge of 'idle capture' and 'session transcript', but context signals indicate siblings and annotations. Has output schema, so return values are covered. Minor gap: prerequisites like session existence are implied but not explicit.
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% with a brief description for dry_run. The tool description adds meaning by explaining the effect of dry_run in context ('no memories are written and the response only reports what would run'), which is more explicit than the schema's 'Preview what would be saved without writing anything.'
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 clearly states 'Run idle capture... Extracts durable insights... saves as memo records.' It distinguishes itself as a write tool, contrasting with sibling read tools like memo_search and memo_ask.
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 ('after a meaningful unit of work, or periodically for clients without Stop hooks') and when not to use ('Do not use for normal lookup; call memo_search, memo_ask, or memo_unified_briefing'). Also explains dry_run mode.
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 only carry readOnlyHint=false and destructiveHint=false (no strong assertions), so the description must disclose behavior, which it does thoroughly. It explains the extraction mode's return shape (extraction summary vs single record), the tag propagation to every fact, the fallback 'blob saved verbatim' behavior, the auto project:<repo> tagging logic including the global recall tier boost, and the authority-controlled key stripping in `extra`. This is rich behavioral context well beyond minimal requirements.
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 organized into clear topically-paragraphed blocks (purpose, extraction mode, scope, defer_embed), each earning its place. It is long but every paragraph addresses a distinct behavioral aspect necessary for correct usage. Shorter than the length would suggest given 9 parameters and several conditional behaviors it must explain.
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 9 parameters, an output schema exists (which presumably documents the extraction summary shape), and no strong annotations to lean on, the description fully compensates. It covers the two major sub-modes (extract vs normal), the scope/recall-tier mechanics, the defer_embed flow, cross-references memo_reindex, and notes CLI parity. For a tool this complex, this is complete.
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. The description adds meaningful value by explaining the interaction semantics between parameters: extract's decomposition behavior, scope's 'global'/None distinction and the project tag precedence ('An explicit project: tag in tags always wins'), and defer_embed's mirroring of the CLI flag with the extraction-mode exception. Parameters like title/type/auto_derive are adequately covered by schema alone.
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 verb ('Persist `content` to memo') and resource, and explicitly distinguishes memo_save from memo_offload ('durable curated fact, decision, or preference' vs 'bulk dumps of working context'). The scope of what gets saved is precise and it differentiates from the closest sibling.
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?
The description provides explicit usage guidance: 'Use memo_save for a durable curated fact, decision, or preference; use memo_offload for bulk dumps of working context.' It also explains mode-specific behaviors (extract vs normal) and how scope/auto_derive/defer_embed each alter behavior, giving the agent clear conditional decision-making 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. Description adds value by listing specific statistics (corpus count, storage paths, etc.) and explicitly stating 'Read-only', reinforcing the safe behavior.
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 concise sentences with no wasted words. The most critical information (purpose and usage) is 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?
Given the presence of an output schema, the description provides sufficient context by listing example statistics and noting 'when available'. The no-parameter tool with clear annotations is fully described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so the description does not need to add parameter info. It explains what the tool returns, which fully compensates for the absence of parameters.
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 clear verb 'Return' and specific resource 'local memo corpus and runtime statistics'. It distinguishes itself from sibling tools by focusing on diagnostics and health checks, and enumerates the included fields.
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 'Use for diagnostics, health checks, and environment inspection', providing clear context. No direct alternatives mentioned, but the purpose is well-defined.
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?
Even with annotations declaring readOnlyHint and destructiveHint, the description adds substantial context: it details the AdvancedConsolidator algorithm, sampling behavior, budget-derived defaults, response size calculations, and the middleware refusal rather than truncation. This far exceeds what the annotations alone convey.
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 front-loads the purpose in the first two sentences, then follows with a logically organized explanation of algorithm, parameters, and budget. It is verbose, but every sentence carries useful information, so the length is justified.
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 output schema exists and annotations cover safety, the description completes the picture: it explains the algorithm, parameter trade-offs, default rationale, and failure behavior (budget middleware refusing overruns). No critical context appears missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage, but the tool description adds non-obvious rationale: why defaults are 10x2, the token budget math, and that two sample members are enough to see a duplicate. These insights go well beyond the schema's per-parameter descriptions.
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 first sentence, 'Detect near-duplicate clusters and propose merges,' is a specific verb+resource statement that clearly defines the tool's function. It also immediately clarifies the read-only nature, distinguishing it from any actual merge-execution tool.
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 states 'Read-only — returns proposals without modifying the corpus,' providing clear context for when to use the tool. It does not explicitly name an alternative for actually performing merges, but the read-only framing makes the intended use case clear.
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 readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context beyond annotations: it explains that the pack includes dynamic recent context (up to 5 memories updated in last 7 days), static profile, query hits, omissions, and is read-only. It also mentions budget trimming. No contradiction.
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 two sentences long. First sentence states purpose clearly. Second sentence elaborates on content and differentiates from sibling. No wasted words, front-loaded with key 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?
Given that an output schema exists, the description need not explain return values. It covers purpose, behavioral traits, and high-level output structure. All relevant aspects are addressed for a tool of this 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%, so the schema already documents all parameters. The description does not add specific parameter semantics beyond the schema, but it does provide context on how budget_chars and snippet_chars affect output. 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 clearly states the tool's purpose: 'Build prompt-ready memory context without calling the answer LLM.' It contrasts with memo_search's raw hit list, specifying that this returns a budgeted, prompt-ready context pack with static profile, dynamic recent context, query hits, omissions, and a readonly prompt wrapper. This distinguishes it from siblings and is specific about what it does.
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?
The description explicitly says 'Read-only. Unlike memo_search's raw hit list, this returns a budgeted, prompt-ready context pack for direct injection.' It tells when to use this tool (when needing a prompt-ready pack) and when to use an alternative (memo_search for raw hits). This provides clear guidance.
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 provide destructiveHint=true, and description elaborates: hidden from recall/search until memo_unforget restores it. Reversible nature clearly stated. No contradictions with 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?
Three concise sentences, front-loaded with main purpose, no wasted words. Efficiently conveys all necessary 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?
With output schema present and low complexity (2 simple params), the description covers all needed aspects: purpose, effect, parameter roles, and relationship to sibling tools.
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%, but description adds value: for 'id' mentions 'unique prefix' not in schema; for 'reason' explains purpose. Adds meaningful context beyond 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 clearly states 'Mark one memory as forgotten without deleting its history.' It uses a specific verb (mark) and resource (memory), and distinguishes from siblings like memo_delete and memo_unforget.
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?
Explanation of destructive retrieval behavior and mention of memo_unforget for restoration provides context. Could explicitly state when to use memo_delete instead, but the guidance is clear enough.
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 read-only, idempotent, and non-destructive hints. The description adds substantial behavioral context: the memory-only default, how include_code folds in the codegraph, the meaning of 'why' as a weighted path, and cursor-driven pagination for architecture. This goes beyond the annotations and clearly explains what the tool returns and how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough but well-structured: a one-line summary followed by a bulleted list of verbs with concise explanations. It is front-loaded with the main purpose and no sentence is redundant. Despite its length, it is appropriately sized for the tool's complexity.
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 12 parameters, 7 verbs, and an existing output schema, the description covers all operational aspects: verb definitions, parameter roles, default behavior, include_code toggle, pagination via cursor, and limits. The output schema provides return details, so the description is complete for effective tool selection and invocation.
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?
The schema already describes all parameters, so the baseline is 3. The description adds value by mapping verbs to parameters (e.g., 'path' uses a and b, 'impact' uses cwd, 'neighbors/explore' use entity or a) and by explaining the semantics of include_code and cursor. This is more than the schema alone 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 opens with a clear verb+resource statement: 'Navigate the entity knowledge graph (read-only).' It then enumerates specific sub-operations (path, why, neighbors, explore, communities, impact, architecture), which distinguishes it from sibling tools like memo_search or memo_get. The scope is very clear.
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 clear context for each verb and explains the default memory-only behavior with include_code to add the codegraph layer. It does not explicitly name alternative tools or when not to use it, but the context is strong enough to infer its intended use-case.
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 readOnlyHint, idempotentHint, and destructiveHint=false. The description adds behavioral context: 'List recent memories' implying default sorting by recency, and 'Read-only' confirms the safety trait. No contradictions, and the description enriches understanding beyond 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?
Three sentences with every line earning its place: purpose, usage guidance, and parameter context. Front-loaded with the verb 'List' and resource. No filler or repetition.
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 tool's simplicity (2 optional params, full schema coverage, output schema present, and clear annotations), the description is complete. It explains the browsing workflow, the filtering behavior, and the limit cap, which is sufficient for the agent to use the tool correctly.
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%, so baseline is 3. The description mentions '`limit` caps the number of returned records' and 'optionally filtered by memory type', but these add no new meaning beyond what is already in the input schema descriptions. No value is added to parameter understanding.
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 it lists recent memories with optional filtering by type, and explicitly differentiates it from other memo tools by positioning it as a browsing step before using get/update/delete/history tools. The verb 'List' combined with the resource 'memories' and scope is 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use this to browse the corpus before choosing an id for memo_get, memo_update, memo_rename, memo_delete, or history tools.' This tells the agent when to use this tool and what alternatives to use after, plus notes about the `limit` parameter.
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 show readOnlyHint=false, confirming it's a write operation. The description adds that it creates or refreshes a tracked session checkpoint. It does not elaborate on side effects like whether calling it multiple times is safe or has cumulative effects, but it provides sufficient context given the annotations are minimal.
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 concise at 4 sentences, well-structured with clear intent, usage, parameter guidance, and a caution against misuse. Every sentence adds value, and the structure is front-loaded with the core purpose.
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 output schema exists (context indicates 'Has output schema: true'), the description does not need to explain return values. It covers purpose, usage, parameter semantics, and differentiation from sibling tools. For a session start tool, this is comprehensive.
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% with descriptions. The description adds behavioral context beyond the schema: 'Pass session_id to continue a known session; omit it to create one. Pass cwd to bind the session to a project directory; omit it to use the current process directory.' This provides practical guidance not captured in the schema alone.
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 starts a new session for the client. It specifies it's a write tool that creates or refreshes a session checkpoint used by capture, grounding, and transcript lookup. It distinguishes itself from memo_save and memo_save_text by clarifying it is not for saving memories.
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 usage guidance is provided: 'Call once at the beginning of a task or conversation.' It explains when to pass session_id (to continue a known session) vs omit (to create a new one), and when to pass cwd (to bind to a project). It also explicitly states when not to use the tool and directs to alternatives (memo_save/memo_save_text for durable content).
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 idempotent and non-destructive. Description adds that it returns a boolean indicating success and accepts prefixes, going beyond 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?
Three sentences, front-loaded with purpose, no unnecessary words. Every sentence adds value.
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 one parameter, strong annotations, and implied output schema, description fully covers what agent needs: purpose, when to use, input constraints, and return value.
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?
Only one parameter 'id' with schema description. Description adds that it can accept a unique prefix, which is valuable extra semantics.
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?
Clearly states it restores a forgotten memory to normal retrieval, using a specific verb and resource. Distinguishes from sibling tools like memo_forget.
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 guidance: use after deciding a memory should participate in search and recall again. Mentions idempotency and acceptance of unique prefix.
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?
Discloses beyond annotations: confirms destructive only to the notification queue, never deletes memories or transcripts, and explains the pop-and-remove behavior.
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 a clear first sentence, but slightly verbose with three sentences; could be trimmed slightly without losing clarity.
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 no parameters and annotations present, the description fully explains behavior, return value, and usage context; output schema exists so return details are not needed.
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?
No parameters, and schema coverage is 100%. The description adds context that the tool operates on the pending notification implicitly, meeting the baseline for zero params.
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 reads and dismisses a pending idle-capture notification, differentiating it from siblings like memo_search and memo_list for reading durable records.
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 (after memo_idle_capture or before replying) and when not to use (for reading durable memory records, use memo_search or memo_list).
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 readOnlyHint and idempotentHint. Description adds 'Read-only' and explains limit semantics (no clamp, oldest-first order, has_more truncation flag), providing context beyond 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?
Three clear, front-loaded sentences. No filler words; each sentence provides distinct information about purpose, usage, and parameter behavior.
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 only 2 parameters and output schema present, description covers id input format, limit behavior, and use case. No gaps remain for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds meaning: explains id prefix resolution (error if ambiguous) and limit behavior (max events, no clamp, ordering, has_more). This significantly enhances understanding.
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 'Return recent history events for one memory in chronological order.' It specifies a concrete verb and resource, and distinguishes this tool from siblings like memo_history by focusing on recent diff events.
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 explicit use case: 'Use to inspect how a memory changed over time before editing or rolling back.' It explains id prefix and limit behavior but does not explicitly mention when not to use it.
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?
Discloses idempotent behavior (deduplication), deterministic synopsis, and that offloaded blobs are excluded from auto-recall. These add context beyond annotations (idempotentHint=true) and enhance behavioral understanding.
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 concise paragraphs with front-loaded purpose, clear structure. Every sentence adds meaningful information without redundancy.
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 output schema presence and rich annotations, the description fully covers behavior: what tool does, when to use, idempotency, output format (types of fields), and how to retrieve content later with memo_get.
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 already documents parameters with 100% coverage. Description adds value by explaining verbatim storage, rejection criteria for content, and auto-generation for title when null. Minor improvement over 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's purpose: offloading bulky payloads out of the context window, content-addressed storage in reference-tier memory. It differentiates from memo_save by contrasting bulk dumps vs. curated durable facts.
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 this tool ('bulk working-context dumps') versus memo_save ('curated durable facts meant to be recalled'). Also explains idempotency and auto-recall exclusion.
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 mark destructiveHint=true; the description reinforces 'Destructive metadata edit' and adds context on behavior of omitted id (targets most recent save). No contradictions.
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?
Every sentence serves a purpose: first states action and scope, second flags destructive nature, third gives use case and parameter advice. No wasted words.
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 annotations and output schema, the description covers purpose, usage, parameters, and behavioral traits comprehensively for a simple rename operation.
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% with descriptions for both parameters; the description adds practical nuance about when to omit id (only after a save). This justifies a score above baseline 3.
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 verb 'rename' and the resource 'memory title', and explicitly distinguishes from siblings by noting 'without changing its body or tags' and referencing memo_update for editing other fields.
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 context ('after memo_save or memo_search when a record has the right content but the wrong title') and when-not-to-use ('Use memo_update instead when you need to edit content, type, or tags').
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 provide readOnlyHint=true and idempotentHint=true; description confirms read-only and adds behavioral details: no retrieval, adds 'rerank_score' field, drops non-dict entries, and handles disabled state gracefully. No contradiction with 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?
Three concise sentences front-load the purpose and key differentiator, then cover usage and edge case. No filler; every sentence earns its place.
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 output schema exists, description need not detail return values. It covers purpose, usage, behavior (including disabled state and score addition), and interaction with parameters. Annotations and schema complement fully.
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 covers 100% of parameters with descriptions. Description adds extra meaning for hits (scored on title/snippet/body, adds rerank_score, drops non-dicts) and query (empty returns unchanged). This adds value beyond schema, justifying above baseline 3.
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 starts with 'Rerank candidate memory hits for a query', specifying a clear verb and resource. It distinguishes from sibling memo_search by stating it performs no retrieval of its own, making its unique purpose explicit.
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 tells when to use: after memo_search or another retrieval source, for answer synthesis. Also mentions an alternative (memo_search) and explains behavior when reranking is disabled, giving clear usage boundaries.
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:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/jagoff/memo'
If you have feedback or need assistance with the MCP directory API, please join our Discord server