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

Annotations declare readOnlyHint=true and openWorldHint=false, and the description goes well beyond that. It explains the exact semantics of max_chars (bounds serialized array, not wrapper), how omitted records are reported (omitted_from_page vs returned_after_budget vs retrieval.returned), and the behavior of compact view (never truncates body, never invents provenance, preserves source_summary details). No contradictions with annotations.

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

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

The description is dense yet well-structured: purpose first, then max_chars semantics, view behavior, source_summary note, and a usage recommendation. Every sentence adds essential information with no fluff. It front-loads the primary purpose and keeps related details grouped logically.

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 tool with a nested selection parameter, the description covers the key behavioral aspects: budget semantics, view differences, and the relationship with memory_history. It explains the response fields (omitted_from_page, returned_after_budget, retrieval.returned) sufficiently for an agent to interpret results correctly. The suggested startup read provides a practical entry point. No obvious gaps 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 0%, so the description must compensate. It does for the key parameters: max_chars (explains exactly what it bounds and how records are dropped) and view (explains full vs compact and what compact includes/excludes). It also gives a recommended value for limit. It doesn't elaborate on the selection object's fields, but that's detailed in the schema, and the description's core purpose is clear.

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 purpose: retrieving bounded reference memories for the current task with scope and validity constraints. It clearly differentiates from memory_history by naming it as the alternative for full evidence, and the view options (full vs compact) further distinguish its behavior from other memory 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?

Explicit guidance is given: when full evidence is needed, use memory_history instead. It also provides a concrete recommended startup read (view='compact', max_chars=6000, limit=8) and explains the trade-offs between full and compact views, making it clear when to choose each.

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?

Even though annotations already show destructiveHint=true and readOnlyHint=false, the description adds crucial non-obvious behavior: the deletion is soft, retrieval-only scope, history and database content are retained, and there is a revision-based precondition. This significantly goes beyond the structured 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 short sentences with no filler: the core operation is front-loaded, and the two caveats (not secure erasure, read revision first) are each essential. Every sentence carries load.

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 two-parameter mutation without an output schema, the description covers the operation, retention behavior, and the required revision workflow. It stops short of describing the result/return value or what happens on a revision mismatch, but those are minor for this low-complexity 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?

With 0% schema description coverage, the description compensates for expected_revision by explaining that the current revision must be read from history before calling the tool, linking it to the parameter. It doesn't explicitly restate memory_id, but the name plus 'one memory' is self-explanatory; the marginal gap prevents a 5.

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 action, 'Soft-delete one memory from retrieval,' which clearly names the verb and resource. The explicit distinction from secure erasure ('This is NOT secure erasure') differentiates it from any hard-delete variant and from sibling update/search 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?

It gives a clear prerequisite: read the current revision via history before forgetting, which tells the agent the correct sequencing. The 'NOT secure erasure' warning provides an explicit when-not-to-use condition, though it does not name alternative tools (e.g., memory_update) for other intents.

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 openWorldHint=false, so the safety profile is covered. The description adds behavioral detail beyond annotations: results are ordered newest first, forgotten memories are included, and pagination is supported. This gives the agent useful invocation 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 a single front-loaded sentence with no wasted words. It packs the action, resource, ordering, special inclusion, and pagination support into a compact form.

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 tool with one required parameter and no output schema, the description provides the key invocation facts: revision snapshots, newest-first order, forgotten-memory inclusion, and pagination. It could clarify what 'revision snapshot' means or describe the response shape, but those are not essential for calling 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 coverage is 0%, so the description must carry semantic weight. It only mentions pagination, which clarifies limit/offset at a high level but does not explain memory_id or the meaning of offset/limit values. The parameter names and defaults are self-evident enough to make a reasonable call, but the description does not fully compensate for the missing 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 ('Read') and resource ('revision snapshots'), and adds ordering ('newest first') and scope ('including forgotten memories'). This clearly distinguishes memory_history from siblings like memory_search, memory_context, and memory_status.

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 is the tool for browsing historical revisions and forgotten memories, but it never explicitly says when to choose it over memory_search or memory_context. Pagination hints at large result sets, yet no alternative tools or exclusions are mentioned.

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 only declare readOnlyHint=true and openWorldHint=false. The description goes far beyond this by disclosing: forgotten records are always excluded, as_of filters validity not historical revisions, relaxed mode rewrites confidence never, candidate_pool is a floor when candidate_limit_reached, and empty results are valid answers. It also explains the retrieval object's reason field values, which is critical for interpreting results.

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 information-dense and front-loaded with the core purpose, but it is quite long and somewhat sprawling. The relaxed-mode explanation is thorough but could be tightened. Every sentence earns its place in terms of content, but the structure could be improved with clearer paragraph breaks or bullet-like separation. It's not concise, but it's not padded either.

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 complex search tool with 11 parameters, no output schema, and nuanced fallback behavior, the description is remarkably complete. It covers the retrieval object, reason values, candidate pools, per-query counts, fallback mechanics, and edge cases like empty queries and pagination overflow. An agent has everything needed to invoke this tool correctly and interpret its results.

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 carries the full burden. It explains query semantics (plain text, all terms must match, not SQL/FTS syntax), query_variants constraints (max 5, max 100 chars, RRF scoring formula), search_mode behavior, scope/include_global behavior, and as_of semantics. It doesn't explicitly walk through every parameter like limit/offset, but those are self-evident from the schema. The description adds substantial meaning beyond the raw 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 opens with a specific verb and resource ('Search active memories with FTS5') and immediately distinguishes scope behavior ('Default global only; project/domain may include global'). It clearly differentiates from siblings like memory_store, memory_forget, and memory_history by focusing on search/retrieval semantics.

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 explicitly explains when to use strict vs auto search_mode, how query_variants work, when relaxed fallback triggers, and what filters always apply. It also clarifies that this is lexical keyword fusion, NOT vector/semantic search, which prevents misuse. It gives concrete guidance on pagination and offset behavior.

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?

