WhiteMagic — governed local memory for agent continuity

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the context that this is a provenance readout, aligning with the annotations, but it does not disclose additional behavioral details beyond what annotations already provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single focused sentence with a clear verb, a concise object, and a helpful parenthetical clarification. It contains no filler and is immediately understandable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is adequate as a minimal purpose statement and is supported by complete schema descriptions and rich annotations. It lacks explicit guidance on how the optional claim parameters relate to the provenance query, and it does not address usage boundaries, so it is not fully complete on its own.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all six parameters are individually documented. The description does not need to explain parameter semantics and does not add meaningful parameter-level guidance beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Explain'), the resource ('memory or route'), and the specific outcome ('why ... was selected'), which makes the tool's purpose obvious. It does not explicitly distinguish itself from siblings, but no sibling appears to offer provenance explanation, so the purpose is sufficiently clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 an agent needs an explanation of why a memory or route was selected. It does not provide explicit when-not-to-use guidance or name alternatives, though the tool's specialized purpose makes the intended use reasonably inferable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds context about what the status includes (galaxies, counts, index health) but does not go beyond that. It does not contradict annotations, but provides only moderate additional 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that is front-loaded with the core purpose. It is efficient with no waste and covers the essential aspects.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only status tool with no parameters and an output schema present, the description is sufficiently complete. It mentions the key elements (galaxies, counts, index health) and the output schema handles return details. No critical information is missing for an agent to call this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so the baseline is 4. The description does not need to explain parameters, and the input schema confirms no parameters are required. This is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear purpose: providing status on the knowledge surface, including galaxies, counts, and index health. It is specific about the resource and what it covers. It does not explicitly distinguish from sibling tools, but given the unique 'status' nature, the purpose is clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for checking status but provides no explicit when-to-use guidance or exclusions. It does not mention alternatives or when not to use it. The context is understandable but lacks explicit direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which establishes the safety profile. The description does not contradict these and adds minimal behavioral context (e.g., that it aggregates over 'matched memories'). It does not specify behavior like handling of empty results or the exact output format, but with an output schema present, the bar is lowered. This is an adequate but not enriching disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence, which is concise and front-loaded with the main verb. However, it is so terse that it omits essential specificity (e.g., metric options, relationship to siblings). It is not verbose, but it is under-specified, which is a structural weakness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's medium complexity (3 params, output schema) and the large sibling set, the description fails to provide necessary context. It does not explain the metric enumeration, the role of the query parameter, or how this differs from memory.count/stats. The presence of an output schema reduces the need to describe return values, but the description still lacks enough to guide correct selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (all three parameters have descriptions), so the baseline is 3. However, the description's phrase 'numeric or categorical field' is misleading because the metric parameter is an enum of aggregate types, not a field name. This actively confuses interpretation rather than adding value. The description does not clarify the meaning of 'metric' or the limit default, relying solely on schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb ('Aggregate') and resource ('memories'), and mentions 'numeric or categorical field' which hints at the metric parameter. However, it is vague about what specific aggregates are available (the metric values are count, session_count, session_span) and it uses the word 'field' when there is no such parameter. It does not differentiate from siblings like memory.count or memory.stats, leaving the agent to infer exact behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance is given about when to use this tool versus the many siblings (e.g., memory.count, memory.stats, memory.list). The description does not mention alternatives, usage contexts, or prerequisites. With a crowded toolset, 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the tool is known to be safe and non-mutating. The description adds the concept of spreading activation, which hints at the underlying algorithm but doesn't clarify specifics like traversal depth or whether results are limited. This additional context is useful but not comprehensive, so the score 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the core purpose. It is not verbose and every word adds value. However, it could have included a brief note about direction handling to improve clarity without much length increase.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema, the return format is presumably documented elsewhere, so the description doesn't need to explain it. The tool has two simple parameters and safe annotations. However, the lack of usage guidelines and the vague concept of 'spreading activation' leave some gaps, but overall it's adequate for a straightforward read operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, meaning every parameter (id and direction) is documented in the schema. The description does not add any additional semantic information beyond the schema, such as the meaning of 'from' vs 'to' in the direction parameter. Since the schema already covers the parameters, the description is adequate but not additive.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: it retrieves associative neighbours of a memory using spreading activation over the association graph. This is specific and identifies the resource (a memory) and the action (inspecting associations). However, it doesn't explicitly distinguish it from siblings like memory.nearby or memory.hybrid_recall, which might also involve related memories.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide any guidance on when to use this tool versus alternatives. It doesn't mention when to choose associations over other memory retrieval tools, nor does it explain the concept of spreading activation in practical terms. The agent must infer 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds only the batching aspect ('in one call'), which is a minor behavioral note. It does not disclose potential partial-failure behavior or ordering guarantees, but given annotations, the additional context is acceptable and not contradicting.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that front-loads the action and purpose. There is zero waste; every word earns its place. It is concise without being under-specified for the simple operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only batch operation, the description is sufficient in terms of core functionality, and the output schema plus annotations cover much of the context. However, it does not mention behaviors like partial success if some IDs are invalid, or whether the result preserves input order. These are not critical but would be helpful for a complete understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Both parameters (ids and galaxy) are fully described in the schema (100% coverage), so the description is not required to explain them. The description adds nothing beyond what the schema already provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Read'), the resource ('memories'), and the batching aspect ('several memories by id in one call'). It distinguishes from a single-read tool implicitly through 'several', but does not explicitly name the sibling memory.read, which would sharpen differentiation. Still, the purpose is unambiguous and specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use it (when you need to read multiple memories by ID) but provides no explicit guidance on when not to use it or alternatives. A reader must infer that memory.read is for single reads, but no direct comparison is made. Usage context is clear but not fully articulated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds that it does not return content, which is useful. However, it does not disclose what exactly the count represents (e.g., all memory types?) or any performance considerations or limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One concise sentence that front-loads the key behavior ('Count memories') and adds the critical side effect ('without returning content'). Zero waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema (likely a count value) and full parameter coverage, the description is largely complete. It could mention whether the count is approximate or exact, but the presence of an output schema and simple parameter list makes it sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 100% of the parameter (galaxy) with a clear description, so the baseline is 3. The description mentions 'matching optional filters' which implies the galaxy parameter is a filter, but it doesn't add new details beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Count' with resource 'memories' and clearly states that it returns a count, not content. This distinguishes it from sibling tools like memory.read, memory.query, and memory.list, which would return actual memories.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for counting memories without returning content, which suggests it for aggregation or existence checks. However, it does not explicitly state when to use it over memory.stats or memory.aggregate, 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description is not required to repeat safety traits. However, it adds no behavioral context beyond a restatement of filter dimensions—no mention of pagination, default limits, result ordering, or the fact that all parameters are optional.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, front-loaded with the verb and resource, and contains no filler. Every word contributes to the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite rich schema and output schema, the description is too sparse for a 10-parameter tool with many siblings. It omits the query parameter, does not explain how filters combine, and offers no selection guidance, leaving an agent to open the schema to understand even basic usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds a light grouping of tags/importance/recency as 'metadata,' which is helpful but does not add syntactic, format, or combinatorial details beyond what the parameter descriptions already provide.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Filter') and resource ('memories') and names three metadata categories (tags, importance, recency) that map to schema parameters. It does not explicitly differentiate from sibling tools like memory.search or memory.query, and it omits the query parameter, so it under-represents the full capability set.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to prefer this tool over siblings like memory.search, memory.query, memory.list, or memory.hybrid_recall. With a large family of memory tools, an agent cannot determine selection criteria from the description alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description's only added behavioral claim is equivalence of implementation, arguments and results with memory.search — useful but thin; it says nothing about recall semantics, latency, or behavior on cold/unindexed data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, zero filler, with the identity of the tool front-loaded and the routing recommendation immediately after. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an alias tool with an output schema, complete parameter documentation and rich annotations, the description supplies exactly the missing piece — that this is not a distinct capability and should not be chosen over memory.search unless the client is pinned to the name.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% across all 12 parameters, so the schema carries full parameter semantics (limits, time bounds, trust/importance floors, cold recovery). The description adds no parameter-level detail beyond declaring the arguments identical to memory.search; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states precisely what this tool is — a compatibility alias of memory.search with identical implementation, arguments and results — and names the canonical sibling, so an agent can route without opening either schema. It does not independently describe the underlying operation (memory search/recall), deferring that to memory.search, which keeps it just short of a self-contained 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit use condition ('kept for clients pinned to this name') and an explicit preference ('prefer memory.search'), which is exactly the when/when-not/alternative guidance the dimension asks for.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, covering the full safety profile. The description adds no behavioral context beyond that — no pagination behavior, no note on default galaxy scoping impact, nothing not already in structured data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single compact sentence with the operation front-loaded and filters in parentheses. Efficient, though the trailing 'for browsing and discovery' clause is filler that does not earn its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and annotations covering safety, the description needn't explain return values, and a zero-required-param list is simple. But given an unusually crowded sibling set of near-identical retrieval tools, the complete absence of differentiation leaves an agent under-equipped to pick this one.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the schema fully documents limit, galaxy, offset, and exclude_tags with defaults. The description largely restates these and even names 'tags' where the actual parameter is 'exclude_tags', a minor imprecision rather than added meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a clear verb+resource (list memories) and names the filter dimensions, so the agent knows the operation immediately. However, it does nothing to separate itself from close siblings like memory.filter, memory.query, or memory.search, which likely overlap heavily with 'list with filters'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'for browsing and discovery' is a vague sentiment rather than guidance; it never states when to choose this over memory.filter, memory.query, or memory.search, all of which appear to be filtered retrieval tools. No exclusions, no prerequisites, no alternative routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description is not required to restate those. It adds the '5D spatial neighbourhood' context but does not clarify behavioral details such as ordering, default radius behavior, or how the text query maps to coordinates.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, short sentence with no filler, and the core spatial concept is front-loaded. It is concise but slightly cryptic; 'coordinate address' and '5D spatial neighbourhood' could be clearer without additional explanation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With output schema present, annotations covering safety, and full schema parameter coverage, the description does not need to explain return values or safety. However, it leaves the meaning of '5D spatial neighbourhood' and coordinate addressing underspecified, and it offers no routing guidance among the many sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema fully documents all four parameters. The description adds no additional parameter-level meaning beyond the schema, which is acceptable given the high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource ('memories') and the operation ('near' a coordinate address), and adds the distinctive '5D spatial neighbourhood' concept. However, it does not explicitly differentiate this tool from siblings like memory.vector.search or memory.query, which could also operate over the same space.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'near a coordinate address' implies the tool is for spatial proximity lookups, giving some context. But there is no explicit guidance on when to prefer this over alternatives, nor any when-not-to-use conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the read-only nature is covered. The description adds no behavioral details beyond 'structured query', such as default ordering or whether it is exact-match only; it does not contradict the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence with no filler or duplicated schema content; 'filters and ordering' gives a compact summary of the tool's behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a rich input schema, an output schema, and complete annotations, the definition is usable for invoking the tool, but it doesn't provide enough high-level context to choose among memory.query, memory.filter, memory.list, and memory.search, and the 'ordering' claim is left unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema fully documents each filter, default, and timestamp format. The description adds no parameter-level meaning and even mentions 'ordering' without exposing an ordering parameter, but with full schema coverage the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a clear operation (structured query) and resource (memories), and notes it supports filters and ordering. However, it doesn't distinguish memory.query from sibling tools like memory.filter, memory.list, or memory.search, which also operate over memories.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given in the tool description about when to use this tool versus the many sibling memory tools; the only useful routing hint (use memory.search for ranked full-text retrieval) appears inside the query parameter's schema description rather than in the main description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the description need not restate it. It adds only the 'coordinate address' notion, which hints at an alternative addressing scheme beyond a plain UUID. This is useful but thin; no behavior like existence handling or cross-galaxy resolution is disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler or repetition; efficient and easily parsed. Slightly sparse, but for a simple read tool it is appropriately sized rather than bloated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a rich output schema, fully described parameters, and annotations covering safety/idempotency, the description doesn't need to cover return values or mutation risks. The main gap is usage routing among the many memory siblings and the ambiguity of 'coordinate address' versus UUID, which could matter for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: id is documented as 'Memory UUID' and galaxy as 'Galaxy containing the memory (default codex)', so the schema already explains both parameters. The description's 'or coordinate address' adds slight nuance suggesting id can be a coordinate rather than only a UUID, offering marginal value over the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Retrieve') and resource ('a specific memory'), and the qualifier 'by its ID or coordinate address' plus 'specific' implies single-record fetch, which distinguishes it from batch_read, list, and search siblings. However, it doesn't explicitly name or contrast any sibling tool, leaving some differentiation to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'by its ID or coordinate address' implies this tool is for lookup when an identifier is already known, giving minimal context about when to reach for it. But it offers no explicit when-to-use / when-not-to-use guidance and names no alternatives among the two dozen memory/query siblings, so routing is left largely implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context beyond annotations: it explains that every content update is chained and head-checked, which conveys the tamper-evidence mechanism and the verify action's purpose.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence states the verb, resource, and purpose without wasted words. The parenthetical 'tamper evidence' efficiently communicates the tool's intent, and the chaining detail earns its place by explaining the behavioral guarantee.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, full parameter coverage in the schema, and annotations covering safety and idempotency, the description is nearly complete for an agent to invoke the tool correctly. The only minor gap is that 'head-checked' is not elaborated, though the output schema likely clarifies the returned verification data.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents id, action, and galaxy. The description's 'List or verify' maps to the action parameter but adds no new semantic detail beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('List or verify') and a specific resource ('a memory's content revision chain'), and adds the purpose ('tamper evidence'). This clearly distinguishes it from siblings like memory.read or memory.search, which deal with current content or retrieval rather than revision history.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'tamper evidence' implies the tool is for integrity checking, and the action parameter distinguishes listing from verifying. However, the description does not explicitly state when to use this tool versus alternatives such as memory.read, receipts.verify, or memory.aggregate, nor does it mention any exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower. The description still adds real behavioral context: fusion with deterministic episodic/full-text fallbacks, and that each result self-reports its recall_mode, which tells the agent how to interpret heterogeneous result quality. It omits the cold-recovery/no-thaw nuance, but that is covered in the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler, with the core mechanism stated first and the positioning claim last. Every clause carries information an agent can act on.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter hybrid search tool with a full output schema and complete annotation coverage, the description supplies the mechanism, fallback semantics, and result-labeling behavior an agent needs to trust the output. It would be stronger if it positioned itself against the near-identical siblings, but nothing required to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% across all 12 parameters, including non-obvious ones like time_basis, include_cold, and min_score_ratio, so the schema carries the full burden. The description adds no parameter-level meaning beyond the schema; baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb+resource (search memories) and discloses the retrieval mechanism (hybrid BM25 + vector fusion with deterministic fallbacks), which is more than a restatement of the title. It does not, however, differentiate itself from close siblings such as memory.hybrid_recall, memory.vector.search, or memory.query — 'the preferred recall tool' asserts priority without explaining the distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'The preferred recall tool' is a routing hint that implies this is the default choice for recall, which is useful signal. But it names no alternatives and gives no when-not-to-use condition (e.g., use memory.vector.search for pure semantic similarity, memory.filter for structured constraints), so the agent must infer the boundaries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and non-destructive, so the safety profile is covered. The description adds useful batch context (concurrency, 10-query cap, curated corpus) but omits how results are consolidated or how partial failures are handled.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences with the batch behavior front-loaded; little waste. The 'unpacks' wording is slightly vague but not costly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only batch search with full schema coverage and annotations carrying the safety profile, this is largely adequate. However, with no output schema, the description's vague 'consolidated results' leaves the return shape under-specified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description restates the 10-query cap already in the schema but adds no format guidance (e.g., how queries map to returned results) beyond what the schema documents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb+resource: batch-executes memory search queries concurrently and returns consolidated results. The batch semantics are stated precisely, though it never names the single-query sibling (memory.search) or memory.hybrid_recall, so differentiation from siblings is left to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'in a single turn' and 'up to 10 queries' implies the usage context (multiple lookups at once), but there is no explicit when-to-use/when-not guidance or naming of alternatives such as memory.search for single queries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds semantic context about what the statistics include, but does not disclose permissions, rate limits, or result shape beyond what the output schema provides.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence that directly names the resource and its key outputs. There is no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only statistics tool with full parameter documentation, comprehensive annotations, and an output schema, the description is nearly sufficient. It only lacks explicit usage guidance, which is a minor gap given the simple, single-purpose nature of the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the single optional galaxy parameter is fully documented in the schema with its default (codex). The description adds no additional parameter guidance, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb-resource relationship — statistics on the memory index — and enumerates what those statistics cover: totals, galaxy spread, and index health. It is clearly distinct from count/list/search siblings, though it does not explicitly name an alternative tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied: call this when you need summary statistics about the memory index. There is no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as memory.count or memory.aggregate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds the specific output detail (usage counts), which is useful context. It does not mention pagination or error behavior, but for a simple list tool with these annotations, the added detail 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no redundancy. It conveys the purpose and the key output detail efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values are covered elsewhere. The tool is simple with one optional parameter and no nested objects. The description, combined with the schema and annotations, provides everything an agent needs to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the single parameter 'galaxy' is fully documented in the schema. The description adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb (list), a specific resource (tag vocabulary), and adds a distinguishing detail (with usage counts). This differentiates it from sibling memory tools like memory.list (which likely lists memories) and memory.stats (which might give aggregate stats).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 such as memory.aggregate, memory.count, or memory.stats. The description only states what it does, without any context for selecting it over similar read-only tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is well covered. The description adds little beyond restating the title, but it does not contradict the annotations and no destructive caveats are needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. It is concise and readable, though its brevity leaves room for more useful guidance about when to choose this tool over similar siblings.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple read-only nature, annotations, and full schema coverage, the definition is minimally viable. However, the lack of sibling differentiation and usage context for embedding-based versus keyword or hybrid search leaves a meaningful gap for correct tool selection.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already documents the semantics of memory_id, embedding, limit, and galaxy, including that embedding is an alternative to memory_id. The description itself contributes no additional parameter-level detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: it is a vector-similarity 'search' over 'memory embeddings'. It clearly communicates the core operation, but does not explicitly differentiate it from sibling tools like memory.search or memory.hybrid_recall.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 such as memory.search, memory.hybrid_recall, or memory.nearby. The description only states what the tool does, leaving the agent to infer appropriate invocation context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish this as a read-only, idempotent, non-destructive local operation, so the bar is lower. The description still adds real behavioral context beyond them: verification works offline, it is fail-closed, and an absent anchor yields a PROVISIONAL verdict rather than an error.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence that front-loads the action and both input modes, then the fail-closed consequence. No filler and nothing redundant with the structured fields.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not explain the verdict payload, and the key behavioral caveats (offline, fail-closed, PROVISIONAL) are covered. It is complete enough for a four-param verification call, though it says nothing about failure modes for malformed bundles.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and all four parameters are documented there, so the schema does the heavy lifting. The description's mention of id vs bundle as alternatives and the PROVISIONAL consequence of require_anchor largely restates what the schema descriptions already say.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (verify) and resource (continuity receipt) and names the two input modes, receipt id or inline bundle. It does not explicitly differentiate itself from any sibling, but no sibling performs receipt verification, so the risk of confusion is low.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'verify a receipt id or a bundle' implies the calling context (checking a receipt's validity, usable offline), but there is no explicit when-to-use/when-not guidance or named alternative. Usage must be inferred rather than read.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds the conceptual shape of the result (turns, checkpoints, open work) but says nothing about default behaviour such as excluding the current session, truncation/budget behaviour, or what a checkpoint contains; an output schema exists, which lowers but does not remove that burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with zero filler; the payoff (recent turns, checkpoints, open work) comes immediately after the verb. Nothing is repeated from the schema or annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only recall tool with a full output schema and 100% parameter coverage, the description supplies the essential framing. It stops short of situational guidance (when resuming vs. when doing a targeted memory.search) which would be the remaining useful addition.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all seven parameters (n, since, until, byte caps, current_session_id, briefing flag) are fully documented in the schema. The description adds no format, default or interaction detail beyond that, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (recall) and resource (where the previous session left off), and enumerates the returned content: recent turns, checkpoints, open work. It never distinguishes itself from near-neighbours like session.recall, session.replay or session.list, so an agent cannot route between them from the description alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use guidance, no conditions, and no named alternative. The intended occasion (resuming after a break) is only inferable from the phrase 'where the previous session left off', and the presence of session.recall/session.replay in the sibling set makes the choice genuinely ambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to restate safety. The description adds minimal behavioral context ('with titles and summaries'), but there is no contradiction and no unexpected side effects are implied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence containing only useful information. It is front-loaded with the main action and adds the relevant output detail without unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only list tool with a complete input schema and output schema present, the description is mostly sufficient. It could be slightly stronger with a brief note on when to choose this over sibling session tools, but nothing critical is missing for a correct call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the input schema already explains each filter parameter clearly. The description adds no parameter-level meaning, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource: 'List sessions,' and adds that output includes titles and summaries. It doesn't explicitly distinguish itself from sibling tools, but the 'list' framing is specific enough to separate it from session.recall, session.replay, and session.continuity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 is no mention of when this is preferred over session.recall or session.replay, and no context about typical use cases or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds one useful behavioral detail—'without continuity packaging'—but does not go beyond that, which is acceptable given the strong annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no filler. The core action is front-loaded, and the distinguishing qualifier is placed immediately after the resource, making it easy to parse in one pass.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with only two optional parameters, an output schema, and strong annotations, the definition is nearly complete. The only minor gap is that 'continuity packaging' is not explained and no explicit pointer to session.continuity is given, but the sibling list mitigates this.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both limit and session_id fully documented in the schema. The description itself adds no parameter-level meaning, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Recall') and resource ('a session's turns'), and adds 'without continuity packaging' to distinguish this from a continuity-wrapped variant. This makes the tool's function immediately clear and separates it from session.continuity without needing to inspect the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'without continuity packaging' provides clear contextual guidance: this tool is for raw turns, not continuity-wrapped output. It does not explicitly name session.continuity or session.replay as alternatives, but the sibling list and the wording make the intended choice fairly inferable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the tool readOnly, idempotent, and non-destructive, which lowers the burden on the description. The description adds the useful fact that recorded turns are returned 'in order,' but it does not disclose mode-specific behavior, pagination, or the lossless cursor mechanics. There is no contradiction with the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence with no filler, and every word contributes to the basic purpose. It is concise, though it leans heavily on the title and sacrifices useful mode-level orientation for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Annotations, a 100%-covered schema, and the presence of an output schema carry much of the burden, so a terse description is acceptable. However, for a 12-parameter tool with four distinct modes, the absence of any high-level explanation of what 'full,' 'selective,' 'progressive,' and 'lossless' mean leaves a real semantic gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already documents all 12 parameters with formats, defaults, and mode-specific meanings. The tool description itself adds no additional parameter-level semantics beyond what the schema provides, so it meets the baseline without exceeding it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Replay') and identifies the resource ('a session's recorded turns') with an ordering constraint, making the core behavior clear. It does not, however, distinguish itself from the similarly named sibling session.recall, so an agent still has to infer which retrieval-style tool is appropriate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no when-to-use guidance, no exclusions, and no mention of alternatives such as session.recall or session.continuity. The mode options in the schema imply several distinct use cases, but the description does not help an agent choose among them.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with the READ-ONLY mode statement and the concrete refusal behavior for session.* and memory.create/update writes, plus the storage scope path. That is genuine added context beyond annotations, though rate limits and routing failure behavior are not described.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the meta-tool identity and capability areas, followed by mode, scope, and invocation syntax in a logical order. It is dense but every clause carries information; only the '70 tools' aside is arguably incidental.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a routing meta-tool with a rich output schema, the description covers mode, scope, all three invocation styles, the exclusivity constraint, enumeration, and the decision rule against discrete siblings. An agent has everything needed to call it correctly without opening the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds real semantic value: examples of route values ('memory.search', 'session.continuity'), the auto-routing behavior of thought, the passthrough nature of args, and the exactly-one-of constraint that the schema does not encode.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (persistent memory, session continuity, governance/audit, local tool execution) and explicitly frames itself as a routing meta-tool, which distinguishes it from the discrete siblings listed. The phrase 'memory and continuity kernel' is somewhat jargon-heavy, but the following clause grounds it in concrete capability areas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states exactly how to invoke (thought=, route=, args=), the mutual-exclusion rule ('provide exactly one of thought or route'), and when to prefer alternatives ('Prefer a discrete lifecycle tool when one matches your task; use wm for natural-language routing and the wider curated catalog'). It even documents the 'list tools' enumeration path.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.