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 usefully states that the tool returns every promote/pin/corroborate/review action with reason and timestamp, which reveals scope. However, it does not mention the limit parameter's effect, pagination, ordering, or that this is a read-only operation.

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 first sentence is front-loaded and information-dense. The second sentence is largely rhetorical and repeats the 'reason' concept, so it does not fully earn its place. Still, the overall length is appropriate and scannable.

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 one-parameter tool, the description covers the main return contents and distinguishes it as the audit log. Missing pieces include limit behavior, usage context, and explicit read-only assurance. The presence of an output schema reduces the need to describe returns, but the parameter gap remains.

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 0%, so the description must explain the parameter semantics. It never mentions 'limit' or how limiting interacts with the claim of returning the 'full' audit trail. This is a meaningful omission for the only parameter.

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 ('Return') and clearly names the resource ('full audit trail'), then enumerates the action types included (promote, pin, corroborate, review). This distinguishes it from siblings like 'current_narrative' or 'provenance' by positioning it as the complete history of accountable actions.

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 guidance on when to use this tool versus alternatives such as 'provenance' or 'current_narrative'. The description implies it is for retrieving audit history, but does not state exclusions, prerequisites, or conditions that would route an agent here instead of a sibling.

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?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It transparently details side effects: automatic upgrade of 'archive' to 'testimony', the need for two sources when origin is unknown/blank, trimming and case-sensitivity of source labels, source identity rules, and auditing of duplicates. This goes beyond a simple action description and covers non-obvious behaviors.

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 compact paragraph with no filler. Every sentence adds value: purpose, upgrade rule, special case for unknown origins, source handling, auditing, and the exclusion for interpretation-tier. It is front-loaded with the core action and then provides necessary conditions. No word is wasted.

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 tool with two parameters, no output schema, and no annotations, the description is remarkably complete. It covers the action, trigger conditions, edge cases (unknown origins), source identity nuances, and when to use an alternative tool. An agent would have all the information needed to decide when and how to invoke 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?

Schema description coverage is 0%, so the description must clarify parameters. It does: for `source`, it explains the semantics ('Source labels are trimmed, case-sensitive identifiers... repeated turns from one speaker or copies of a document are one source'), which is critical for correct invocation. The `memory_id` is implicitly a memory identifier, which is self-explanatory from the context. The description effectively compensates for the schema's lack of 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 clearly states the tool's purpose: 'Record that an independent additional source corroborates this memory.' It specifies the action (record corroboration) and the resource (a memory), and distinguishes itself by explaining the upgrade effect on 'archive' memories and explicitly excluding 'interpretation'-tier memories, which directs the agent to a sibling tool. This differentiates it from other memory-related tools.

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 explicit usage context: it explains when an upgrade happens (after a distinct source corroborates the origin), and clearly states when NOT to use it ('Has no upgrade effect on interpretation-tier memories — use review() for those instead'). It also specifies source counting rules (distinct sources, repeated turns counted as one), giving the agent clear conditions for invocation.

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?

With no annotations provided, the description carries the full burden and it delivers: it discloses the null-return case, the fact that stale text is included in the output, and the review_status/source_issues caveat. 'Inspect' also signals a read-only operation. One minor gap is that it never explicitly states whether the call is side-effect-free, but the overall behavioral profile is unusually 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.

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

Three sentences, no filler. The core behavior is front-loaded in sentence one, the safety caveat in sentence two, and the sibling differentiation in sentence three. Every sentence earns its place and the structure moves from what-it-does to how-to-use-it-safely to how-it-differs.

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 low-complexity tool (one optional parameter, output schema present), the description covers the purpose, null behavior, stale-text handling, and trust caveat. The notable gap is the 'scope' parameter, which is entirely unexplained — a real hole since the schema provides no description either. Output schema richness helps offset the lack of return-value detail.

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 0% for the single 'scope' parameter, so the description must compensate — and it never mentions 'scope' at all. An agent is left guessing what scopes are valid beyond the 'global' default and what effect scope has on the returned narrative. The parameter being optional softens the impact, but the description adds zero semantic value for the one parameter that exists.

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 opens with a specific verb ('Inspect') and a clear resource ('the latest stored narrative'), then pins down exact behavior: it includes stale text and returns null if none exists. It further distinguishes itself from the sibling tool 'recall' by explicitly noting that recall withholds stale narrative text by default, so an agent can tell the two apart without opening schemas.

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

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

