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

With no annotations, the description carries the full burden and does real work: it discloses that the default provider is fully offline (no key, no network), that 'auto'/'laya' semantics differ, that jev requires TYPESAFE_API_KEY, and that failures are fail-safe (content is kept). The dependency and key requirements are exactly the behavioral context an agent cannot get from the schema. It stops short of describing output format or what 'irrelevant' means operationally.

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 core action is front-loaded in the first sentence, followed by compact provider notes. The semicolon-separated provider clauses are dense but readable, and no sentence is wasted, though the provider detail could be tightened.

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 4-parameter tool with no annotations, no output schema, and zero schema description coverage, the description covers provider selection and failure behavior well but omits any explanation of the required text/question semantics or the threshold's effect on filtering. Adequate but 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% across 4 parameters, so the description must compensate. It explains the provider enum options well (mechanical/laya/jev and their requirements), but says nothing about 'text', 'question', or the 'threshold' number and its 0.4 default, leaving half the parameters undocumented.

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 and resource: 'Drop context blocks irrelevant to an objective,' which tells the agent this is a filtering/compaction operation keyed to a question. It does not, however, distinguish itself from the sibling compact_transcript, so an agent must guess which compaction tool applies.

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 never states when to use this tool versus compact_transcript or the other siblings, nor any preconditions for invoking it. The provider paragraph explains operational modes but is not usage-routing guidance, leaving selection entirely to inference.

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 discloses important behavior: kept messages stay verbatim, nothing is summarized, failures preserve the call, and remote `jev` requires `TYPESAFE_API_KEY`. It still omits some behavioral details, such as side effects beyond compaction and return-shape expectations, but overall it is informative.

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 but front-loaded, beginning with the core compaction behavior before provider and failure semantics. Most sentences earn their place, though the single-paragraph style makes it slightly harder to scan for a 20-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?

For a complex 20-parameter tool with no annotations and no output schema, the description covers the main modes and important caveats well. However, it leaves several parameters and the general return shape under-explained, so an agent would still need to inspect the schema for full invocation confidence.

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 only 45%, so the description must compensate. It does add useful meaning for `provider`, `rules_mode`, `ref_blocks`, `ref_unchanged`, `workspace_root`, and `allow_command_pointers`, but leaves many parameters (e.g., `threshold`, `preserve_recent`, `max_state_tokens`, `max_request_tokens`) unexplained.

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 operation on a specific resource: tool-call compaction for a session transcript, with concrete mechanics (pairing calls/results, pinning messages, dropping spent pairs). It is clear enough to distinguish from a generic `compact` tool, though it does not explicitly name any sibling alternative.

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 explains provider selection and defaults, which is useful operational guidance, but it does not say when to use `compact_transcript` instead of siblings such as `compact`, `inspect`, or `prepare`. Usage is implied by the tool name and transcript-specific behavior rather than explicitly framed.

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 burden. It usefully discloses two non-obvious traits — it never re-runs compaction and never touches the network (pure, side-effect-free, offline) — but says nothing about permissions, error behavior, or cost, so the safety profile is only partially covered.

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 tightly written sentences with the purpose front-loaded and no filler. Every clause earns its place, though the second sentence reads as a behavioral caveat rather than structure.

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 four-parameter tool with a nested required object and no annotations or output schema, the description adequately conveys what the tool returns (per-block keep/trim/drop rationale) but leaves the parameters and any validation/failure behavior unexplained. The core purpose is covered; the callable specifics are not.

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% across four parameters (report, only, limit, source_text), so the description must compensate and largely does not. The phrase 'kept, trimmed, or dropped' loosely echoes the keep/trim/drop enum on `only`, but limit, source_text, and the shape of the required nested `report` object are never addressed.

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 ('explain') and resource (a relevance-compaction report), and ties itself to the sibling tool that produces the report ('as produced by compact'). It distinguishes itself from compact by clarifying it does not re-run, though it does not carve out territory against other read-flavored siblings like inspect or recall.

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

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

The description implies usage ('a report ... as produced by compact') but gives no explicit when/when-not or a named alternative to prefer or avoid. The 'Never re-runs' clause hints at the boundary versus compact without stating the selection rule directly.

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 does disclose two meaningful traits: 'Read-only' (no mutation) and 'Offline' (no network dependency). It says nothing about determinism, input size limits, cost, or what the returned recommendation looks like, so a 3 is appropriate.

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

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

A single dense sentence that front-loads the read-only nature and then lists the report contents in order. Every clause carries information; the only minor cost is the telegraphic 'Offline.' fragment at the end.

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?

There is no output schema, and the description correctly compensates by enumerating the returned facets (tokens, structure, duplication, cleanup projection, recommendation). Combined with the read-only/offline disclosure, an agent knows enough to invoke it correctly, though the relationship to the cleanup siblings remains unstated.

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?