Beyond the readOnlyHint=true annotation, the description explains the meaning of active_count versus total_count and how they relate to retrieval semantics (validation at as_of, including forgotten and expired records). This gives the agent genuinely useful behavioral context about how the data in the report should be interpreted.

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 an excellent front-loaded summary maps directly to the tool name. The added detail about scopes is useful, though the phrase 'kept as separate fields' is slightly redundant and the paragraph could be trimmed without losing meaning.

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 carries the burden of explaining what the agent can expect: location, counts, schema, capabilities, and a detailed account of the scopes sub-structure. For a zero-parameter status tool, this is complete enough for an agent to invoke and interpret the result 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?

The tool has zero parameters and schema coverage is 100%, so there is nothing meaningful to add about parameter behavior. The baseline of 4 applies; the description appropriately spends no space on parameters.

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 ('Report') and a clear resource ('database location, counts, scope inventory, schema and capabilities'). This immediately distinguishes memory_status from memory_search, memory_store, and other siblings because it is about inspecting the memory system itself rather than operating on 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 gives an explicit when-to-use: 'Check it when the task scope is unclear or changes.' It also warns against over-reading scopes ('knowing that a scope exists is not a reason to read every project'), which prevents misuse. It does not name alternative sibling tools, so it stops short of full 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?

Beyond the annotations, the description discloses important write behavior: persistence, return of id/revision, exact-duplicate suppression, atomic closing of the superseded memory's validity, and scope/scope_id matching requirements. 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 front-loaded with the core action and return value, and every subsequent sentence adds a policy, constraint, or behavioral detail. There is no filler or repetition.

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 write tool with no output schema, the description supplies enough context: preconditions for autonomous writes, prohibited content, search-first requirement, deduplication behavior, and atomic supersede mechanics. Nothing essential to correct invocation 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?

With 0% schema description coverage, the description compensates by adding meaning to source.trigger, supersedes, valid_from, scope, and scope_id. However, it leaves fields like valid_to, confidence, importance, tags, and type to inference or schema defaults/enums, so compensation is strong but not complete.

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 ('Store') and resource ('durable memory with provenance'), and commits to a clear return contract ('Return id and revision'). It also distinguishes the tool from siblings like memory_search and memory_update by describing duplicate suppression and supersede 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?

It gives explicit when-to-use guidance: explicit user requests must be handled, and autonomous writes require confirmed, durable, future-useful information. It also gives clear when-not-to-use guidance by prohibiting secrets, speculation, raw logs, and short-lived details, and instructs the agent to search first and avoid re-inserting duplicates.

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 description discloses behavioral traits beyond annotations: it mentions optimistic concurrency (implying expected_revision is required), a full audit snapshot (indicating every update is logged), and which fields are immutable. Since annotations already flag destructiveHint=true, the description adds concurrency and audit details, enhancing transparency without contradicting 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 two sentences, front-loaded with the core purpose and concurrency/audit traits, followed by a compact bullet list of editable and immutable fields. No redundant phrasing; every sentence 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 a 3-parameter mutation tool with a nested object and no output schema, the description covers all critical aspects: the concurrency mechanism, audit behavior, allowed fields, and when to use a sibling. An agent has everything needed to construct a valid call (memory_id, changes with only editable fields, expected_revision) and to avoid misuse.

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?

With 0% schema coverage, the description fully compensates by listing the editable fields (title, content, type, confidence, importance, source, tags) and explaining that expected_revision is for optimistic concurrency. It also tells the agent which fields to exclude (scope, validity, supersedes), giving clear semantics for the 'changes' object beyond the generic 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 'Correct' with a resource ('content/metadata'), and immediately distinguishes itself from the sibling memory_store by noting that scope, validity, and supersedes are immutable and should be handled there. This makes the tool's role unambiguous: updating/correcting existing memory entries rather than storing new facts.

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 when-to-use and when-not-to-use guidance: it lists editable fields and states that immutable fields (scope, validity, supersedes) require memory_store instead. This directly tells an agent when to select this tool over alternatives, eliminating guesswork.

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