The description gives a concrete caution about when the result should not be trusted outright ('Check review_status and source_issues before using the account as current evidence'), which functions as a when-not-to-use warning. The contrast with 'recall' ('Default recall withholds stale narrative text') implies when each tool is appropriate, though it stops short of an explicit 'use X instead of Y when...' formulation.

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?

No annotations are provided, so the description must disclose behavior. It states the queue is oldest-first and that items not promoted remain recallable, reassuring about state preservation. However, it doesn't explicitly state whether the tool is read-only, whether calling it has any side effects, or how pagination works. It adds some context but leaves the safety profile implicit.

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 well-structured: a clear purpose statement, then usage guidance, then a suggested flow. It's a bit longer than minimal but every sentence adds value, and the key information is front-loaded. No fluff.

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 tool has an output schema, so return structure is covered. However, the parameters are undocumented in both schema and description, and there's no mention of potential side effects or error conditions. For a query tool with two optional parameters, the description should at least hint at what 'days' and 'limit' do. Incomplete.

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 0%, so the description must explain the parameters. It mentions neither 'days' nor 'limit' nor their meaning. The agent is left to guess what 'days' controls (likely a time window for consolidation) and what 'limit' does (max results). This is a significant gap.

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 defines the tool as a consolidation queue listing working-tier memories not yet promoted, oldest-first. It distinguishes itself from siblings like promote and recall by focusing on the queue of candidates for promotion, and contrasts with in-conversation judgment.

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?

Explicitly says to call at session end or start, and gives a suggested flow: recall the queue, evaluate, promote durable ones, and let the rest stay. It also contrasts with relying on in-conversation judgment, which is measurably unreliable. This gives clear when-to-use guidance and differentiates from ad-hoc memory management.

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?

With no annotations, the description carries the full burden. It discloses significant side effects: removal of unsupported anchors/canon, atomic invalidation of dependent narratives, and the fact that `pin()` will require independent corroboration afterward. It also states that `reason` is required and logged. These are important behavioral traits beyond what a schema would convey.

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 concise (three sentences) and front-loaded with the primary purpose. It efficiently covers side effects and constraints without unnecessary fluff. It earns a 4 for being appropriately sized and structured.

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 complexity (side effects, interaction with `pin()`), no output schema, and no annotations, the description is reasonably complete for an agent to invoke correctly. However, it omits details such as the return value, error conditions, and how to obtain a valid `memory_id`. These gaps make it less than fully complete.

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 0%, so the description must compensate for parameter meaning. It explains `reason` ('required and logged'), but it does not describe `memory_id` at all beyond the tool's general purpose of marking an existing memory. The agent must infer that `memory_id` identifies the memory, but no format or acquisition method is given. This is a notable gap given the lack of schema descriptions.

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 ('mark'), a resource ('existing memory'), and a clear purpose ('as security-sensitive'), with examples of content types (identity / permissions / standing-instruction content). It clearly distinguishes this from siblings like `pin()` and `promote` by focusing on retroactive sensitivity marking.

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 use case (retroactively marking sensitive memories) but does not explicitly mention when not to use it or alternatives. It does provide some contextual guidance by noting that `pin()` will require independent corroboration after flagging, which helps the agent understand downstream effects, but there is no explicit comparison to sibling 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?

With no annotations, the description carries the full disclosure burden, and it delivers: content is tombstoned rather than destroyed, visibility disappears from recall() and list_anchors(), the reason is persisted, and a required predecessor (unpin) is named. This goes well beyond a simple mutation warning.

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?

Four short sentences, each carrying distinct information: purpose, retention semantics, reason requirement, and unpin prerequisite. The most important constraints are front-loaded in the second sentence rather than buried.

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 two-parameter mutation with no output schema, the description covers the core behavioral contract and prerequisite. It omits edge-case behavior (unknown memory_id, whether tombstone is restorable), but those gaps are minor given the strong core disclosure.

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 0%, so the description must compensate. It adds real meaning to reason (required/logged/accountable), but memory_id is only indirectly implied as the identifier of the memory to forget; no guidance is given on where it comes from or its format.

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 opening sentence names a concrete verb and resource ('Deliberately forget a memory') and immediately distinguishes the operation from a hard delete by describing tombstone retention. The effect on recall() and list_anchors() makes it unambiguous which behavior is being invoked.

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?

