mnemosis-mcp

by liyexiaoyi

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.2.2
Disambiguation2/5
With 98 tools, many share overlapping responsibilities (e.g., practice_report/practice_session/practice_due/practice_answer; memory_status/memory_audit/memory_health/memory_map/stats; sleep/sleep_replay/sleep_and_plan; plan/replan/plan_rewrite/plan_quality/plan_tracker). An agent selecting a tool will frequently need to parse subtle description differences, and several report tools seem to summarize the same underlying state.
Naming Consistency4/5
Tool names mostly use snake_case and many follow verb_noun, but there are many noun-phrase names (memory_health, schema_report, lifecycle_audit, dependency_map, concept_cover) and one-word commands (sleep, check, update, plan, search). This is a readable convention but not consistently predictable.
Tool Count1/5
98 tools is extreme for any MCP server. Even if each tool has a cognitive justification, this scale makes the tool set hard to navigate and causes selection latency, so it is not well-scoped.
Completeness5/5
The surface covers the full memory lifecycle—store, retrieve, update, forget, restore, batch review, spaced repetition, sleep consolidation, intentions, planning, reasoning, exports, and audits. There are no obvious dead ends; every major operation appears to have at least one tool.
Average 3.3/5 across 98 of 98 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 651 commits in the last 12 weeks
- Last stable release on August 9, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It only mentions metacognitive aspects but does not explain what the tool does (e.g., returns a report, mutates state, or requires specific permissions). No behavioral traits 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but brevity is not conciseness when it omits essential information. It is under-specified rather than efficiently worded, offering little value for the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and any parameter explanations, the description is grossly incomplete. An agent would have no idea what to pass as 'query', what 'top_k' controls, or what the returned data looks like. It fails to provide even minimal context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the parameters. It fails to mention 'query' or 'top_k', leaving their purpose and format entirely unexplained. The description adds no meaning beyond the bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool is a 'metacognitive check' covering confidence, contradictions, gaps, and blocked states, but it lacks a specific verb or resource. It does not clearly differentiate from sibling tools like 'reasoning_trace' or 'conflict_advice', which likely cover similar concepts. The purpose remains ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No prerequisites, exclusions, or alternative tool mentions are provided. The description offers zero usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to state whether the operation is read-only, how results are formatted, whether the 'limit' parameter affects output, or any side effects. The description is too vague to inform an agent about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It is not a complete sentence and omits essential details. While it wastes no words, it also provides no usable structure or front-loaded key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no output schema, and no annotations, the description must explain what the tool returns, how to invoke it, and why to use it. The current text is a fragment that does not describe return values, input semantics, or integration with the broader memory system. It is wholly inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines a 'limit' integer but provides no description, and the tool description does not mention it at all. With 0% schema description coverage, the description should compensate but offers zero semantic information about this parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a noun phrase ('Recently used memories for prompt injection') with no explicit verb, so it's unclear whether the tool lists, retrieves, or formats these memories. It names a resource ('recently used memories') and a context ('prompt injection'), but does not differentiate from sibling tools like 'recall' or 'search'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The phrase 'for prompt injection' hints at a use case, but it does not explain scenarios, prerequisites, or when other tools would be more appropriate. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description carries the full burden of behavioral disclosure. It reveals nothing about side effects, return format, read-only nature, or any operational characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, which might seem concise, but it is under-specified. 'Memory statistics.' is a vague fragment that does not earn its place without additional meaningful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description needs to explain what statistics are returned and in what form. It fails to do so, leaving the tool's behavior almost entirely ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. The empty schema and the description imply there are no inputs to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Memory statistics.' is a noun phrase that essentially restates the tool name with a domain qualifier. It provides no action verb and does not differentiate from sibling tools such as memory_status or similarity_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No context, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects, safety, and return behavior. It reveals a dependency on stored formulas and a pedagogical approach (concreteness fading) but does not state whether the tool reads or writes memory, what output it produces, or any potential side effects. The metaphor obscures operational certainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and not overly long, but it is dense with a metaphor and a parenthetical citation that add little operational value. While compact, it lacks the clear, front-loaded structure expected for an API description; the citation could be omitted without loss of usage-relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a sparse input schema, the description should clearly state what the tool does, how to invoke it, and what to expect. It does none of these adequately: parameters are unexplained, output is not mentioned, and the tool's behavior is buried in metaphor. For a simple 2-parameter tool, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention 'problem' or 'top_k' at all. The tool has only two parameters, but the description provides zero insight into what values they accept or how they influence the ladder process. This is a complete failure to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description indicates a distinct math-focused approach ('Climb the math abstraction ladder') and mentions a specific method (concrete -> symbolic -> general rule), which differentiates it from siblings. However, the verb 'climb' is metaphorical and does not clearly state the tool's operation (e.g., generate, explain, transform), leaving the actual functionality vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided regarding when to use this tool versus alternatives. The phrase 'using formulas already stored in memory' implies a prerequisite (formulas must be in memory), but there is no mention of scenarios, exclusions, or comparisons to sibling tools like numeric_reasoning or practice_report.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it revises a memory and adds the term 'reconsolidation' for context, but it does not explain effects, reversibility, required permissions, or what happens during the revision process.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief—one short sentence. While this is concise, it is under-specified and does not convey enough information to be useful. The term 'reconsolidation' is jargon that adds some flavor but does not substitute for substantive guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and no output schema, the description is severely incomplete. It provides no detail about inputs, outputs, side effects, or use context, making it inadequate for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters, but the description provides zero parameter-level context. It does not mention memory_id, content, cues, confidence, or importance, leaving the agent without any guidance on how to populate them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Revise' with resource 'memory', clearly indicating a modification operation. It distinguishes from siblings like 'remember' (create), 'forget' (delete), and 'restore' (undo), though not as explicitly as desired.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisite conditions, exclusions, or scenarios where other memory tools 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects, persistence, overwrite behavior, and similar traits. It only states 'Store a memory' without revealing whether this creates a new record, overwrites existing ones, or requires specific preconditions. The parenthetical types are already reflected in the schema enum, adding no extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no redundancy and is front-loaded. However, for an 8-parameter tool, it is arguably too terse to be 'appropriately sized,' though every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no annotations, and no output schema, the description is drastically insufficient. It lacks return value information, parameter semantics, and usage context, making it incomplete for an AI agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description mentions no parameters, including the required 'content'. It does not explain the meaning of cues, affect, confidence, importance, or evidence_count, failing to compensate for the schema's lack of descriptive text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Store' with resource 'memory' and notes types '(episodic or semantic)', clearly distinguishing from retrieval tools like recall and forget. However, it does not explicitly distinguish from the sibling 'remember_turn', leaving a slight 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives or exclusions. The only hint is 'Store a memory,' which implies usage but does not state conditions, and siblings like remember_turn suggest an alternative without any distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It explains the conceptual outcome (lessons as schemas) but does not reveal whether the operation is read-only, whether it modifies memory, what inputs are expected, or any side effects. The reference to 'Bartlett 1932' adds obscure context without practical transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the core action. However, the parenthetical '(schema reuse, Bartlett 1932)' is cryptic and unnecessary, adding noise rather than clarity. Still, it is compact and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no parameter descriptions, and no output schema, the description is severely lacking. It gives a high-level concept but omits essential operational details: how parameters work, what the output structure is, whether memories are affected, and when to use it. The agent cannot reliably invoke this tool based on the provided information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the parameters 'limit' or 'memory_ids' at all. The agent is left with no explanation of what these parameters mean, their format, or how they affect the extraction. The description adds no value to the bare schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts lessons learned from project memories and presents them as reusable schemas. This is a specific verb ('extract') with a clear resource ('project memories') and outcome ('reusable schemas'). It does not explicitly distinguish from sibling tools, but the focus on lessons/schemas is unique enough to avoid major confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any conditions, exclusions, or related sibling tools. It implies it is for distilling lessons, but gives no context about scenarios where this would be preferred over other memory-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only says memories are recalled 'matching a query' but gives no details about return format, limits, side effects, or operational characteristics. This is minimal and insufficient for a tool with no safety 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is concise and easily parsed, though it sacrifices substantive content for brevity. That is acceptable for this dimension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, no annotations, and many siblings, the description is severely under-specified. It fails to explain parameter semantics, return value shape, filtering behavior, or differences from similar tools. This is inadequate for effective autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate by explaining parameter meanings. It only implies 'query' and provides no information about 'kind', 'top_k', 'context', or 'embedder'. The description adds minimal value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Recall') and resource ('memories') with a query-based selection criterion. It is clear what the tool does at a basic level, but it does not distinguish itself from sibling tools like 'search' or 'search_batch', which may also retrieve memory-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or exclusions, leaving the agent without context for tool selection among the many sibling memory tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It provides some algorithmic detail (grouping criteria) but does not state whether the operation is read-only, what output is generated, or any limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence conveying the core purpose without unnecessary words. However, the phrase 'primary cue' and the citation add some density, making it slightly less clear than ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity (one optional parameter), the description lacks essential information about return values, how limit affects results, and the precise meaning of 'primary cue.' No output schema or annotations exist, so the description is the only source and it is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'limit' parameter is not mentioned in the description, and the schema provides no description for it. With 0% schema coverage, the description does not compensate, leaving the parameter's meaning and effect entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool groups memories into topic schemas based on specific criteria (cluster size, average importance, kind mix, samples). It identifies a specific verb and resource, but does not explicitly differentiate from sibling report tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus other reporting tools like similarity_report or association_report. The description only defines what the tool does without providing usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the return value (number imported) but does not mention whether existing memories are affected, deduplication behavior, authentication requirements, or side effects of importing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that places the action first and includes the key input and return value. There is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should compensate with richer context. It only states the basic function and return count, but omits critical details like format expectations, merge/replace behavior, and any constraints, making it incomplete for a potentially mutating operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'payload' with no description, and schema coverage is 0%. The description only says 'from an export payload', which gives no structural detail. This is inadequate for understanding what to pass, especially since payload is a nested object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool imports memories and specifies the source (export payload) and return value (count). It distinguishes from export_memories as the counterpart, though it doesn't explicitly differentiate from other memory-related tools like restore.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. The mention of 'export payload' implies it's for restoring previously exported data, but there are no direct references to sibling tools or exclusion scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden for behavioral disclosure. It only lists metrics and a citation; it does not state whether the tool executes queries, whether it is read-only, what the return format is, or any side effects or dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. The parenthetical reference to Koriat & Goldsmith is somewhat extraneous for an AI agent, but it does not bloat the text, and the overall structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero schema coverage, no annotations, and no output schema, the description is grossly incomplete. It lacks information about parameter usage, expected output, edge cases, or how this tool fits into the broader retrieval workflow, making it inadequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to explain any of the three parameters (limit, top_k, queries). The only implicit hint is 'across queries,' which vaguely alludes to the queries parameter but does not clarify its format or the roles of limit and top_k.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as measuring retrieval quality and enumerates specific metrics (average top score, retrievability, hit rate, weak rate). This distinguishes it from sibling tools that perform retrieval (e.g., search, recall) or general reporting (e.g., stats, practice_report).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios, prerequisites, or exclusions, leaving the agent without context for selection among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It describes what the loop includes but does not disclose side effects, state changes, prerequisites, or return behavior. 'Build' suggests a generation action, but the tool could be read-only or mutating without any clarification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, focused sentence that front-loads the main action ('Build a ready-to-run learning loop') and then lists the key outputs. The parenthetical about cognitive techniques adds useful context without bloating the description. Very efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one undocumented parameter, no output schema, and no annotations. The description explains the high-level purpose but omits crucial details: what 'count' controls, what the output structure looks like, and any prerequisites. For a build tool, this is insufficient for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter ('count') with no description, and the tool description never mentions it. With 0% schema description coverage, the description should explain the parameter but instead omits it entirely, leaving the agent without any guidance on how to populate 'count'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair ('Build a ready-to-run learning loop') and enumerates the concrete outputs (what to review first, a self-test question, and a snapshot). This clearly distinguishes it from sibling tools like practice_plan or spacing_plan by framing it as an integrated loop rather than a single plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., practice_plan, spacing_plan, review). The phrase 'ready-to-run' implies a use case for those wanting an actionable loop, but no exclusions or comparison is provided, leaving the decision to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It hints at a read-only prediction mechanism ('prediction-error updated records') but does not state whether it has side effects, requires special permissions, or what the output format is. The lack of safety disclosure for a tool that could be read-only is a notable deficiency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys the core purpose without any filler. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), but the description leaves critical gaps: the meaning of 'step', when to use it relative to siblings, and expected output. It is minimally adequate for a simple tool but not fully complete given the ambiguous parameter and lack of alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain what the 'step' parameter should contain or its format. The tool name and description mention 'step', but no additional meaning is provided to help the agent construct a valid parameter value. This is a complete failure to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('predict') and resource ('step's success probability'), with a mechanism ('outcome history with prediction-error updated records'). It is clear but does not explicitly distinguish from sibling prediction tools like 'practice_forecast' or 'forecast', so it loses one point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description only explains what it does, with no mention of use cases, exclusions, or prerequisites. Given the large list of sibling tools, this is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full burden of behavioral disclosure. It only states a mutation ('Record') and the outcome type, but does not describe side effects (e.g., updating scheduling, idempotency), required prior state (e.g., memory must exist), or any other behavioral traits. This is a significant transparency gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the key action and subject. No wasted words; it efficiently conveys the core purpose. Structure is appropriate for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description is the sole source of context. It is too sparse given the large sibling set and the nature of the operation (recording an outcome could have downstream effects). The description does not explain the workflow, prerequisites, or relationship to other tools, making it incomplete for an agent to use correctly in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The description hints that 'success' is a boolean for success/fail, adding some meaning beyond the schema's bare boolean type. However, it does not explain 'memory_id' or what happens if 'success' is omitted. The description provides minimal semantic value for one parameter and none for the other.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Record') and identifies the resource ('spaced-repetition outcome') and the data shape ('success/fail'). This is clear about what the tool does, though it does not explicitly differentiate itself from similar siblings like 'record_outcome' or 'review_batch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool vs alternatives. The description only states the action ('Record a spaced-repetition outcome') without mentioning context, prerequisites, or exclusions. There is no 'use this when...' or 'instead of...' guidance, leaving the agent without clear direction on selecting this tool among many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It lists the report contents but doesn't explicitly state that the operation is read-only, whether any permissions are required, or how 'status' is determined. The word 'Report' suggests non-mutation but lacks explicit confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with 'Report', and every listed metric carries meaning. No redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a report tool with one optional parameter and no output schema, the description leaves out essential context: what 'per topic schema' entails, the semantics of 'status', and the effect of 'limit'. It is not fully self-contained for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'limit' parameter has 0% schema description coverage and the description never mentions it, leaving the agent to guess its function (pagination vs. aggregation) entirely unaided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb 'Report' and resource 'review coverage per topic schema', listing concrete metrics (memory count, reviewed count, coverage ratio, average retrievability/importance, status). It distinguishes from sibling report tools by focusing on review coverage per schema, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to obtain coverage statistics but doesn't provide any when-to-use/alternatives guidance. With many sibling report tools, this creates ambiguity about when to select this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions adaptive spacing but doesn't state whether the tool reads or modifies memory intervals, what output it returns, or any side effects. The verb 'recommend' implies a read-only operation, but this is not made explicit. No info about error handling or performance is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence. It front-loads the action and object, and every word earns its place. The citation adds credibility without fluff. It is neither under-specified nor verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter) but lacks output schema and annotations. The description does not explain what the function actually returns (e.g., an interval value, in days/weeks), what happens when memory_id is omitted, or how 'retrieval history' is defined. This is not complete enough for an agent to confidently invoke it without further assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the 'memory_id' parameter at all. Schema description coverage is 0%, and the description fails to compensate by explaining the role of the parameter or whether it is optional. The phrase 'each memory' is vague about whether memory_id selects one or multiple. This leaves the only parameter completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Recommend each memory's next review interval') and specifies the data source ('from retrieval history') and method ('adaptive spacing'). It distinguishes itself from siblings by explicitly naming the adaptive spacing algorithm and citing a study, making it clear this is about interval computation, not planning or reporting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. Sibling tools like 'spacing_plan' and 'practice_plan' could overlap, but the description does not mention any conditions, exclusions, or alternative tool names. The use case is only implied by the natural language.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It does not state whether the tool is read-only, whether it has side effects on stored plans, or what it returns. The word 'Track' could imply monitoring, but it's not explicit. This lack of detail is risky for an agent invoking the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the main action and key details. The parenthetical status list and the citation add context but are not strictly necessary for tool invocation. It is concise and well-structured, though the citation is a minor distraction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two parameters, nested objects, and no output schema, yet the description does not explain the expected format of 'plan' or 'statuses', nor what a completion ratio means in practice. It also fails to describe the return value or side effects. For a tool with this complexity, the description is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must explain the parameters. While it hints that 'plan' contains steps and statuses appear in parentheses, it does not clarify the structure of the 'plan' array or the 'statuses' object, nor how they relate. The description adds minimal semantic value beyond what the schema shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Track') and resource ('execution status of each plan step'), clearly distinguishing it from sibling tools like 'plan' or 'replan'. It also enumerates the status values and mentions a completion ratio, making the tool's function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description states what it does but not in which situations it should be preferred over siblings like 'plan', 'replan', or 'plan_quality'. This is a clear gap for a tool in a large family of plan-related utilities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state whether the tool is read-only, whether it has side effects, what permissions are needed, or what the output format is. The phrase 'memory-driven risk management' hints at behavior but fails to disclose key traits needed for safe and correct invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, reasonably concise sentence that front-loads the main verb and resource. It avoids unnecessary words, but the parenthetical list could be more specific. Overall, it is well-structured and economically written, though not exceptionally detailed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should explain return values and parameter usage. It fails to do so—it never states what the 'score' looks like, how it is returned, or what compare_limit controls. For a tool with two parameters and no schema descriptions, this is a significant completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It mentions 'memories' which likely maps to memory_ids, but it does not explicitly explain the parameter, and compare_limit is completely unexplained. The description adds minimal meaning beyond the schema field names, leaving the agent to guess parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Score project risk from memories and intention state.' It lists example inputs (known problem traces, conflicts, overdue intentions, clashing schedules), which gives a distinct purpose. However, it does not explicitly differentiate from related sibling tools like list_conflicts or conflict_advice, so it stops short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for risk assessment based on memory and intention data, but it provides no explicit guidance on when to prefer this tool over alternatives such as list_conflicts or conflict_advice. There are no stated exclusions or alternative tool references, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only states the action without describing side effects, output, or read/write nature. It doesn't even clarify whether this is a retrieval or computation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with no filler, though the phrase 'Reasoning recall' is somewhat redundant with the tool name. Still, it's well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks essential context about what a 'premise pack' is, what the output looks like, and how top_k influences results. For a two-parameter tool with a likely complex reasoning task, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters with zero description coverage. The description hints that 'query' should be a math/compare/transitive question, adding some context, but 'top_k' is completely unaddressed. Given the low coverage, the description should compensate but only does minimally.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'assemble' with the resource 'premise pack' and scopes it to 'math / compare / transitive question,' giving a clear action and domain. It distinguishes from generic recall tools by specifying the reasoning context, though 'premise pack' is not fully defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage for math, compare, or transitive questions, which gives some contextual guidance. However, it does not explicitly state when to avoid this tool or mention alternatives like 'recall' or 'reasoning_trace,' leaving differentiation incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses that the tool performs multiple steps (scoring, diffing, planning) and references 'testing effect + knowledge tracing', but it does not explain side effects, whether it modifies state, what 'snapshot' means, or what is returned. For a complex session tool, transparency is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs several actions, but it is not overly verbose. It front-loads the primary action ('Run one end-to-end learning session') and tacks on specifics. While slightly dense, it avoids redundancies and earns its place, though splitting into bullets could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks both annotations and an output schema, and the description omits crucial context such as the meaning of 'second snapshot', the format of answers, and the expected result. For a tool with two undocumented parameters and a multi-step operation, this description is too thin for an agent to invoke correctly without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero descriptions for the two parameters (count, answers), and the tool description does not explain them. 'count' could be the number of attempts, and 'answers' likely holds practice data, but nothing clarifies their meaning or relationship. With 0% schema coverage and no compensating description, parameter semantics are not established.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs an end-to-end learning session and enumerates specific sub-actions (score practice attempts, diff a second snapshot against baseline, plan next loop). This provides a specific verb and resource, and distinguishes it from related siblings like practice_session or learning_loop by describing its multi-step process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for a comprehensive learning session that combines scoring, diffing, and planning. However, it does not explicitly state when to use this tool versus alternatives like practice_session or learning_loop, nor does it mention exclusions or prerequisites. The usage context is implied but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It does not mention whether the operation is read-only, what it returns, side effects, or any constraints. The citation of theoretical frameworks adds context about the algorithm but not 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the core function. The citations add minor extraneous information but do not significantly bloat the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description is insufficient. It omits parameter meanings, return format, and any behavioral context, leaving the agent to make guesses about how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention 'limit' or 'min_structure' at all. The agent has no way to infer what these parameters do, and the description does not compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: finding cross-topic memory pairs with shared structure for analogical transfer. The verb 'Find' is specific, and the resource 'cross-topic memory pairs' is unique among siblings, distinguishing it from search/recall 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied through 'for analogical transfer,' indicating when this tool is appropriate. However, there is no explicit guidance on when to use this vs. alternatives like recall or search, and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It explains the ranking logic but does not disclose whether this tool is read-only or has side effects, what the output format is, or how the 'limit' parameter affects behavior. The intent is clear, but side effects and return behavior are unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action and criterion. It contains no filler, but the formula 'importance x forgetting' is slightly terse and could be expanded without adding waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter, no output schema, and no annotations, the description is insufficient. It does not explain what the returned data looks like, how 'limit' works, or when to use this tool compared to the many sibling review/ranking tools. The core purpose is complete, but operational details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, 'limit', with zero schema description coverage. The tool description does not mention 'limit' at all, failing to compensate for the lack of schema documentation. The parameter's semantics (e.g., max number of results, threshold) remain entirely ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Rank memories by forgetting risk' with a defined formula ('importance x forgetting') and a clear purpose. It distinguishes itself from sibling tools like review_due or practice_report by focusing specifically on risk-prioritization for review.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'the riskiest ones should be reviewed first' implies the tool is for prioritizing review order, but it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. The usage context is only implied, not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It discloses the internal ordered phases and cites the intuitive physics engine, adding behavioral context beyond the name. However, it does not mention side effects, return format, or whether the tool mutates state, which is relevant given the absence of 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the main action front-loaded in the first sentence. The second sentence adds process detail and citations, but the citations are likely unnecessary for tool invocation and add noise. Overall, it is efficient without being overly terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is incomplete. It gives an overview of the process but omits critical details such as expected input format, meaning of top_k, and what the simulation returns. The agent lacks enough information to confidently invoke the tool correctly without further clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameters. It does not mention 'scene' or 'top_k' at all. The description's generic 'detect scene type' gives only a weak hint about the scene parameter, while top_k is completely unexplained. The agent would have no way to know what top_k controls or how to format the scene input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Run') and resource ('mental physics simulation'), and outlines a multi-step process (detect scene, extract quantities, recall laws, play forward). This distinguishes it from sibling tools like numeric_reasoning or reason by focusing on physics simulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It does not mention any exclusions or competing tools, and the context is only implied by the name and description. The description lacks statements like 'use this for physics scene understanding' or 'instead of numeric_reasoning when physical dynamics are involved.'
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?
The description adds context for the desirable_difficulty parameter, defining it as 'hard but likely to succeed'. However, with no annotations, it fails to mention side effects, pagination, or return format, leaving significant behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no filler. It is front-loaded and efficiently conveys the core purpose and one key option.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters, no annotations, and no output schema, the description is too sparse. It explains only one parameter and omits behavior, return format, and usage context, making it incomplete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the 'desirable_difficulty' parameter but leaves 'limit' and 'difficulty_target' unexplained, adding partial meaning but not enough to cover the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists memories due for spaced review, with an optional preference for desirable-difficulty items. It uses a specific verb and resource, but does not explicitly distinguish from sibling tools like 'review' or 'review_batch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'review' or 'practice_due'. It only hints at the desirable-difficulty option but gives no context for choosing this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds value by revealing the output includes a confidence flag and reasons, and mentions that 'context-dependent recall and all retrieval mechanisms apply', which hints at behavioral complexity. However, it does not explicitly state whether the operation is read-only, whether it has side effects, or what 'all retrieval mechanisms apply' concretely entails, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, consisting of a single sentence with a parenthetical. It front-loads the primary purpose and packs in the return details without unnecessary fluff. The parenthetical is slightly vague but does not waste words, making it efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema (3 strings), no annotations, and no output schema, the description provides a reasonable overview of core functionality and return values, which helps the agent understand what to expect. However, it is incomplete in explaining the 'context' parameter and lacks usage guidance relative to many similar sibling tools, so an agent may struggle to choose this tool appropriately or construct the context input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), so the description must compensate. It clarifies 'query' (the search input) and 'top_k' ('returns the top-k matches'), but the 'context' parameter is only indirectly referenced via 'context-dependent recall' without explaining its format, optionality, or effect. This leaves a significant gap for the agent to know how to populate the context parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: 'Retrieve memories for a query' with a specific resource (memories) and action (retrieve). It also details the return format (top-k matches with content, score, confidence flag, reasons), making the purpose specific. However, it does not explicitly differentiate from sibling tools like 'search_batch' or 'recall', though the top-k scoring detail implies a single-query ranked search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'search_batch', 'recall', or 'remember'. It lacks any mention of prerequisites, exclusions, or context in which this tool is preferred. The only hint is 'context-dependent recall', but it doesn't explain practical usage scenarios or boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries a heavy burden for behavioral transparency. It only states what the tool does (compares distributions) and mentions 'schema reconstruction' and Bartlett 1932 as theoretical context, but it does not disclose whether the tool is read-only, has side effects, or any other behavioral traits. The description lacks transparency about safety and state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and generally clear. However, the parenthetical '(schema reconstruction, Bartlett 1932)' adds a theoretical reference that may be extraneous for tool selection and invocation, though it does not significantly bloat the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two parameters, no output schema, and no annotations. The description gives a high-level overview but omits essential context: what 'period_days' defaults to, what 'limit' limits, what the report output looks like, and any prerequisites. The phrase 'two most recent periods' is ambiguous without defining period boundaries. Completeness is inadequate for an agent to correctly rely on this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines two parameters (limit, period_days) with no descriptions, and the tool description does not mention either parameter. With 0% schema description coverage, the description should compensate by explaining what these parameters do, but it fails to do so. The agent is left guessing the meaning and effect of limit and period_days.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: comparing topic distribution between two recent periods to identify growth, shrinkage, appearance, and disappearance of themes. It uses a specific verb ('Compare') and resource ('topic distribution'), which distinguishes it from sibling tools like similarity_report or association_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: use this when you need to analyze how topics have drifted between periods. However, it does not explicitly state when to prefer this over alternatives or mention any exclusions. The description provides no guidance on when not to use it or how it fits with other reports.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It reveals the tool checks for unit mixes, division by zero, and fact consistency, but does not disclose whether it is read-only, returns a report, mutates memory, or has side effects. It mentions memory usage but not the nature of access.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and front-loaded with the action, but includes parenthetical academic citations (Dehaene 1997; Johnson-Laird 1983) that do not help an AI agent select or invoke the tool. These extraneous details reduce conciseness without adding operational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a moderately specific purpose and two parameters, but no output schema or annotations. The description covers the tool's purpose and some checks but omits what the tool returns, how context_memory_ids is used, and edge-case behaviors. This is insufficient for an agent to predict tool behavior fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies 'problem' as a Chinese math/physics problem, but does not explain 'context_memory_ids' at all. The array parameter's purpose and relationship to the tool's memory-checking behavior remain undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a sanity-check on numbers and units in Chinese math/physics problems, listing specific checks (unit mixes, division by zero, consistency with known facts). This specific verb+resource scope distinguishes it from sibling tools like 'check' or 'reason'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('Sanity-check numbers and units in a Chinese math or physics problem') but does not explicitly state when to use it versus alternatives, nor does it provide exclusions or prerequisites. It gives a clear scenario but lacks explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a key behavioral effect ('apply testing-effect reinforcement') and output behavior ('return the correct content as feedback'), but it does not explain side effects such as memory modification, competition suppression (despite a suppress_competitors parameter), or any limitations. This is moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action ('Score'), and each clause contributes distinct information: scoring, reinforcement, and feedback. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, 2 required, no output schema, and no annotations, this one-sentence description is under-specified. It does not clarify the meaning of optional parameters, the output format beyond 'correct content', or when to choose this tool over similar practice/retrieval tools. An agent would struggle to invoke it correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undefined parameters. It only loosely implies 'attempt' as the retrieval attempt, but does not explain memory_id, generation_bonus, or suppress_competitors. The description adds almost no meaning to the schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Score' with a clear resource 'retrieval attempt', and adds two additional actions ('apply testing-effect reinforcement' and 'return the correct content as feedback'). This distinguishes it from siblings like practice_report or recall, which focus on planning or simple retrieval, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but gives no explicit guidance on when to use it or how it differs from alternatives. There is no mention of contexts, prerequisites, or exclusions, leaving the agent to infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits, but it only mentions that it 'runs' the sleep cycle and lists return values. It does not clarify whether the tool mutates memory, has prerequisites, or any side effects, leaving the agent uncertain about the operation's safety and impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that clearly states the action and expected outputs without any unnecessary words. It is well-structured and front-loaded with the primary verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists the main outputs but omits crucial context: the meaning of the 'days' parameter, any side effects of running the sleep cycle, and usage guidance relative to sibling tools. Given the combined nature of the operation, this lack of detail is inadequate for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'days' with no description, and the tool description does not explain what it does. Schema coverage is 0%, and the description provides no semantic context for the parameter, leaving it completely ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs the full sleep cycle and returns specific outputs (consolidation summary, weak-important replay count, refreshed practice plan/forecast). This distinguishes it from single-purpose siblings like 'sleep' or 'practice_plan' by combining both actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for running sleep and getting a refreshed plan/forecast, but it does not explicitly state when to choose this over alternative tools or when not to use it. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects. It implies mutation ('strengthen') but does not specify whether records are irreversibly modified, whether permissions are required, or what happens to existing data. It also fails to define 'surprising outcome records' or the format of the '历史成功率' summary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It fronts the tool name and efficiently packs both actions into a compact structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, output schema, or parameters, the description is the only source of information. It conveys the core function but omits critical context such as when to invoke it, how it integrates with sleep cycles, and what the output summary contains, which is insufficient given the large set of sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so no parameter explanation is needed. The baseline score of 4 applies, and the description does not attempt to describe nonexistent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies specific actions ('strengthen surprising outcome records' and 'consolidate each step's experience') with clear resources and an output ('历史成功率' summary). It partially distinguishes from siblings like 'sleep' and 'sleep_and_plan' by mentioning replay and consolidation, though it does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'sleep' or 'sleep_and_plan'. The description only states what the tool does, leaving the agent to infer the appropriate invocation context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the basic effect (memories become retrievable again) but nothing more. With no annotations provided, the description carries the full burden for behavioral transparency, yet it omits any details about reversibility, side effects, required permissions, or return 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every word contributes to the core purpose, making it exceptionally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, the description conveys the core operation but omits any context about expected inputs, outputs, errors, or state changes. The lack of annotations and output schema means the description alone is too sparse for an agent to confidently invoke the tool in varied scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'memory_ids' is not explicitly described in the description, but the phrase 'suppressed memories' implies that the IDs refer to those memories. This adds some meaning beyond the bare schema (array of strings), but it lacks explicit detail about format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Restore') and the target resource ('suppressed memories'), with the goal 'to retrieval'. This distinguishes it from sibling tools like suppress_memories and restore, since it specifically addresses the reverse operation on suppressed memories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any conditions, prerequisites, or exclusions, leaving the agent to infer usage purely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the disclosure burden. It does not state whether the tool is read-only, whether it modifies state, or any side-effect implications. The word 'review' implies analysis, but explicit safety traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the primary action and lists outputs, making it efficient. The parenthetical citation adds academic context but is not actionable; overall, the sentence remains concise and focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has nested object parameters and no output schema, so the description must compensate with structural and output details. It does not explain how to construct the plan array or results object, nor what the response structure will be, making it insufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain the structure and expected format of the 'plan' and 'results' parameters. It only repeats the parameter names without adding any detail about how they should be structured, leaving the agent without guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Review') and resource ('a finished plan against its results'), and explicitly lists output components (success rate, score, verdict, patterns, distilled lessons). This clearly distinguishes it from sibling tools like 'plan' or 'plan_quality' that focus on planning or quality assessment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the context for use: reviewing a finished plan against its results, with a theoretical framing (post-task metacognitive monitoring). It does not explicitly name exclusions or alternative tools, but the context is sufficient for an agent to infer when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It does not state whether the operation is read-only or mutates the plan, nor does it mention any safety, side effects, or prerequisites. It only lists what is computed, not the behavioral traits of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with a clear verb and object. However, the parenthetical citations to Miller & Cohen 2001 and 'critical-path method' are unlikely to help an AI agent and add minor noise, keeping it from a perfect conciseness score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain return values. It names graph components but does not describe their representation (map, list, nested structure), nor does it address edge cases or input prerequisites. This is incomplete for a tool with a single unstructured parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'plan' with 0% description coverage. The description does not explain the expected structure of the plan array (e.g., how strings/objects represent tasks or dependencies), so it fails to compensate for the schema's vagueness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Build a plan's dependency graph and critical path') on a specific resource, and enumerates the outputs (levels, predecessors, parallel groups, gating chain). This distinguishes it from sibling planning tools such as plan_tracker or plan_quality, which focus on other aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit 'use when' or 'instead of' guidance. The academic references ('hierarchical planning... critical-path method') imply a scenario, but the agent is not told when to select this tool over other planning-related siblings. The usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action without explaining what 'completed' entails, whether the operation is reversible, or any side effects on related memory or planning systems. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically complete sentence with no redundant words. It is appropriately sized for such a simple tool and is easily parsed at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one required parameter, no output schema), the description is minimally viable but lacks context about return values, success/failure indicators, or potential interactions with other intent-related tools. It is not severely underspecified but not rich enough to fully guide an agent in a complex workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter, intent_id, with 0% description coverage. The description does not mention the parameter or provide any additional meaning beyond the parameter's name, which is self-explanatory but under-supported for an agent needing to construct a valid request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mark an intention as completed' uses a specific verb ('mark') and resource ('intention') with a clear outcome, effectively distinguishing it from sibling tools like intent_cancel or intent_due. Despite its brevity, it unambiguously communicates what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as intent_cancel or intent_due. There are no prerequisites, context, or exclusions mentioned, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It explains the detection criteria but does not mention whether the tool is read-only, what it returns, or any side effects. This is a significant gap for a tool that might be expected to produce a report or mutate state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the purpose and gives concrete criteria. Every word earns its place, with no redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, but without an output schema or annotations, the description should explain what the tool returns and how it fits with sibling conflict tools. It lacks details on return format, usage context, and relationship to 'list_conflicts' and 'resolve_conflicts', making it incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for 'time_window_minutes' (0% coverage). The description implies this parameter controls the 'short window' threshold, adding some meaning beyond the bare schema. However, it does not explicitly state that the parameter defines the window, leaving room for ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Detect' and names the resource 'intention clashes', then defines the exact conditions (two active intentions due within a short window, or sharing the same context cue). This clearly distinguishes it from sibling tools like 'list_conflicts' (which lists existing conflicts) and 'conflict_advice' (which provides advice).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool over siblings such as 'list_conflicts' or 'resolve_conflicts'. The description defines what it does but does not state use cases, prerequisites, or exclusions, leaving the agent to infer when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It explains the scoring criteria but does not mention what the tool returns (e.g., a score, report, or errors), whether it has side effects, or any constraints like requiring a non-empty plan. It also does not describe the role of project memories beyond a vague reference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose before listing criteria. It is concise and packed with information, though the parenthetical citations add length without direct practical value. Overall, it is well-structured and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and sparse parameter documentation, the description is insufficient for an agent to fully understand the tool's behavior and expectations. It lacks information about return values, input format nuances, and the relationship between context_memory_ids and the scoring process, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It hints at 'plan' containing steps and 'project memories' relating to context_memory_ids, but it does not explicitly explain the format or purpose of either parameter. The criteria list gives some semantic context, but it fails to fully clarify what inputs are expected and how they are used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Score') and resource ('a Chinese agent plan's quality'), listing concrete evaluation criteria (step count, explicit verbs, dependency ordering, duplicates, alignment with project memories). This distinguishes it from sibling tools like plan, plan_rewrite, and plan_tracker, which focus on creation or tracking rather than scoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs to evaluate a plan's quality, but it does not explicitly state when to use this tool versus alternatives. There is no mention of exclusions, prerequisites, or comparison with other scoring tools, leaving the agent to infer the context from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the primary source for behavioral disclosure. It implies a read-only operation through 'Return' and discloses the output composition, which is helpful. However, it does not explicitly state whether it mutates state, how 'next' is determined, or whether the optional limit parameter alters the result, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the primary action and result. Every word contributes to understanding the tool's output, with no redundancy or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter, no output schema), the description effectively covers what the tool returns, which substitutes for an output schema. However, the missing explanation of the 'limit' parameter creates a clear gap, preventing the description from being fully complete for all usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'limit' with no description, and the description does not mention it at all. Schema description coverage is 0%, so the description was expected to compensate but fails to explain the meaning or effect of 'limit', leaving the parameter wholly undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return' and the specific resource 'the next practice session as a review plan', and enumerates the exact fields included (scheduled next review time, current retrievability, historical success rate). This distinguishes it from related siblings like practice_report, practice_forecast, or practice_session, which have different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as practice_forecast or practice_report. It does not state any exclusions or preferred contexts, so the agent is left without explicit selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It adds some behavioral context by mentioning 'schema activation, Bartlett 1932' and the output sections, but it does not disclose side effects, permission needs, or behavior when no related memories exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the primary purpose and lists key output sections. The cryptic 'schema activation, Bartlett 1932' may not earn its place, but overall it is concise without significant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain return values and parameter usage. It states the tool assembles a brief and lists sections, but it does not describe the brief's format, how parameters are used, or edge cases like missing memories, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the three parameters (limit, title, memory_ids). It vaguely references 'related memories' but never clarifies how memory_ids or limit affect execution, or that title is the project title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Assemble') and a distinct resource ('a project brief from related memories and intentions') with a clear output structure (background, requirements, risks, pending actions). This differentiates it from sibling tools like 'project_risk' or 'plan_tracker' by the comprehensive brief output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—when a project brief is needed from related memories and intentions—but provides no explicit exclusions or alternatives. There is no guidance on choosing this over similar tools like 'life_story' or 'session_summary'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses output components (gist elements) but does not state whether the operation is read-only, has side effects, or requires privileges. The theoretical citation adds context but not behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the purpose. The parenthetical citation is compact and does not detract.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-param tool, the description covers intent and output contents but lacks usage guidance, side-effect disclosure, and parameter details. Overall it is minimally viable but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines memory_ids as an array of strings, with 0% coverage. The description indirectly refers to a 'cluster of related memories' but never explicitly maps the parameter to the cluster. It does not clarify what constitutes a cluster or constraints on IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Summarize') and resource ('a cluster of related memories'), and distinguishes itself from siblings by focusing on gist extraction (shared cues, frequent terms, evidence, previews). This is distinct from recall/search tools that retrieve raw memories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The term 'cluster' implies it is for grouped memories, but no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It does disclose output characteristics: chronological order, grouping by day, and optional windowing. However, it does not explicitly state read-only/safety implications, date format expectations, or how the limit parameter affects results, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. Every word earns its place by conveying the core output and a key optional behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description leaves important context uncovered: how limit behaves, what date formats are expected, whether the result is a flat list or nested by day, and when to choose this tool over similar memory-report siblings. It provides a high-level overview but not enough for fully reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly maps start and end to a 'start/end window', adding meaning beyond the bare schema. However, the limit parameter is not mentioned, and schema description coverage is 0%, so the description only partially compensates for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as producing an autobiographical timeline of episodic memories in chronological order grouped by day, with an optional start/end window. It lacks an explicit verb like 'reports' or 'generates', but the noun-phrase style still conveys the purpose and distinguishes it from sibling tools by the chronological/day-grouping emphasis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as recall, search, or life_story. The only usage hint is the optional start/end window for date filtering, but there are no explicit when-to-use scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior. It only states that cancellation does not complete the intention, but omits crucial details such as whether the operation is destructive, reversible, or how it affects related data. This is insufficient for a mutation-like action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It efficiently conveys the core purpose without extraneous details, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description lacks critical context about side effects, reversibility, and the meaning of the parameter. Given no annotations and no output schema, the description fails to provide a complete picture for an agent to safely invoke the tool, especially for a cancel operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter (intent_id) with zero description coverage. The description does not elaborate on what intent_id refers to, relying solely on the parameter name. Since the parameter is self-explanatory but not explicitly linked to the description, the compensation is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Cancel an intention without completing it' clearly states the action (cancel) and the resource (intention). It distinguishes itself from sibling tools like intent_complete by explicitly noting it does not complete the intention, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs to cancel an intention, but provides no explicit guidance on when to use this tool versus alternatives like intent_complete or intent_due. There is no mention of exclusions or alternative conditions, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the transformation process but does not state whether the tool returns a new plan, modifies the input in place, persists changes, or has any side effects. This leaves significant ambiguity about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the main purpose and transformation details. The academic reference (Miller & Cohen 2001) adds context but could be considered extraneous. Overall, it is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter and no output schema or annotations, so the description must explain both input and output semantics. It describes the input transformation but does not state the return format, whether the original plan is mutated, or how non-Chinese plans are handled. This incompleteness is significant for a rewrite tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the 'plan' parameter by describing it as a weak Chinese plan with steps, duplicates, and a need for action-verb normalization. However, it does not address the object variant allowed by the schema, leaving the structure of object items unclear. The enrichment is partial, so a medium score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Rewrite a weak Chinese plan into an executable one') and specifies the transformation steps (normalize to action verbs, remove duplicates, order along the standard build flow). This distinguishes it from sibling tools like 'plan' or 'replan' by targeting weak Chinese plans specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when a plan is weak and in Chinese) but does not explicitly state when not to use it or compare it with alternatives such as 'replan' or 'plan_quality'. The usage context is clear but lacks explicit exclusions or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose key behavior: results are grouped per query and preserve input order, and it is a single MCP round trip. Missing are limits, failure handling, or whether results are fully ordered, but for a batch read tool this is moderate detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, front-loading the action and then explaining benefit and outcome. Every clause adds value: what it does, how results are returned, and why you would use it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple batch read tool, the description covers the main behavior and purpose, but lacks parameter guidance, usage constraints, and output details (no output schema). It is adequate but not fully complete for a tool with three parameters and no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain the parameters beyond implying 'queries' are recall queries. It does not clarify the 'kind' enum or 'top_k' semantics, so the description adds minimal value over the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs multiple recall queries in one call and returns results per query, making the batch behavior explicit. It differentiates from single-query tools like search/recall by emphasizing 'several' and 'single MCP round trip', though it does not name specific siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a list of questions needing recall, citing efficiency via a single round trip. However, it does not explicitly state when not to use it or mention alternatives like search or recall.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It transparently reveals the detection method (content-token overlap) and the intended results, but it does not explicitly state whether the operation is read-only, how results are paginated, or any behavioral side effects, relying on the 'report' name for implied safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and concise, adding no redundant information. It efficiently states the purpose, method, and intended outcomes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a report tool with no output schema and no annotations, the description is insufficiently complete. It does not explain the meaning of 'limit' and 'threshold', nor what the returned report contains, leaving important information for correct invocation undisclosed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the two parameters (limit, threshold), and the description does not mention either parameter. The agent receives no semantic meaning beyond the parameter names and types, so the description completely fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Find confusable memory pairs') and defines the method ('content-token overlap') and outcome categories (near-duplicates or pairs needing separation), clearly distinguishing it from sibling tools like dedupe_memories or conflict_advice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for detecting similar pairs, but does not explicitly state when to use this tool over alternatives or provide any exclusions. It lacks a direct comparison to related reports or dedupe tools, leaving usage somewhat implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It explains the spacing principle (distributed practice, Cepeda 2006) which gives insight into how the schedule is constructed, but it does not mention side effects, whether it stores data, return values, or parameter effects. Some behavioral context is provided, but operational details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, immediately states the purpose, includes a citation for credibility. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and undocumented parameters, the description leaves significant gaps. It explains the high-level algorithm but not how to invoke the tool correctly (parameter semantics, return types, side effects). The agent would likely need to guess or inspect other resources.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (days, limit) have no schema descriptions, and the description does not mention them at all. The 0% schema description coverage means the description is responsible for explaining parameter meaning, but it fails to do so. An agent would not know what 'days' or 'limit' refer to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Build a spaced review schedule' with specific details about the scheduling logic (fading memories early, strong ones later, interleaving). This distinguishes it from sibling planning tools like practice_plan or review_due by specifying the spaced review algorithm.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs a spaced review schedule, but it does not explicitly state when to use this tool versus alternatives or when not to use it. No alternative tools are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the ordering logic (overdue first, then upcoming by deadline) and that clashing intentions are flagged, which adds useful context. However, it does not state whether this is a read-only operation, what 'flagged' means in the output, or any side effects, so transparency is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core functionality. The parenthetical reference to 'goal-directed priority, ACT-R; Anderson 1983' adds theoretical context but could be seen as extra; however, it does not undermine conciseness. Overall, minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one undetermined parameter, no output schema, and no annotations, the description is incomplete. It does not explain the return format, the meaning of 'flagged', how 'limit' affects the queue, or how this tool relates to the many sibling planning and intent tools. A more comprehensive description is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single 'limit' parameter with no description, and schema coverage is 0%. The description does not mention 'limit' at all, leaving its meaning completely unexplained. The description fails to compensate for the missing schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: it orders active intentions into an action queue with a specific priority scheme (overdue first, then upcoming by deadline) and flags clashing intentions. This is a specific verb ('order') + resource ('active intentions') + scoping (queue ordering) that distinguishes it from other intent-related tools like intent_due or intent_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: whenever you need an ordered action queue from active intentions. However, it does not explicitly mention alternatives or exclusion conditions, so it falls short of a 5 but is more than just implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether the tool is read-only, whether it modifies memories, what happens on invalid IDs, or how the verdict is computed. It only describes the output, not the behavior or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the key action ('Compare two memories'), and includes necessary details about outputs and purpose. The reference to Johnson et al. (1993) is extra but does not detract from clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no annotations and no output schema, the description covers the core function and outputs. However, it omits behavioral details like read-only nature, error handling, or how to interpret the verdict, leaving some gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only parameter names (id_a, id_b) with no descriptions. The description's phrase 'two memories' clarifies that these are memory identifiers. While it doesn't specify the exact format or whether the order matters, it adds enough meaning for a two-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares two memories and specifies the outputs: token overlap, shared cues, and a verdict (duplicate/conflict/distinct). It is specific and understandable, though it does not explicitly differentiate from sibling tools like similarity_report or dedupe_memories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a purpose ('source monitoring and schema integration') which implies when it might be useful, but it lacks explicit guidance on when to use this tool versus alternatives or any exclusions. It does not name alternatives or describe specific use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses some behaviors: deduplication, score ranking, and character budget (with cognitive load reference). This adds context beyond a generic 'pack' statement. However, it doesn't state whether the operation is read-only, whether it affects memory state, what happens with insufficient matches, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no filler. It front-loads the action and packs meaningful details without redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a short description, the tool has 3 parameters with no coverage, no output schema, and no annotations. The description provides the core idea but omits parameter details, return value structure, and edge cases. Given the complexity and lack of structured metadata, it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It indirectly maps 'several queries' to the 'queries' parameter, 'character-budgeted' to 'max_chars', and 'score-ranked' to 'top_k', but it does not explicitly explain the parameters or their constraints (e.g., required queries, ranges, defaults). This is insufficient for a 3-parameter tool with no schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Pack' with the resource 'memories' and clarifies scope: 'for several queries' and 'into one bounded context'. It lists key behaviors (deduplicated, score-ranked, character-budgeted) which differentiate it from single-query recall/search tools. However, it does not explicitly name sibling alternatives or state when not to use it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage context: for packing memories relevant to multiple queries within a bounded context. It mentions 'character-budgeted' which signals when context limits matter. However, it does not explicitly contrast with sibling tools like search_batch or working_set, nor state 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose whether the tool is read-only, modifies memory, or requires a minimum history length. The phrase 'Personalize each memory's forgetting forecast' could be interpreted as a write operation, making behavior ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs in purpose, method, and model citation without wasted words. It is slightly dense but remains readable and front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain return values and prerequisites. It does not state what the tool returns (only predicts days, not the format), nor does it address edge cases like insufficient history. The description is too brief for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It gives context for 'threshold' ('crosses a threshold') but does not explain 'memory_id' (obvious but unstated) or 'horizon_days' (no mention at all). The compensation is partial at best.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: personalizing a memory's forgetting forecast from retrieval history and predicting days until a threshold is crossed. It distinguishes itself from siblings by emphasizing 'individual forgetting rates' and citing Murre & Chessa (2011), which implies a unique model compared to other forecast 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use when you have retrieval history for a memory and want an individualized forgetting curve prediction. However, it does not explicitly mention alternatives or when not to use, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden. It implicitly indicates non-permanence by referencing a recycle bin, but does not disclose whether the action is reversible via restore, effects on associated data, or any required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is minimally adequate. However, without annotations, it lacks details on side effects, reversibility, and error conditions, leaving gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the memory_id parameter, its format, or how to obtain it. The description fails to compensate for the lack of schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool moves a memory to the recycle bin, using a specific verb and resource. This distinguishes it from siblings like restore (reverse operation) and update (modification).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like restore, suppress, or update. There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It mentions terms like 'reactivate overdue intentions' and 'score replay readiness' but does not disclose side effects, whether the operation mutates memory, requires auth, or has rate limits. The behavioral impact of 'reactivate' is ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a clear front-loaded verb and purpose. It is relatively compact, though the academic citations add unnecessary length without functional value for tool invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is insufficiently complete for correct invocation. It leaves top_k, return format, and side effects unexplained, so an agent would lack critical details to use the tool safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not add meaning for the two parameters. While 'goal' is hinted by 'goal-related memories,' the 'top_k' parameter is entirely unexplained, leaving the agent to guess its purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool: 'Replay goal-related memories to plan the next move' with specific actions like 'recall evidence, extract past lessons, reactivate overdue intentions and score replay readiness.' This distinguishes it from siblings such as remember, recall, or plan by focusing on goal-related memory replay.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this tool to plan the next move via goal-related memory replay. It implies a planning scenario but provides no explicit exclusions or alternatives among the many sibling tools, so it doesn't fully meet the 'when-to-use vs alternatives' ideal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states the registration action but does not mention side effects, idempotency, return values, or any prerequisites, which is a notable gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that efficiently conveys the core purpose and key parameters without wasted words. It is appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, this description is minimal. It does not cover due_at format, importance semantics, or the relationship to sibling intent tools, making it insufficient for an agent to fully understand tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description names three of four parameters (content, deadline, context cue) but omits 'importance'. With 0% schema coverage, it adds some value but fails to explain due_at format or the meaning of importance, leaving the schema to carry incomplete information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Register a future intention (prospective memory)' with a specific verb and resource. It distinguishes from siblings like 'remember' and 'remember_turn' by explicitly focusing on prospective memory and future intentions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for future intentions but does not explicitly contrast with alternatives. No exclusions or when-not-to-use scenarios are mentioned, leaving the agent to infer context from the phrase 'prospective memory'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. The verb 'Retrieve' implies a read operation, but the description does not explicitly state that it is non-destructive, nor does it mention any side effects, prerequisites, or return format. This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action. The parenthetical theoretical citation adds conceptual context but could be seen as slightly extraneous; overall it remains concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, no parameter descriptions, and only a minimal description. The agent does not know the return structure, how top_k affects results, or how to handle edge cases like empty plans or missing memories. This is too sparse for robust invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero descriptions for its parameters (plan and top_k), so the description must compensate. It clarifies that 'plan' is a set of steps and that memories are retrieved for each step, but it does not explain the structure of plan items or the meaning/effect of top_k. This is only partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Retrieve') and resource ('supporting memories for each plan step'), and it distinguishes itself from sibling memory tools by linking to plan steps. The purpose is unambiguous and specialized.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys a clear usage context: retrieving memories to give the agent context during plan execution. It references working memory theory but does not explicitly name alternatives or exclusions, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only describes the output (plan and scored report) but does not state whether the session records results, requires an existing plan, mutates state, or has side effects. This lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary action ('Run one complete practice session') and then efficiently summarizes the return value. There is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately explains the output format (plan plus scored report with difficulty and next-review suggestions), which is important given no output schema. However, it omits parameter semantics for 'limit', behavioral side effects, and any prerequisites, leaving the tool not fully specified for an agent to use correctly without further inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It gives context for 'answers' (the responses to be scored) but leaves 'limit' completely unexplained, and it does not clarify the structure of answer items (id/attempt) beyond what the schema already shows. The description adds only minimal value over the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run one complete practice session' and explains that it returns both the coming session plan and the scored report. This specific verb+resource combination distinguishes it from sibling tools like practice_plan and practice_report, which handle these components separately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you want a full practice session combining plan and report, but it gives no explicit guidance on when to choose this over practice_plan or practice_report for individual needs. There are no exclusions or alternative scenarios mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the main workflow (recall, extract, build, optional store) and mentions the potential mutation of storing an inference memory. However, it does not specify side effects of storing (e.g., whether memories are modified, duplicate handling, reversibility) or any prerequisites. This is a moderate level of disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the main purpose and then provides supporting details, including scholarly citations. It is efficient with no redundant phrasing, though the citations add length without utility for tool invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four parameters, no annotations, and no output schema, the description is insufficiently complete. It gives a high-level workflow and domain context (math reasoning) but omits parameter semantics, return format, and potential side effects. An agent would need to rely on inference or external knowledge to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It loosely maps 'store conclusion' to store_conclusion and 'recall evidence' to problem/topic, but does not explain top_k at all, nor the exact format/role of each parameter. The description adds some high-level meaning but leaves significant ambiguity for the agent to safely invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's action (build a replay-friendly reasoning trace), source (stored memories), and key sub-steps (recall evidence, extract quantities, build per-step trace, optionally store conclusion). It distinguishes itself from siblings like recall (simple retrieval) and reason (general reasoning) by specifying its trace-building and optional inference-memory storage behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for math reasoning circuits with stored memories, but does not explicitly state when to use this tool over alternatives like 'recall_trace' or 'numeric_reasoning'. No exclusions or alternative recommendations are provided, so the agent gets a sense of context but not clear selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It indicates the mutable nature (add/remove), but fails to disclose the default behavior of the optional action parameter, idempotency, permissions, or consequences for existing tags. Minimal behavioral context beyond the operation itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It is front-loaded with the verb and object, and includes a meaningful note about tags being retrieval cues. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is adequate but leaves gaps. It doesn't explain the action parameter's default or possible values, nor does it describe return values or effects. However, the core purpose is clear enough for simple tagging use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description should compensate. It explains 'tags' and 'memories' conceptually, but does not describe the individual parameters, especially the 'action' parameter with its add/remove enum. The agent must infer parameter purpose from the description alone, which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: adding or removing tags on memories in bulk. It also explains that tags are retrieval cues, which distinguishes it from memory retrieval tools like 'search' or 'recall'. The phrase 'in bulk' signals batch operation, adding further specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for managing tags as retrieval cues, but does not provide explicit when-to-use guidance or mention alternatives like 'remember' or 'search'. No exclusions or comparisons with sibling tools are given, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It adds useful behavioral context: the estimation includes critical-path hours and applies a 20% buffer, rooted in the planning fallacy. However, it does not disclose side effects, permissions, or how base_hours interacts with the calculation, leaving some behaviors opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core purpose and two concrete details (critical-path and buffer) without extraneous words. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the core purpose is clear, the description fails to describe the return format (no output schema) and leaves the base_hours parameter undocumented. With no annotations, these omissions make the tool incomplete for an agent to invoke with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that 'plan' is used to estimate per-step and total effort, but it completely omits 'base_hours'—its purpose and relationship to the estimate are unexplained. This is a significant gap given zero schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Estimate' and clearly identifies the resource ('a plan') while specifying granular outputs: per-step effort, total effort, critical-path hours, and a 20% buffer. This distinguishes it from sibling planning tools like plan_quality or plan_rewrite, which focus on different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: use when you need effort estimates for a plan. However, there is no explicit guidance on when not to use it or how it compares to alternative planning tools (e.g., plan_tracker, project_brief). No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It does disclose the output scope by listing state components, which is useful. However, it does not explicitly state whether the operation is read-only, what happens if the memory_id is invalid, or any side effects. The word 'explain' implies non-mutating behavior, but this is not stated confidently.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that lists the full state attributes efficiently. It is front-loaded with the verb 'Explain' and avoids any redundancy or filler. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is reasonably complete. It enumerates the return fields, satisfying the need to explain output when no output schema exists. It does not elaborate on each field's interpretation, but that is not essential for a tool of this scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not describe the 'memory_id' parameter beyond implying it identifies a memory. The parameter name is somewhat self-explanatory, but no format, source, or required context is provided. The single 'one memory' phrase adds minimal meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Explain') and the resource ('one memory's full state'), enumerating all aspects covered (content, cues, retrievability, importance, strength, confidence, evidence, links, suppression, access, review state). This specific list differentiates it from sibling tools like 'recall' (which likely returns only content) and 'stats' (aggregate).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. It only defines the tool's function, leaving the agent to infer usage context from the 'explain' action. No sibling alternative is referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'List' implies a read-only operation, but the description does not explicitly state that it has no side effects, how results are ordered, or what fields are returned. It adds minimal behavioral context beyond the core purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a front-loaded verb and no redundant words. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description adequately states what it returns and under what condition. It could be enriched by mentioning limit semantics or ordering, but these are not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter ('limit') with 0% schema description coverage, and the tool description does not mention it. The parameter name is somewhat self-explanatory, but the description fails to compensate for the missing schema documentation with default values, range, or behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') plus a resource ('active intentions') and a clear condition ('deadline has arrived'). This distinguishes it from sibling tools like intent_complete, intent_cancel, and intent_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There are no exclusions, prerequisites, or references to related tools such as intent_report or review_due; the usage context is only implied by the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose the main behavior (reporting clusters and providing a suggestion), but it omits details about parameter effects, sorting, limits, or whether it is strictly read-only. This makes it moderately transparent but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core action ('Report cue-crowded clusters') and adds the relevant suggestion detail without excessive wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and two undocumented parameters. The description explains the core concept but lacks essential information about parameters and expected results, making it insufficient for an agent to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%—the description does not explain the 'limit' or 'shared_cue_min' parameters. The schema only provides their types, and the description fails to add any meaning, leaving the agent unable to determine how to set these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Report' and clearly identifies the resource as 'cue-crowded clusters' caused by interference, which differentiates it from sibling reports like similarity_report or association_report. The added details about the suggestion and the Wickens 1972 citation further clarify its unique focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context about when this tool is relevant—when cue crowding causes interference—but does not explicitly name alternatives or state when not to use it. This aligns with 'clear context, no exclusions'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It fails to state whether this is a read-only operation or if it has any side effects. While 'audit' implies non-mutating, the description does not explicitly confirm that, nor does it mention any auth requirements, performance implications, or what 'deep' entails in terms of behavior. The enumeration of metrics adds content but not transparency about operational effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the key action ('Deep lifecycle audit') and then efficiently lists the specific audit dimensions. Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description carries the burden of explaining what to expect. It lists many metrics but does not specify the return format (e.g., summary counts vs. detailed breakdown), whether it covers all memories or only a subset, or if there are any time-window restrictions. It is adequate for a high-level audit tool but leaves operational details unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so per the baseline rule for no parameters, this scores a 4. The description doesn't need to add parameter meaning since there are none; it simply states what the audit reports.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a 'Deep lifecycle audit' and enumerates specific components it covers (active/recycled counts, revised and emotional traces, conflicts, due now, average retrievability and importance). This is a specific verb+resource that distinguishes it from siblings like 'stats' or 'memory_status' by focusing on the full lifecycle with a comprehensive list of audit dimensions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention when this deep audit is preferable to simpler tools like stats or memory_health, nor does it state any exclusions or prerequisites. The description is purely descriptive of the output, not prescriptive of usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains the spreading-activation traversal and cites Collins & Loftus (1975), adding useful conceptual detail, but it does not state whether the operation is read-only, what the output shape is, or how depth/limit constrain traversal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that efficiently conveys the core operation and adds a useful theoretical reference without any fluff. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must compensate. It omits return format, parameter semantics, and usage boundaries, leaving an agent uncertain how to correctly set depth/limit or interpret the result. The conceptual explanation alone is insufficient for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only indirectly references start_id ('start memory') and hop depth ('1 hop, 2 hops etc.'), but it does not explain the depth parameter as a maximum hop count, nor does it clarify the limit parameter. Two of three parameters remain semantically opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Walk' and states the resource ('association network') and the action ('hop by hop from a start memory'), explicitly distinguishing multi-hop exploration from sibling search/recall/report tools. It clearly communicates what the tool does and its distinctive multi-hop scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a usage context (tracing associations at increasing distances) but does not explicitly state when to choose this tool over alternatives like association_report or memory_map. No exclusions or alternative tool mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the analogical reuse behavior and the ordered-step output, but it does not state whether the plan is persisted, how missing history is handled, or what the return structure looks like. The effort parameter's depth/rerank behavior is only in the schema, not the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that introduces the tool's purpose immediately and wastes no words. Every phrase ('ordered step plan', 'analogical template') adds meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must cover more ground. It leaves top_k semantics, effort/depth behavior, return format, and choice-vs-alternatives unspecified, making it incomplete for an agent to use confidently among many sibling planning tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description must compensate. It clarifies the goal parameter by saying it is turned into a plan, but top_k is completely unexplained, and the 'referenced person's steps' mention does not map to any visible parameter in the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'turn a goal into an ordered step plan' and adds a distinctive mechanism ('reusing the person's own past steps or a referenced person's steps as an analogical template'). This clearly differentiates it from sibling tools like replan, plan_quality, or analogy_bridge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The wording implies use when a goal needs to be converted into a step plan, and the analogical-template hint suggests reuse of history. However, it provides no explicit when-to-use/when-not-to-use guidance or alternatives, especially given the many planning-related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a key behavior: listing cues only without answers. The verb 'list' implies a read-only operation, but it does not explicitly state side effects, logging, or any impact on memory scheduling, which is important with 9 optional parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently conveys the core action, mode, and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters and no output schema, yet the description only covers the basic idea. It leaves parameter meanings and return format entirely unspecified, making it inadequate for an agent to reliably invoke or configure the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for 9 parameters, and the description provides no semantics for any of them. It does not explain what 'kind', 'limit', 'vary_cues', 'interleave', 'adaptive_gap', or other parameters do. The description must compensate for this gap but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('list') and resource ('due memories'), and adds mode ('cues only, no answer') and purpose ('testing-effect self-quizzing'). This clearly differentiates it from sibling tools like practice_answer (which likely shows answers) and practice_report (which reports practice stats).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieval practice and self-quizzing, which provides clear context. However, it does not explicitly name alternatives or state when not to use this tool, missing the highest level of guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose side effects. It does not state whether recording overwrites existing outcomes, is append-only, or whether there are any return values or error conditions. The phrase 'evidence accumulation' hints at non-destructive addition, but this is not explicit enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary filler. The main verb and object are front-loaded, and every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters and no output schema, so the description should provide adequate context. It does not explain what 'evidence accumulation' means in practice, the relationship between goal and step, or what happens after recording (e.g., return value, effects on related plans). The description is too minimal for the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'success/fail' (success) and 'note', and indirectly 'step' via 'agent project step', but it entirely omits 'goal' and does not explain the relationship between goal and step. With a required 'goal' parameter, this is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Record' and identifies the resource as 'an execution outcome (success/fail + note) for an agent project step'. This clearly distinguishes it from siblings like practice_report or lesson_learned, and the parenthetical 'evidence accumulation' adds context about its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need to store the result of executing a project step. It provides clear context but does not explicitly mention alternatives or exclusion criteria, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for side effects and safety. The word 'estimate' implies a read-only calculation, but it does not explicitly confirm non-mutation, permissions, or dependencies. The focus is on output metrics rather than behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with purpose, lists metrics compactly. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one optional parameter and no output schema, the description gives a good overview of returned metrics but leaves 'weak traces' and 'weighted load index' undefined, and does not clarify output format or default for 'days'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description maps the 'days' parameter to 'due within N days', providing practical meaning beyond the bare schema. It does not specify default behavior or effects on other metrics, but for a single optional parameter this is a meaningful addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool estimates review pressure with a specific set of metrics (due now, overdue, due within N days, weak traces, weighted load index). This distinguishes it from sibling tools such as review_due or practice_forecast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. It only states what it does, leaving the agent to infer appropriate usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It hints at side effects by mentioning 'prune' and 'promote', but does not explain consequences, reversibility, or what specifically is affected. This is insufficient for a potentially destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. The parenthetical list efficiently conveys the scope of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and no parameters, the description is minimal but conveys the essential action. However, for a memory consolidation process with potential pruning, it would be more complete if it mentioned side effects or when to use it, especially given the large sibling list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description need not add parameter information, and the parenthetical list does not conflict with the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Run' with a clear resource 'sleep consolidation' and lists the sub-actions (promote, prune, reflect, conflicts), making its purpose distinct from sibling tools like sleep_replay and sleep_and_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus similar siblings such as sleep_replay or sleep_and_plan. The description does not state any exclusions or alternative 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?
With no annotations, the description carries the full burden. It discloses that the tool scores both sides and may ask the user for clarification, implying it is non-destructive, but it does not explicitly state whether it is read-only, what side effects might occur, or what the output looks like. It adds useful context about the decision criteria, but not a complete behavioral picture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the tool's purpose and lists the scoring criteria. Every word contributes, with no redundant or vague content, making it appropriately concise for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core behavior but omits the return format, how the optional 'limit' parameter behaves, and whether the tool has any side effects. Since there is no output schema, the description should have revealed what the agent can expect in the response, but it does not. For a simple advisory tool, this is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional integer parameter 'limit', but the description does not mention it, and schema description coverage is 0%. The parameter's meaning can only be guessed from its name, and the description does not compensate by explaining how limit affects the scoring or recommendation behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's function: for each memory conflict, score both sides using evidence, confidence, recency, and source trust, then recommend which to keep or ask the user to clarify. It uses specific verbs ('score', 'recommend') and a clear resource ('memory conflict'), and it distinguishes itself from sibling tools like resolve_conflicts by focusing on advice rather than execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when there is a memory conflict and you need a recommendation, but it does not explicitly state when to use it over alternatives like resolve_conflicts or list_conflicts. No exclusions or alternative names are mentioned, so 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?
With no annotations provided, the description carries the full burden. It discloses the grouping mechanism and specific output metrics, plus a theoretical reference, giving a clear behavioral model. However, it doesn't mention edge cases or limitations such as handling of very large stores or non-trace content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence with no redundancy. It front-loads the primary verb and resource, then uses a colon to efficiently list output attributes. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema is absent, so the description must explain return values; it does list the key output components. However, the complete absence of parameter semantics leaves a significant gap, making the tool only partially usable without guessing about 'limit' and 'period_days'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description makes no mention of 'limit' or 'period_days'. Although 'time buckets' hints at period_days, there is no explicit connection. Users have no guidance on how these parameters affect the summary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Summarize the store as lifetime periods' and details the method (group episodic traces into time buckets) and output contents (event counts, top themes, average importance, highlights). This distinguishes it from siblings like 'recall' or 'timeline_report'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for summarizing memory traces into a life story, but it does not explicitly state when to use this tool versus alternatives like 'session_summary' or 'timeline_report'. No exclusions or prerequisites are mentioned.
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?
The description indicates a non-destructive read operation via 'Summarize' and describes the output structure. However, with no annotations provided, the description carries the full burden and does not mention potential side effects, rate limits, or whether it operates on a subset of memory. It provides basic transparency but not rich context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of two sentences that front-load the main purpose and then add specific output details. No word is wasted, and the structure is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple summary tool, the description adequately conveys the return value. However, it lacks explanations for the parameters and clear usage guidance relative to other tools, which are notable gaps given the absence of an output schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes two optional integer parameters (limit and topic_min) with 0% schema description coverage, and the description does not mention either parameter. This fails to compensate for the missing schema descriptions, leaving the agent uncertain about their meaning and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Summarize what the memory holds' and specifies the output elements ('topics with counts and average retrievability, plus a weak/ok/strong strength histogram'). It also distinguishes itself by noting it 'Powers the human-readable memory map chart', which differentiates it from other reporting tools like memory_status or stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage in the context of generating a chart ('Powers the human-readable memory map chart'), but it does not explicitly state when to use this tool over alternatives or provide any exclusions. Sibling tools like memory_status and stats exist, but no comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It uses 'Return' and 'snapshot', which imply a read-only operation, and lists the output categories. However, it does not explicitly mention whether there are side effects, costs, or how the snapshot is computed, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose and then enumerates the snapshot components. Every clause adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description does a complete job of explaining the return value by listing all four dimensions. It is sufficient for an agent to know exactly what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to explain. The baseline for 0 params is 4, and the description appropriately focuses on the output rather than input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a memory-health snapshot and lists its key components (active counts, average strength/importance, due memories, conflicts). This is specific and actionable, though it does not explicitly differentiate from the sibling tool 'memory_health' through naming or contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternative siblings like 'memory_health', 'stats', 'review_due', or 'list_conflicts'. The description only explains what it does, not the context 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?
With no annotations provided, the description carries the full burden. It discloses valuable behavioral details: using outcome history, predicting probabilities, flagging weakest step, and offering a fallback. However, it does not state whether the tool has side effects (e.g., read-only vs mutating) or describe the output structure, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action. The academic citation (Schacter & Addis, 2007) adds a small amount of extraneous detail but does not significantly impede understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two undocumented parameters and no output schema, yet the description does not explain how to invoke it or what the return value looks like. While the conceptual purpose is clear, an agent lacks critical operational context to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the meaning of 'goal' or 'top_k'. The description mentions 'each step' and 'outcome history' but does not connect these to the parameters, leaving the agent unable to correctly populate them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Mentally rehearse a plan before executing' and elaborates on specific actions (predict success, flag weakest step, offer fallback). This distinguishes it from sibling tools like plan or predict_step by focusing on pre-execution simulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before executing' provides a clear temporal context for when to use this tool. However, it does not explicitly mention alternatives or situations where this tool should not be used, missing the full guidance level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly states the tool scores and returns a report, implying a read-only operation, but it does not disclose potential side effects, error behavior for invalid IDs, or any external dependencies. It adds some context but leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence. It immediately states the action, inputs, and output without any filler, repeating only what is necessary for clarity. It earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, but there is no output schema and no annotations. The description covers the core operation but omits details about the report structure, validation behavior, and how this fits into the broader practice workflow. It is minimally complete but not deeply informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'answers' with id and attempt strings, and schema coverage is 0%. The description only says 'list of id/attempt', which barely restates the schema. It does not explain the meaning of 'id' (e.g., card identifier) or the expected format/content of 'attempt', which is insufficient given the lack of schema assistance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action ('Score') and clearly identifies the input resource ('a whole practice round (list of id/attempt)') and output ('session report with per-card feedback'). This distinguishes it from sibling tools like practice_answer (single card) and practice_plan (planning), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when scoring a full practice round, but it does not explicitly state when to use it versus alternatives such as practice_answer or practice_plan. There is no mention of when-not-to-use or exclusion conditions, leaving usage guidance only implied.
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?
The description reveals the core behavior (moving a memory out of the recycle bin) but does not disclose edge cases, side effects, or conditions (e.g., what happens if the memory is not in the bin, or if it already exists). With no annotations, the description carries the full burden, and it provides only the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that wastes no words. It is appropriately sized for a tool with one simple action and one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple restore tool with one parameter and no output schema, the description covers the primary function. However, it omits important context such as the prerequisite (memory must be in recycle bin) and potential error cases, leaving the agent to infer behavioral details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines memory_id as a required string with no description, and the tool description does not mention memory_id at all. It adds no meaning beyond the schema, and with 0% schema coverage, the description fails to compensate for the missing parameter explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Restore'), the object ('a memory'), and the origin ('from the recycle bin'). This distinguishes it from siblings like 'forget' or 'remember' and leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is for restoring memories that are currently in the recycle bin. It does not explicitly mention when not to use it or name alternatives, but the context is straightforward and sufficient for the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions merging and returning a count, but omits whether the operation is destructive, reversible, or requires confirmation. It also doesn't explain what 'near-duplicate traces' means or what happens to the merged traces.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It front-loads the primary action and includes the return value, making every word informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params), the description covers the core action and return value. However, with no annotations or output schema, it leaves out important context like side effects or reversibility, making it only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema is an empty object, so the baseline is 4. The description adds no param info, but none is needed since the tool takes no inputs. The description's mention of 'on demand' clarifies invocation context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Merge') and resource ('near-duplicate traces'), and the return value ('returns how many duplicates were merged') adds specificity. This distinguishes it from sibling tools like 'cleanup_preview' or 'memory_audit'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'on demand' implies manual usage, and the description conveys the core function, but it doesn't explicitly mention when to use this tool versus alternatives like 'forget' or 'restore'. No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does specify output details (edge list, deduplicated, undirected) but does not state whether the operation is read-only, requires auth, or has side effects. 'Export' implies non-destructive but it is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states the action, output format, and purpose. It is concise without wasted words, though the citation to Collins & Quillian is slightly academic but acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 0-parameter tool without an output schema, the description adequately covers what the tool does, the output format, and the intended use case. It does not mention limitations or interactions with other tools, but that is not critical for this low-complexity operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is trivially 100%. Per the rubric, a description is not required to explain parameters when none exist, so the baseline of 4 applies. The description does not need to add parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('Export'), the resource ('memory network'), and the output format ('knowledge-graph edge list with nodes and deduplicated undirected edges'). However, it does not explicitly differentiate from sibling tools like export_memories or memory_map, which also may export or map the memory network.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for external visualization' gives a behavioral context and implies when to use it, but there is no explicit guidance on when not to use it or which alternative tools might be more appropriate. Given the large number of sibling tools, the lack of exclusions or alternatives weakens the usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the bounded nature and the fields returned, and implies read-only behavior. However, it does not explain default limits, behavior when empty, or whether limit is enforced as a cap, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. Every element earns its place: the verb, object, key fields, and the bounded audit log qualifier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description provides adequate coverage: it states what is returned (recall entries), the ordering (most recent), and the bounded nature. Minor gap: no mention of default behavior or if the limit parameter is capped, but overall complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'limit' with no description (0% coverage). The description uses the word 'bounded' which hints at the limit parameter's role but does not explicitly state that 'limit' controls the maximum number of entries returned. This indirect reference does not fully compensate for the lack of schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Return' and a specific resource 'recall entries' with enumerated fields (query, top result, confidence, timestamp). It distinguishes itself as an audit log, clearly differentiating from sibling tools like 'recall' which likely performs a recall operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys that this is for retrieving a bounded audit log of recent recall entries, providing some context for when to use it. However, it does not explicitly state when to prefer this over alternatives or mention exclusions, leaving the usage guidance 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the transparency burden. It discloses what the summary includes (semantic facts, events, conflict/duplicate pairs) and implies it produces a summary for later consolidation rather than modifying memories. However, it does not explicitly state whether the operation is safe, read-only, or requires any permissions, which leaves some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently states the verb, resource, and output contents in a compact structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should provide more detail about the return format and parameter semantics. It gives a high-level overview of the summary content but lacks the specifics needed for an agent to confidently invoke the tool and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no direct explanation of memory_ids or compare_limit. The only hint is that 'one work session's memories' implies memory_ids are related to session memories, but compare_limit is completely unexplained, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'summarize' and clearly identifies the resource ('one work session's memories') and enumerates output categories (semantic facts, episodic events, conflict and duplicate pairs). This makes it distinct from generic memory tools and provides a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for post-session consolidation' gives clear context for when to use this tool. However, it does not explicitly state when not to use it or mention alternative tools, so it lacks the explicit exclusions or alternatives that would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that the tool summarizes the network and lists the specific metrics computed, including 'spreading activation', which provides useful context. It does not explicitly note side effects, but 'Summarize' strongly implies a read-only report.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-organized sentence that front-loads the core purpose and enumerates the report's contents. Every word contributes value, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter, no output schema), and the description covers the main functionality and output metrics. However, it omits any explanation of the 'limit' parameter, and the lack of an output schema means the description should have more detail about the exact response structure or how metrics are formatted. This leaves a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter ('limit') with 0% coverage in the description. The description does not explain what the limit applies to (presumably the number of most-connected memories), leaving the agent to infer from the parameter name. With low schema coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies a verb ('Summarize') and a resource ('memory association network'), and enumerates concrete output content (total links, connected/isolated memories, average links, most-connected memories). This distinguishes it from other report tools like similarity_report or interference_report by focusing on the association network.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is appropriate when an overview of the memory association network is needed, but it does not explicitly state when to use it over alternatives or provide exclusions. With many sibling reporting tools, more explicit guidance would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of disclosing behavior. The description does explain what the tool outputs (chunking, memory coverage, top-k) and adds theoretical context (working-memory chunking, Miller 1956). However, it does not explicitly state whether the operation is read-only, whether it has side effects, or how the output is presented. The verb 'Show' implies non-destructive behavior, but this is not made explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and output. The parenthetical reference to Miller (1956) adds relevant theoretical context without being verbose. Every part of the sentence is informative and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter 'show' tool without an output schema, the description provides a good level of context: it explains the core process (chunking, memory coverage, top-k) and the specific domain (Chinese questions). It does not detail the exact output format or any prerequisites, but given the tool's apparent simplicity, it is reasonably complete. The absence of an output schema is mitigated by the clear description of what is shown.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does add meaning: 'query' is described as a multi-concept Chinese question, and 'top_k' relates to the 'final top-k'. However, it does not explain the expected format of the query, the default value for top_k, or how these parameters influence the chunking process. The description provides partial meaning but leaves significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it shows how a multi-concept Chinese question is split into chunks, which memories cover each chunk, and the final top-k. This is a specific verb ('Show') plus a resource ('multi-concept Chinese question') and distinguishes the tool from siblings like 'working_set' and 'memory_map' by focusing on the chunking and memory coverage visualization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for understanding the memory retrieval and chunking process for a multi-concept Chinese question, but it does not explicitly state when to use this tool vs alternatives or provide exclusions. There is no mention of prerequisites or conditions where this tool is preferred over similar tools like 'working_set' or 'explain_memory'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It does state the core behavior—summarizing intention counts—but does not explicitly clarify that it is read-only or describe the output format. For a report, this is adequate but 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that gets straight to the point. It front-loads the verb and resource and then lists the specific counts in a compact enumeration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter report with no output schema, the description adequately conveys what data it provides: counts for five categories of the intention register. It could mention the overall total or whether it also includes lists, but the core information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema fully covers the input surface. The description adds no parameter information, but none is needed. The baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Summarize') and resource ('intention register') and enumerates exactly which counts it reports (active, overdue, next upcoming, completed, cancelled). This clearly distinguishes it from other report tools in the sibling set, which focus on different data (e.g., practice_report, similarity_report).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't state that this is the go-to for an overview of intentions, nor does it mention any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of disclosing behavior. It only describes the output (score and penalties) but does not explicitly state that it is a read-only operation or that it has no side effects. It also doesn't mention any prerequisites or potential recomputation. Since it appears to be a monitoring tool, this lack of explicit safety semantics is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the key output (score with itemized penalties). Every phrase adds meaningful detail (linked ratio, crowded cues, conflicts, etc.) without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no params, no output schema), the description is largely sufficient: it specifies the return value type, range, and components. It could be improved by adding a note about when this is appropriate compared to sibling tools, but the essential info for invocation is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. The baseline for 0 params is 4. The description adds no parameter-specific info because there are none, but it doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool produces a memory-health score (0-100) with itemized penalties, which is specific and distinguishes it from sibling tools like memory_status or memory_audit. It names the exact resource ('overall memory-health score') and the components of the score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use it when you want a high-level health score with penalty details. However, it provides no explicit guidance on when to prefer this over alternatives (e.g., memory_status or practice_report), and lacks any exclusions or alternative recommendations. It merely describes what the tool does.
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?
The description discloses key behavior (splitting into sentences, storing with automatic cues) which is valuable given no annotations. However, it doesn't explain what 'automatic cues' entail or any side effects, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the purpose and usage. Every word adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and usage, but given no output schema and no explanation of max_segments or return values, it is only minimally complete 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The text parameter is implied through 'splits the text into sentences,' but max_segments is completely unexplained. With 0% schema description coverage, the description fails to fully compensate, leaving one of two parameters ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves one conversation turn, splitting text into sentences and storing them with automatic cues. This distinguishes it from the sibling 'remember' by emphasizing turn-level granularity and automatic processing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to call after every user/assistant exchange to keep memory automatic. While this provides clear usage context, it does not mention alternatives or exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions the input (retrieval history) and the formula (median survival span -> decay rate), but does not disclose whether this mutates the system's memory parameters, requires any prerequisites, or what side effects may occur. This is a significant transparency gap for a calibration operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the purpose and the core transformation without any wasted words. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate but leaves gaps: no mention of the output format, whether it writes back to the system, or how it relates to similar tools like curve_fit. Given the lack of annotations and output schema, more behavioral context would be beneficial, but the core concept is understandable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema coverage is trivially 100%, so the baseline is 4. The description adds meaning beyond the schema by explaining the implicit input (real retrieval history and median survival span), which helps the agent understand what data is used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'calibrate', the object 'forgetting rate', and the source 'real retrieval history', with the transformation 'median survival span -> decay rate' providing specific scope. This distinguishes it from siblings like curve_fit or next_interval by emphasizing calibration from historical data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: use when you have real retrieval history and need to compute the decay rate. It doesn't explicitly exclude alternatives or name them, but the phrasing implies when it is appropriate. Lacks explicit 'when not to use' 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?
With no annotations, the description discloses the main behaviors: moving the failing step to end (avoided), preserving alternatives, and storing the decision. It adds context about the re-planning decision being stored, which is valuable, though it lacks specifics on parameter semantics and potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and includes all necessary components without redundancy. Every phrase adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters with zero schema descriptions and no annotations, the description is insufficiently complete. It explains the overall behavior but omits parameter meanings (especially top_k) and does not specify return values or prerequisites, making it hard for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the three parameters (goal, top_k, failed_step). The description only vaguely references the failing step but does not define goal or top_k. It fails to compensate for the lack of schema descriptions, leaving half the parameters ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Re-plan') and resource ('after a failed step'), and clearly describes the action: moving the failing step to the end, keeping successful alternatives, and storing the decision. This distinguishes it from siblings like 'plan' and 'plan_rewrite' by specifying the re-planning 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly conditions usage on 'after a failed step', providing clear context. It does not mention when not to use or alternatives, but the context is sufficient for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly states 'Read-only,' which conveys the key behavioral safety trait. It also clarifies that it displays an insertion made by the time-anchor pass, giving context about what the tool does. However, it does not describe output format or edge cases like missing memories, but this is sufficient for a simple read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loaded with the core purpose. The first sentence is highly informative. The second sentence includes an academic citation (Gauthier et al., 2020) that adds little to tool selection/invocation and could be omitted, but overall the description is not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no annotations, no output schema), and the description gives a clear purpose and safety indication. However, it lacks parameter semantics and return-value expectations, which are not covered by schema or output schema. This creates gaps for an agent trying to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters (query and top_k). Although it implies query is the user's style question, it does not define what top_k means or how param values affect behavior. This leaves the agent guessing on parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource: it shows which memory the time-anchor pass inserted, scoped to '上次/下次/最近/什么时候' style questions. It distinguishes itself from sibling tools like recall or search by focusing on the time-anchor pass and last-vs-next retrieval verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on when to use: for verifying last-vs-next retrieval in ordinal time processing questions. It does not explicitly exclude alternatives or name sibling tools, but the trigger ('上次/下次/最近/什么时候' style question) serves as a clear usage indicator.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It uses non-mutating verbs ('check', 'recommend') implying a read-only/analytical operation. It adds behavioral context by citing Miller, Cowan, and Sweller, explaining the underlying decision rules. However, it does not explicitly state that no changes are made to the working set.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with parenthetical citations. It is dense but not verbose, and it front-loads the main purpose. The citations add context without unnecessary wordiness, though they could be trimmed for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and three undocumented parameters. The description provides purpose and theoretical basis but omits parameter semantics and what the output looks like. It is adequate for a simple diagnostic tool but incomplete for full autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameters. It does not clearly define 'limit', 'optimal', or 'capacity'. While the theoretical references hint at capacity concepts, there is no explicit mapping to the input parameters, leaving the agent to guess their roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: check if working set fits working memory and recommend chunking. It uses specific verbs ('check', 'recommend') and identifies the resource ('working set'), distinguishing it from likely siblings like 'working_set' which probably modifies the set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It indicates when to use the tool: 'when overloaded'. This provides clear context, though it does not explicitly mention alternatives or when not to use it. The inclusion of cognitive load theories implies usage for capacity assessment and planning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It usefully discloses that only active memories are included and that output is versioned with retrieval stats, but it does not explicitly state non-destructive behavior, potential payload size, or any response/error format beyond 'JSON payload'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence conveys all essential information without redundancy. Every phrase ('all active', 'portable', 'versioned', 'includes retrieval stats') adds substantive meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema and no annotations, the description adequately covers the return value and scope. It could be improved by noting intended use cases and non-destructive behavior, but it is complete enough for an agent to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100%, so the baseline is 4. The description adds value by describing output characteristics (versioned, includes retrieval stats) even though there are no parameter semantics to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Export'), names the resource ('all active memories'), and specifies the output format ('portable JSON payload, versioned, includes retrieval stats'). This clearly distinguishes it from sibling tools like import_memories and kg_export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a portable backup or transfer of memories is needed, but it provides no explicit when-to-use guidance or exclusions. It does not mention alternatives such as kg_export or import_memories, leaving the agent to infer selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states that the tool forecasts due memories and includes due times, implying a read-only operation. However, it does not explicitly confirm non-mutating behavior, output format, or any assumptions about the forecasting model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys both the action and the purpose. No unnecessary words or vague language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description provides sufficient context: it states the core behavior and a typical use case. It does not detail edge cases or return format, but this is less critical for a straightforward forecasting tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter ('days') with zero description coverage. The description compensates by referring to 'the next N days', which implicitly maps to the 'days' parameter and provides its meaning. However, it does not specify constraints (e.g., default, minimum, maximum) or whether the parameter is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Forecast which memories are due within the next N days, with due times') and the resource (memories). It also includes the intended use case (plan a week of reviews), which distinguishes it from potential sibling tools like 'practice_report' or 'practice_plan'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to plan reviews ahead of time. It does not explicitly list alternative tools or exclusions, but the purpose statement effectively guides usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does well by disclosing what the tool returns: candidates scanned plus top results with scores and reasons. It does not mention side effects or permissions, but for an explanatory tool this is reasonably transparent about the core 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. Every phrase adds value, and it efficiently captures the tool's purpose and output components.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderately complex tool with no output schema and no annotations, the description explains the purpose and output shape but leaves gaps: parameter meanings are not fully specified, and usage context relative to many sibling tools is only implicit. It is not a complete replacement for schema/annotation guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for both parameters. It implies the query parameter and mentions 'top results,' which loosely maps to top_k, but it does not explicitly define top_k, its default, or constraints. This leaves significant ambiguity for the integer parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'explain' and clearly identifies the resource ('why a query recalls what it recalls') plus the components of the explanation ('candidates scanned, top results with scores and reasons'). This distinguishes it from sibling tools like 'recall' or 'search' which return results rather than explain 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for gaining a metacognitive explanation of a query's recall behavior, which is a clear context. However, it does not explicitly contrast with alternatives like 'recall' or 'retrieval_quality', nor does it state when not to use it, so it lacks explicit exclusions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return value (adaptive scheduler state with streak and next review) and describes the input structure as {id, success}. However, it does not explicitly state side effects (e.g., mutations to scheduler state), idempotency, failure modes, or any prerequisites, leaving important behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the main action and immediately providing input and output details. Every word contributes meaning, with no redundant phrases, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple parameter set and no output schema, the description covers the essential aspects: what the tool does, the input format, and the return value. However, it omits details about side effects, error handling, or behavior for invalid inputs, which would be beneficial for a batch operation. The description is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only lists 'answers' with nested properties, and schema coverage is 0%. The description adds semantic meaning by clarifying that each answer is {id, success} and these represent spaced-repetition outcomes. It also implies the expected structure ('for every card') beyond the raw schema, which is valuable given the low schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies a batch of spaced-repetition outcomes, using a specific verb ('Apply') and resource ('batch of spaced-repetition outcomes'). It also specifies the return value (adaptive scheduler state for every card), which differentiates it from single-card tools like 'review' or 'record_outcome' among its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for batch processing of repetition outcomes but does not provide explicit when-to-use guidance or exclusions. It does not mention alternatives or context where this tool should be preferred over singular review tools. The 'batch' qualifier offers some implicit context, but no direct 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?
With no annotations provided, the description carries the full behavioral transparency burden. It explicitly discloses the non-destructive nature ('without deleting anything') and outlines the selection criteria ('unimportant, never accessed, old'). This goes beyond simply stating the tool's function and provides useful safety-relevant 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose. Every word contributes meaning, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple preview tool with one optional parameter and no output schema, the description provides a clear purpose, selection criteria, and non-destructive guarantee. The main gaps are the undocumented limit parameter and the lack of explicit output format, but the low complexity and clear intent make it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema contains one optional 'limit' integer parameter with 0% description coverage. The tool description does not mention this parameter or explain how it affects the preview, leaving it entirely up to the agent to infer from the parameter name. Since the description was expected to compensate for the lack of schema documentation, this is a notable omission.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it previews which episodic traces would be recycled by the sleep prune pass. It distinguishes itself by explicitly noting that nothing is deleted, setting it apart from the actual sleep prune 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without deleting anything' provides clear context for when to use this tool (as a safe dry run before the sleep prune). However, it does not explicitly name alternative tools or state when not to use it, though the contrast with the actual sleep pass is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full transparency burden. It discloses a specific behavior (re-embedding missing memories) and the triggering scenario, but does not mention side effects, idempotency, or whether it can be safely run multiple times. This is a moderate disclosure, enough to understand the core action but lacking deeper behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the main action ('Re-embed active memories missing from the vector index') and adds a useful parenthetical that explains the repair intent. Every word earns its place; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (0 params, no output schema), so the description covers the core action and a likely trigger ('failed batch embedding'). However, it does not mention prerequisites, success verification, or whether manual intervention is appropriate, leaving some contextual gaps for an agent deciding to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the empty schema imposes no information burden. The description adds value by explaining the tool's purpose, though it does not need to elaborate on parameter semantics. Baseline for 0 params is 4, and the description meets that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Re-embed active memories missing from the vector index') and adds the purpose ('repairs a failed batch embedding'). This distinguishes it from sibling tools like 'remember' or 'recall' by focusing on index repair, not memory creation or 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used after a batch embedding failure, providing clear context for when to invoke it. However, it does not explicitly name alternatives or state when not to use it, so it falls short of full usage 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?
With no annotations, the description carries the full burden. The verb 'List' clearly indicates a non-mutating operation, and 'currently suppressed memories' clarifies the scope. It adds useful context about previews, though it does not mention pagination, ordering, or side effects, but for a simple list tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single, front-loaded sentence that conveys all necessary information without any wasted words or extraneous details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with no output schema, the description is complete. It states exactly what is listed (suppressed memories) and that previews are included. The simplicity of the tool means no additional context is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. No further explanation is needed, and the description is consistent with the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('currently suppressed memories') with an added detail ('with previews'). It clearly distinguishes itself from sibling tools like suppress_memories or unsuppress_memories by focusing on reporting rather than mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool compared to alternatives such as memory_status or recall_log. The description implies a read-only report, but it does not explicitly state when this tool is preferred over other memory inspection 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?
With no annotations, the description carries the full burden and covers key behavior: non-destructive ('traces stay in the store'), effect on recall ('stop surfacing in recall'), and reversibility ('until unsuppressed'). It omits potential side effects but provides the essential behavioral contract.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 19 words, front-loaded with the action verb 'block' and free of filler. Every phrase earns its place, delivering purpose, behavior, and reversibility efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter and no output schema, the description is nearly sufficient, explaining the operation and its reversible nature. It could mention the counterpart tool 'unsuppress_memories' or expected return type, but the core functionality is well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description only mentions 'memories' generically, without explaining what memory_ids refer to, where they come from, or any constraints. The schema provides type info only, so the description adds minimal semantic value beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Temporarily block memories from retrieval') and the resource ('memories'), plus the reversible scope ('until unsuppressed'). This distinguishes it from sibling tools like 'forget' (likely permanent) and 'unsuppress_memories' (the opposite operation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'temporarily' provides clear context for when this tool is appropriate, implying a reversible suppression use case. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing side effects. The verbs 'Monitor', 'flag', and 'report' clearly indicate a non-destructive read-only operation, and it lists outputs rather than mutations. It does not explicitly state 'does not modify data', but the behavioral intent is unambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the main action ('Monitor adherence') and then lists three specific, valuable outputs. The citation adds context without being excessive. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema), the description covers the essential return values: overdue flags, adherence ratio, and advice. It does not specify whether it works globally or per-item, nor the format of 'plain advice', but for a monitoring tool of this scope it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is empty. The baseline for 0 params is 4, and the description appropriately omits parameter details since none exist. There is no additional parameter information needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with the specific verb 'Monitor' and clearly identifies the resource ('adherence to the spaced-review schedule'). It enumerates concrete outputs (flag overdue reviews, adherence ratio, plain advice) that distinguish this tool from siblings like 'review_due' or 'stats'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when monitoring spaced-review adherence) but does not name any alternative tools or exclusions. There is no explicit 'use this instead of X' guidance, which would be useful given the large number of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly states the read-only action ('Return') and defines conflict criteria, making the behavior unambiguous. However, it does not clarify 'active' or describe the output format, which would be additional useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence front-loads the core action and criteria, while the second states the intended use. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless list tool with no output schema, the description covers the key aspects: what is returned, the definition of conflict, and a clear use case. It could mention related tools, but this is not necessary for a straightforward read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description adds no parameter-specific details because there are none, but the schema itself is trivially understood.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Return active memory conflicts' – a specific verb and resource – followed by precise criteria ('same cue, both confident, different content'). This clearly distinguishes it from sibling tools like conflict_advice and resolve_conflicts, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Agents can use this to spot contradictions before answering.' It does not name alternative tools or exclusions, but the context makes the intended use case clear, aligning with the 'clear context, no exclusions' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently explains the two behavioral branches: 'lopsided-evidence conflicts retire the stale trace' and 'balanced ones lose confidence', including the mechanism (accommodation + REM-style resolution). It could mention reversibility or side effects, but the core behavior is well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, dense sentence that front-loads the action and resource, then efficiently explains the resolution rules. No wasteful words; every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description covers the essential context: what the tool does and what outcomes occur. It does not state expected return values, but for a mutation tool the effect is fully described. Overall adequate and complete for the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to document. Per the rubric, 0 params receives a baseline of 4. The description adds context about the task rather than parameter details, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Resolve memory conflicts on demand.' It further distinguishes itself from siblings by specifying two resolution outcomes (retiring stale trace or losing confidence), which separates it from list_conflicts and conflict_advice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'On demand' gives usage context. The two conflict types imply when to use it (when lopsided or balanced evidence conflicts exist). It does not explicitly name alternatives, but the intent is clear enough to guide an agent. No exclusions are mentioned, 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.

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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/liyexiaoyi/Mnemosis'

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