One parameter ('text') at 0% schema description coverage, so the schema adds nothing; the description compensates only by saying it inspects 'a text', which is obvious from the parameter name. No format, length, or encoding expectations are given, so it meets the minimum but no more.

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 (diagnostic inspection) and resource (a text), then enumerates exactly what the inspection reports: tokens, structure, duplication, cleanup projection, recommendation. It does not name a sibling to contrast with, but the diagnostic/read-only framing implicitly separates it from mutating siblings like compact or prepare.

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

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

The phrase 'diagnostic inspection ... cleanup projection, and recommendation' implies this is the pre-flight check to run before a cleanup/compaction tool, but the description never states when to use it versus compact, compact_transcript, or prepare, nor any exclusions. Usage is inferable but not spelled out.

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

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

With no annotations, the description carries the full burden. It does disclose one real behavioral trait (offline by default, i.e. no network dependency) and lists the categories of output produced, which is useful since there is no output schema. But it never says how to leave offline mode, whether the call is side-effect free, or whether it is deterministic.

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 tight clauses with no filler; the operation and its output list are front-loaded. The trailing 'Offline by default.' fragment is compact but slightly disconnected from the main clause.

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 2-parameter tool with no output schema and no annotations, the description should at minimum clarify the inputs and what 'readiness'/'intent'/'compiled prompt' mean. Listing output categories helps, but the undocumented question parameter and unelaborated output names leave real 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?

Schema description coverage is 0% and the description never mentions either parameter. 'Raw prompt input' only loosely implies the required text field, and the optional question parameter (default "") is entirely undocumented in both description and 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?

Names a specific operation (intake triage) on a specific resource (raw prompt input) and enumerates the outputs it produces: readiness, intent, clarifying questions, assumptions, compiled prompt. It does not, however, differentiate itself from siblings like prepare, compact, or inspect, so an 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?

There is no statement of when to use this tool versus prepare/inspect/compact, no prerequisites, and no when-not-to-use guidance. 'Offline by default' hints at a mode but does not say how or when to select a different one.

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. It does disclose real traits: deterministic, offline (no network), and it never summarizes or paraphrases, which is a meaningful negative constraint. It does not say whether anything is mutated, whether output is persisted, or what the response contains, so significant gaps remain.

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 clauses, front-loaded with the inspect-first concept and the key constraint ('never summarizes or paraphrases'). No padding or repetition, though the dense jargon costs some readability.

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?

No output schema, no annotations, and 0% parameter coverage, so the description must do more work than it does. It omits what the tool returns, what `question` is for, and how an agent knows whether optimization was 'recommended' — an agent could not call this correctly and predict the result from the definition alone.

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 two parameters. The description's mention of prompt preparation loosely implies `text` is the prompt, but it says nothing at all about `text` format or the `question` parameter, leaving half the interface completely undocumented in both schema and prose.

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

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

The description names a recognizable activity (prompt preparation) and gives a rough pipeline: inspection, then lexical selection plus 'safe optimization' only when recommended. However, 'lexical selection' and 'safe optimization' are undefined jargon, and the name 'prepare' is generic enough that an agent cannot confidently distinguish this from sibling tools like compact or intake without opening the schema.

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

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

'only when recommended' gestures at a precondition but never says who recommends it or how an agent learns the recommendation. There is no explicit when-to-use or when-not-to-use guidance, and none of the siblings (compact, compact_transcript, inspect, intake, recall, explain) are named as alternatives, even though 'runs inspection' overlaps with the sibling `inspect`.

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 does well: it discloses the exactness guarantee (bytes re-hashed on read, so text is exactly what was removed) and the operating constraint (offline, local stash only). It omits error behavior for a missing, expired, or malformed id, which is a meaningful gap for a lookup tool.

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 action before the mechanism and the constraint. Every clause is informative, though the first sentence is dense and jargon-heavy, which slightly reduces scannability.

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, no-output-schema, no-annotation retrieval tool, the description covers what is returned and the key constraints, which is enough for correct invocation. Missing error/expiry handling keeps it from being 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 coverage is 100%, so the schema already documents 'id' (hex id from the pointer) and 'lines' (1-based range 'a-b'). The description adds only indirect context by referencing 'the pointer', and says nothing about what happens when 'lines' is supplied or whether it truncates output. Baseline 3 is appropriate.

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

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

States a specific action (return a previously removed tool output) and ties it to the exact artifact being reversed, including the placeholder marker 'lcc recall <id>'. It names the sibling compact_transcript and its rules_mode 'stashed', which helps distinguish it from compact/compact_transcript. It stops short of a plain 'retrieve contents stashed by X' framing, but an agent can identify it without opening the schema.

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

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

The description embeds the trigger condition: use this when you encounter '[removed: N tokens · lcc recall <id>]' placeholder text. That is clear context for invocation. It does not explicitly contrast with alternatives like inspect or explain, and gives no exclusions beyond the offline/local-only note.

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