States a clear precondition (anchored memories must be unpin()-ed first) and clarifies that reason is mandatory and auditable. It does not explicitly contrast against sibling tools like restore or remember, but the 'not a hard delete' line provides a useful exclusion.

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?

With no annotations provided, the description fully carries the behavioral disclosure burden. It discloses that the previous narrative is marked superseded rather than deleted, that source invalidation hides the account until review_narrative(), that unlinked accounts are labeled unverified, and that security_sensitive can be set automatically by injection patterns. This is rich and non-obvious 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.

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

The description is long and dense, but the complexity of the tool justifies the length. It front-loads the core purpose and workflow, then clarifies parameters, cadence, lifecycle, and security. While readable, it could benefit from tighter paragraph breaks or bullet-like separation for the many conditionals.

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 9-parameter mutation tool with no annotations and no output schema, this description is remarkably complete. It covers prerequisites, cadence, parameter meanings, validation rules, sensitivity handling, supersession behavior, and invalidation paths. An agent has enough to call the tool correctly and anticipate side effects.

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 0%, so the description must define the parameters, and it does so for all nine. It explains scope's default and version chain, perspective and coverage semantics, claim/link requirements, memory_ids as optional provenance, reason as required justification, and security_sensitive conditions. This goes far beyond the bare 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 specific verb and resource: "Submit the current narrative synthesis." It clearly distinguishes the tool from recall() by explaining that this tool does not write the narrative for you but accepts the synthesis you compose, which also implies a division of labor versus sibling tools like current_narrative or remember.

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 explicit usage cadence: call periodically rather than every turn, and read recall() first before composing. It explains when not to use it ("narrating too often defeats the purpose") but does not explicitly name alternative tools for reading or editing, so it stops short of full exclusion guidance.

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?

With no annotations, the description carries the full burden, and it is thorough: it explains the anchor's recall behavior, the warning on exceeding a soft limit, the PermissionError if corroboration is missing, and the prompt-injection rationale. No contradiction with annotations exists.

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 longer than average but every section adds needed operational context: purpose, precondition, warning, and security requirement. It is front-loaded and logically organized, with no filler.

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?

Covers what the tool does, when it can be called, required dependencies, potential warnings, and an error condition. It does not specify the success return shape or quantify the 'soft limit', but this is a minor gap given no output schema exists.

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 0%, so the description compensates by explaining reason as a required declaration rather than an inference. memory_id is only minimally described, but its meaning as the identifier of an existing consolidated memory is clear from context.

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?

Clearly states a specific operation ('Mark a memory as an anchor'), identifies the resource (a consolidated memory), and explains the behavioral effect (always surfaced on recall, not ranked by recency or relevance). This differentiates it from generic recall/remember tools.

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?

Gives explicit preconditions: the memory must already be consolidated and promote() called first, and passing remarks are explicitly excluded. It also specifies the security-sensitive condition requiring corroborate(). It does not, however, name sibling alternatives such as unpin or flag_sensitive, so some routing is left to the agent.

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?

With no annotations, the description carries the full burden. It usefully discloses that the action is deliberate and auditable and that the reason becomes part of the audit log. It does not state whether the original working memory is deleted, whether the operation is reversible, or whether any permissions are required.

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, front-loaded with the core action and followed by the key behavioral caveat. Every sentence earns its place and there is no filler.

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 tool this is close to sufficient: the operation, required arguments, and audit consequence are covered. It is incomplete because the side effect on the working-memory record and the result of promotion are not described, and no annotations or output schema fill that 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 coverage is 0%, so the description must compensate. It adds meaning to `reason` by saying it becomes part of the audit log, but `memory_id` is only explained by its name and the description gives no format or provenance guidance.

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 opens with a specific verb+resource pair: 'Consolidate a working memory into long-term memory.' This states exactly what the tool does and distinguishes it from related memory operations like remember, forget, and restore, even without naming them.

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 (a deliberate consolidation decision) and explicitly excludes using it as an automatic 'similarity/importance score threshold.' However, it never names alternatives or says when to prefer due_for_consolidation, remember, or forget, so the routing guidance is only 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?

No annotations are present, so the description carries the full behavioral burden. It explicitly declares 'Read-only', states that 'historical testimony is preserved', reveals a warning behavior for insufficient support, and discloses a semantic limitation of source labels. This is unusually transparent.

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?

