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

Annotations already declare write semantics, non-open-world, and idempotence; the description adds genuinely new behavioral detail by stating the authorization model and that exact normalized active duplicates return the existing ID without altering evidence. That duplicate-handling nuance goes beyond the bare idempotentHint and is exactly what an agent needs before calling.

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 tight sentences with the core action front-loaded and constraints following in order of importance; no filler. Slightly dense phrasing but every sentence carries information.

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 the essential write/auth behavioral profile and duplicate semantics, which is the most important gap to close given annotations only partially cover behavior. Still leaves the parameter contract largely unexplained with no output schema to fall back on, so an agent cannot fully infer how to construct 'evidence' or what 'reason' is for.

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% and four parameters are undocumented in the schema, yet the description only clarifies that evidence is required and implies the project/global scope split. It says nothing about 'text', 'reason', or the array shape/limits of evidence, so it does not compensate for the coverage 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?

States a specific verb+resource ('Save a concise reusable memory') plus the evidence requirement, which is clearly distinct from read-oriented siblings like memory_search and memory_get. However, it never names an alternative (e.g., memory_supersede) for cases where an existing memory should be replaced, so differentiation is implied rather than 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?

Gives real prerequisites ('requires launch-authorized writes; global writes need separate permission') and hints at dedup behavior, which is useful context for choosing this tool. But it never says when to use memory_add versus memory_supersede or memory_archive, so 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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description nonetheless adds genuinely non-derivable context: that content and history are preserved despite the destructive hint, and that launch-authorized write permission is required. It stops short of describing effects on other queries or reversibility of the archival.

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 behavioral crux ('without deleting its content or history') front-loaded. Nothing to trim.

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 mutation is safety-covered by annotations and the non-deletion guarantee is stated, but with a 0%-coverage schema and no output schema, the description leaves both parameters unexplained. Marginally adequate for a two-param tool, but an agent still guesses what to pass for 'reason'.

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% and the description explains neither parameter. It is unclear whether 'id' is the memory id and what 'reason' is used for, so the description fails to compensate for a fully undocumented two-parameter 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?

States a specific verb ('Exclude') and resource ('a memory') plus a clarifying scope ('from future searches without deleting its content or history'). It implicitly separates itself from destructive deletes, but never names a sibling tool, so the differentiation is only partial.

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 one concrete prerequisite ('Requires launch-authorized writes'), which is real usage guidance, but says nothing about when to prefer this over memory_supersede or memory_feedback, nor any exclusion conditions. Usage is implied rather than directed.

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?

Adds meaningful context beyond annotations: "append-only" indicates the report accumulates rather than overwrites, and "Submit once per assessment; retries add reports" discloses the non-idempotent behavior and warns against retrying. This reinforces the idempotentHint=false annotation with concrete operational meaning.

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 earning its place: purpose, no task ID needed, append-only clarification, and the one-report-per-assessment warning. Front-loaded and free of 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 non-mutating assessment tool with three simple parameters and no output schema, the description is sufficient: it defines the verdict space, clarifies the append-only nature, and warns against retry. Missing only an explicit statement of what happens to the memory after feedback, but the append-only note covers the essential behavior.

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 carry the load, but it only partially compensates. It describes the verdict semantics implicitly (the four categories) but never explains what memory_id refers to beyond its name, or what the optional reason field is for. Baseline 3 is appropriate given the top-level description covers the verdict but leaves other params thin.

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+resource (report feedback on a memory) and enumerates the exact verdict values, which differentiates it from siblings like memory_add or memory_archive that mutate memory state. The "not automatic verification or permission to modify the memory" clause sharpens the boundary.

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?

Clarifies that no task ID is needed and that feedback is an append-only assessment rather than a modification or verification action, which routes the agent away from mutation tools. It does not explicitly name alternative tools to use for correcting or archiving a memory, so it falls just short of 5.

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 declare readOnlyHint=false and idempotentHint=false, and the description supplies the reason ('Records a delivery'), which is exactly the non-obvious side effect that would otherwise look contradictory for a read tool. It also notes archived memories remain inspectable, useful state information beyond the annotations.

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

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

Two dense sentences with no filler; the primary action is front-loaded and the side effect and archive note are appended. Efficient for the amount of content carried.

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 no output schema, the description usefully enumerates what is returned (evidence, statistics, recent history/feedback) and covers the notable edge case of archived records. The main remaining gap is failure behavior for an inaccessible or nonexistent ID.

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% and the single parameter has no description in the schema. The description only adds 'integer ID' and the constraint that the memory must be accessible, which is marginal detail beyond the schema's type and exclusiveMinimum=0.

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 (Read) and resource (memory) with the keying mechanism (integer ID), which cleanly separates it from memory_search. It does not explicitly name a sibling alternative, but the ID-based selector makes the distinction inferable.

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 already hold a memory ID. There is no explicit when-to-use/when-not guidance and no named alternative for cases where only a query is available (memory_search), leaving the agent to infer the 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 flag readOnlyHint=false, and the description explains the side effect ('records deliveries'), which is valuable additive context. It also discloses the untrusted-data safety stance and a semantic-to-keyword fallback on failure, covering behavior the annotations do not.

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, front-loaded sentences with the core action first and no filler. The security note and fallback note are dense but each adds distinct information.

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 no output schema and 0% param coverage, the description should round out the picture more. It gestures at return shape ('bounded results') and ordering of deliveries but leaves result format, pagination, and parameter specifics underspecified.

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 carries the full burden. It partially compensates by implying the scope values ('current-project/global') and the result bound ('bounded results') for limit, but gives no detail on query semantics, defaults, or ranges.

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+resource ('Search ... memories') and narrows scope to 'active current-project/global' memories. However, it does not name or distinguish itself from sibling memory_get or memory_feedback, so the agent must infer the boundary.

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 statement of when to use this versus memory_get (single fetch) or memory_feedback, and no prerequisites or exclusions. Usage is only weakly implied by the word 'Search'.

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 destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior: the operation is atomic (replace-vs-two-calls distinction), requires launch-authorized writes, and the replacement resets retrieval/feedback statistics. Only missing piece is failure/rollback semantics if the atomic step fails.

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 short sentences, front-loaded with the core action, then the precondition, then the side effect. Every sentence adds information; nothing is redundant.

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 destructive, non-idempotent mutation with no output schema, the description covers atomicity, authorization, and stat reset, which is solid. But with 0% schema description coverage it leaves the required evidence array and reason parameter undocumented, and says nothing about what the caller receives or whether the archived memory is recoverable.

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 carry parameter meaning, and it does not. 'active memory' loosely maps to id and 'corrected replacement' to text, but evidence (1-5 items required) and reason are entirely unexplained in both the description and 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?

States a precise compound verb ('atomically archive ... and create its corrected replacement') plus resource and scope ('same scope'). This clearly separates it from siblings memory_archive (archive only) and memory_add (create only), so an agent can pick it without opening a 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 precondition 'Requires launch-authorized writes' gives real context, and 'corrected replacement' implies it is for correcting an existing memory. However, it never says when to prefer this over memory_archive + memory_add or how it relates to memory_feedback, leaving the alternative-selection logic to inference.

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