Three compact sentences with the action verb front-loaded. Each sentence adds a distinct piece of information: what the tool inspects, its non-destructive behavior, and an important interpretation caveat. No filler.

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 one-parameter read-only tool with no output schema, the description covers purpose, safety, warning behavior, and a key interpretation pitfall. It is slightly incomplete only in not describing the exact return shape or what 'stable identifiers' refers to, but these are minor for 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?

The input schema provides only name and type with 0% description coverage. The description does not directly define memory_id, but the tool context makes clear that it identifies the memory whose recorded sources are being inspected. This adds enough framing to avoid misuse, though format or identifier source is not specified.

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, 'Inspect', and a specific resource: 'recorded sources and the independent-corroboration gate'. This is concrete and tool-specific, and the 'Read-only' qualifier distinguishes it from mutation-oriented siblings like corroborate and promote.

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 this tool is for checking a memory's recorded sources or corroboration status, but it never explicitly says when to use it instead of siblings like audit_log or corroborate. The caveat about stable identifiers is interpretational guidance after the fact, not tool-selection guidance.

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?

With no annotations, the description carries the full disclosure burden and does so thoroughly: it reveals the priority ordering, the limit exception for anchors, the distinction between consolidated and working memories, and the exact nature of narrative_review as content-free. It also discloses the conflict condition and frame-relative scoping, giving agents an unusually complete behavioral model.

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 long but every clause earns its place: ordering rules, return-field semantics, and the frame restriction are all behaviorally necessary. Key behavior is front-loaded in the opening sentence, and the content-free nature of narrative_review is stated directly rather than left for the agent to infer.

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 memory tool with no annotations and no output schema, this description is highly complete: it covers all input parameters, the memory-selection priority, all notable return fields, and edge cases such as 'even above the limit' and 'always returned regardless'. No obvious gate or consequence an agent needs to call 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?

Input schema has 0% description coverage, so the description must explain all three parameters and it does. Limit is defined by the shared-limit and anchor-exception semantics, query is defined by ordering behavior, and frame is defined by what it restricts and what it never restricts.

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 ('Recall memories within a shared limit') and details the retrieval/return behavior with anchors, canon, ordinary memories, and narrative fields. It distinguishes recall from a plain search by describing its composite output, but it never names a sibling alternative (e.g., search or current_narrative) to make the boundary explicit.

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 clear internal usage context for the query parameter (lexical ranking vs. consolidated/working prioritization) and for frame (only restricts ordinary memories, never anchors/canon). However, it does not say when to prefer recall over sibling tools such as search, current_narrative, or narrate, so routing among alternatives is left implicit.

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?

With no annotations, the description carries full burden and excels: explains recency competition, default tier behavior, rejection of testimony, security_sensitive implications for pinning, and the frame disagreement mechanism. Also states 'None of these establish truth' to clarify epistemological status. No contradictions.

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

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

Though long, every sentence adds value. It front-loads the core purpose, then systematically explains optional fields and behaviors. Paragraphs are logically organized by topic (tier, security, frame). No fluff or repetition – appropriate density for an 11-parameter tool.

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?

Extremely thorough for a complex tool with no annotations or output schema. Covers purpose, parameter semantics, behavioral nuances, and relationships to other tools. Missing only the 'source' parameter explanation and any mention of return values or error conditions, which are minor given the storage-focused nature.

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 0%, so the description must explain all parameters. It does explain most: tier, frame, event_at, session_id, session_position, material_type, origin_id, capture_context, security_sensitive, and content is obvious. However, 'source' is present in the schema but completely absent from the description – a notable gap for a parameter that likely carries provenance information.

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 'Store a new working memory' – a specific verb and resource. It further differentiates from siblings by explaining what working memory is (unconsolidated, recency-based) and referencing related tools like corroborate, pin, and mark_conflict, 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.

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

Provides explicit when-to-use guidance: tier='interpretation' for agent's own inferences, rejection of direct 'testimony' capture with instruction to use corroborate() instead, and the security_sensitive flag's implications for future pin(). Also references mark_conflict() for frame disagreements, clearly routing agents to 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?

This tool has no annotations, so the description carries the full burden of disclosing behavior. It notes that forgetting is a tombstone and that restoration is always possible, which is useful. It also mentions that `reason` is required and logged, which is a form of audit behavior. However, it does not mention any side effects, such as whether restoring a memory resurrects it in full, or any consequences for related data. The 'logged' detail adds some transparency, but the depth is limited.

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 short, two-sentence paragraph that is front-loaded with the core purpose ('Reverse a forgetting decision'). Every sentence adds value: the first states the action and possibility, the second explains the rationale for always being possible and the requirement of `reason`. No fluff.

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 fairly complete for a simple restore operation. It explains the core behavior and the logging requirement. However, it does not specify the return value (though there is no output schema, so it might be acceptable), nor does it mention any potential side effects or conditions under which restoration might fail (e.g., if the memory has been permanently purged despite the tombstone note). Given the low complexity (2 params) and no output schema, it is reasonably complete but leaves some gaps.

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 has 0% coverage, so the description is the only source of parameter guidance. It explains that `reason` is required and logged, which adds meaning to that parameter, but it does not provide any guidance on `memory_id` beyond what the schema gives (title 'Memory Id'). Since 0% coverage, the description should compensate more, but it does somewhat for `reason`.

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 the tool reverses a forgetting decision, which is a clear verb and resource ('reverse forgetting'). It is distinguished from sibling 'forget' by explicitly positioning itself as the inverse operation, though it does not name the sibling directly. The tombstone vs delete detail adds specificity.

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 clarifies when to use this tool: after a forgetting decision, to reverse it. It notes that it is 'always possible' because forgetting is a tombstone, not a delete, which implies a key context and contrasts with a delete operation. However, it does not explicitly state when not to use it or mention 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?

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does this thoroughly. It reveals mode internals (cosine similarity vs. hybrid rank combination), preservation of recall's priorities and filters, the limitation that 'Ranking cannot promote evidence', and operational constraints including that 'search itself never downloads models or uses hosted inference'. This is far beyond a typical minimal description.

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 compact and front-loaded with the main purpose, then gives essential behavioral and operational details. Every sentence contributes value, though the middle section is a dense block of clauses that could be slightly better structured with bullet points or clearer separation between features and prerequisites.

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 search tool with four parameters and no output schema, the description provides enough operational context to invoke it correctly: mode behavior, preserved filter rules, ranking constraints, and prerequisites. The main gap is that it does not describe the return shape or how results are ordered, which would be useful since no output schema exists.

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 0%, so the description must compensate for the schema's lack of parameter documentation. It adds real meaning to 'mode' by explaining 'semantic' and 'hybrid', and it references the 'global limit' and 'frame filter', giving context to 'limit' and 'frame'. The 'query' parameter itself is self-evident. Coverage is strong but does not exhaustively document every parameter's allowed values or formats.

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 with a specific verb and resource: 'Find paraphrased evidence'. It also names the core search mode distinction, which helps distinguish it from a plain lexical recall. However, it does not explicitly differentiate itself from sibling tools like 'recall', relying on implication rather than naming alternatives.

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 paraphrased/semantic evidence search and explicitly mentions prerequisites ('Requires the semantic extra and explicit model download beforehand'). It does not clearly state when to use this tool versus alternatives such as 'recall', nor does it provide exclusions or when-not-to-use conditions, leaving the selection logic partially inferred.

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?

With no annotations, the description carries the full behavioral burden and does so thoroughly. It explains audit logging, how omitted/None reasons are handled, the unpin_noop outcome for no-op calls, and the precise meaning of `unpinned: true`. This is rich, honest behavioral disclosure beyond 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?

The description is concise and front-loaded with the core action, followed by tightly packed behavioral details. Every sentence contributes meaningful information without redundancy or filler.

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 two-parameter tool with no output schema and no annotations, the description is remarkably complete. It covers the main action, reason semantics, idempotent no-op behavior, audit handling, and response-field interpretation, leaving little ambiguity for an agent deciding to call and interpret 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 0%, so the description must compensate. It does an excellent job explaining the `reason` parameter, including nullability, compatibility, and audit implications. The `memory_id` parameter is not explicitly described, but its meaning is strongly implied by the tool name and the mention of unknown IDs, making the gap minor.

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 opens with a specific verb and resource: 'Remove anchor status' clearly identifies what unpin does. It also distinguishes itself from sibling tools by stating it preserves the memory, which separates it from destructive tools like forget, and the audit behavior sets it apart from simple state mutations.

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 clear context: unpin is for removing anchor status while preserving the memory, implying when it should be used versus deleting/forgetting the memory. It also covers idempotent use on already-unpinned or unknown IDs. However, it does not explicitly name alternatives or provide 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.