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

Annotations declare openWorldHint=true, idempotentHint=true, destructiveHint=false and readOnlyHint=false, so the safety profile is largely covered. The description does add one genuinely useful behavioral note — outputs are 'untrusted evidence' — but it never explains the non-read-only profile or the snapshot refresh/indexing behavior implied by the freshness parameter.

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 verb+resource lead is front-loaded and there is no filler. It is telegraphic semicolon fragments rather than prose, which is dense but occasionally hard to parse.

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 9-parameter tool with no output schema, the description does sketch the report composition, which covers returns. It omits the untrusted-evidence handling implications, the refresh/staleness model, and the heuristic/model-association toggles, so an agent still has 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 100%, so baseline is 3, but the description actually expands the operation enum semantics (hubs = blast radius, surprises = cross-community links, confidence = provenance, community = subsystems), adding meaning beyond the bare enum values.

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 (analyze the selected local graph) and enumerates the report sections it produces, so the agent knows exactly what it gets back. It fails to distinguish itself from the sibling inspect_code_graph, which an agent will have to disambiguate on its own.

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 when-to-use, when-not-to-use, or alternative routing anywhere in the text. The operation list implies what can be requested but never says when this analyzer is preferred over inspect_code_graph or context_brief, leaving selection 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?

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so safety is partly covered. The description adds genuinely useful context beyond annotations — 'revision checking' signals an optimistic-concurrency guard and 'explicit user decision' signals an authorization precondition — but it never says what content is destroyed on replace or how the three-way action/revision/approval interplay resolves.

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

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

A single front-loaded sentence with no redundant restatement of the name or schema, so it is efficient. It is arguably too terse given nine parameters and destructive semantics, but it wastes nothing.

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, nine-parameter mutation with no output schema, the description is far too thin. It does not explain the required combinations (action=approve vs approved=true vs operation=create/replace vs allowDestructiveReplacement), what 'revision checking' does on a stale revision, or what the tool returns, leaving the agent to reconstruct critical call logic from the schema 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 100%, so the nine parameters are already documented in the schema, giving a baseline of 3. The description only loosely maps to the parameters ('decision' → action/approved, 'candidate' → candidateId, 'revision checking' → revision) and adds no syntax, default, or conditional-requirement detail (e.g. when approved/allowDestructiveReplacement must be true).

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 ('apply a user decision to one pending candidate') and scopes the operation to a single candidate, so the agent understands it is a decision-commit tool rather than a listing or review tool. It does not, however, name or contrast itself with sibling review/apply pairs (e.g. context_metadata_apply), so sibling differentiation is only implied.

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 'explicit user decision' implies the precondition that a review is pending and the user has acted, but there is no explicit when-to-use/when-not guidance and no mention of alternatives among the many review/apply siblings. 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive). The description adds real context beyond them: the server 'reads and attests the published decision' and rejects user-authored input, which tells the agent the proof is server-verified. It still omits what a completed vs rejected challenge returns.

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 action front-loaded and the constraint following. No filler, though the phrasing is dense and slightly jargon-heavy.

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 exists, but the description explains the server-side attestation mechanism, which is the key behavioral fact for calling a proof tool. Combined with full schema coverage and annotations, most of what an agent needs is present, though return behavior on failure is 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?

Schema description coverage is 100%, so the schema already documents all five parameters and the baseline is 3. The description's emphasis on 'this exact managed MCP surface' reinforces the exact-match expectation but adds no field-level syntax beyond the schema.

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

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

States a specific verb ('Complete') and resource ('pending guided-activation retrieval challenge'), making it distinguishable from recall/read siblings. It does not name an alternative tool directly, but the object of the action is concrete enough for an agent to identify the operation.

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 ('pending' challenge) rather than explicitly conditional, and there is no explicit when-not or named alternative. The line 'user-authored recall/read JSON is never accepted' weakly separates it from recall_context, but routing guidance is left 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?

Annotations already declare readOnlyHint=false, idempotentHint=true, openWorldHint=true, destructiveHint=false. The description adds two behavioral facts beyond them ('semantic truncation' of output and 'cold indexing is never started'), which is genuine added value, but it never explains why the tool is not read-only or what side effects accompany the non-readOnly hint.

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, purpose front-loaded, no filler. It is terse and efficient, though the density of unexplained jargon slightly undercuts the 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?

This is a complex 10-parameter tool with six modes (brief/locate/explain/trace/impact/resume) and no output schema, yet the description never explains the modes, the token budget behavior, or the overall flow. Even with full schema coverage, the description leaves an agent without enough context to use the tool confidently.

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

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

Schema description coverage is 100%, so all ten parameters (including the mode/detail/responseFormat enums) are already documented in the schema. The description's mention of 'cgs_ not cgr_' merely echoes the schema's codeRefs description and adds no new semantics, so the baseline 3 applies.

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

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

The phrase 'Graph+memory brief with semantic truncation' names a resource but uses a noun ('brief') rather than a clear verb, so the action is ambiguous. Jargon like 'cgs_' and 'cgr_' is opaque, and it does nothing to distinguish itself from close siblings such as recall_context, read_context, or list_context.

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 constrains inputs ('Accepts 8 graph paths/local cgs_; not cgr_') but gives no when-to-use guidance, no when-not-to-use, and no mention of alternatives among the many sibling context tools. An agent cannot infer which of recall_context/read_context/context_brief to pick.

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?

readOnlyHint=true and destructiveHint=false are already declared, but the description earns credit by explicitly stating it never prepares a graph or applies repairs and that it works from current local evidence. This adds useful scope context (no side effects, local snapshot) beyond the raw annotation flags, though pagination behavior and rate/scope limits are unmentioned.

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 issue types, no filler. The second sentence overlaps somewhat with the readOnlyHint annotation, costing a little against full efficiency.

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 six-parameter inspection tool with a 16-value findingCategory enum and no output schema, the description says what it looks for but not what a caller receives or how paging works. Adequate but with clear gaps for an agent needing to interpret 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 100%, so all six parameters including two enums are already documented in the schema. The description adds no filter semantics (kind/topic/findingCategory intersection, or how 'after' resumes a page), so baseline 3 applies.

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

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

The description names a specific verb (Inspect) and resource scope (one project's context for stale, conflicting, duplicate, or invalid issues), which is concrete. It implicitly differentiates from context_health_aggregate via 'one project' and from the repair siblings via 'never...applies repairs', but never names those siblings explicitly, so a reader must infer the routing.

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 'never prepares a graph or applies repairs' tells the agent a negative condition (don't use this to fix things), which is useful routing guidance. However, no alternative tool is named and there is no positive statement of when this is the right call versus recall_context, list_context, or context_health_aggregate.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true; the description adds real value by explicitly negating side effects ('never fetches, syncs, writes, or prepares a graph'), which disambiguates the misleading openWorldHint. It stops short of describing result shape or cost/latency characteristics for aggregating up to 32 teams.

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 core purpose front-loaded and no filler. The negative-capability sentence is long but each clause (no fetch, sync, write, graph prep) carries 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, the description is the only place return structure could be conveyed, yet it says nothing about what the aggregate produces (e.g., per-team breakdown vs combined score). Safety and scope are covered, but an agent cannot anticipate 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 100%, so the schema already documents all three parameters; the description's only parameter content ('omit team for every configured team') duplicates the schema's own wording. It also leaves unaddressed the schema's 'Required' labels on project and callerCwd against a reported zero required parameters, adding no clarity there.

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 specific verb (Aggregate) and composite resource (personal context health across configured local Git team snapshots), so an agent knows this is a multi-team roll-up rather than a single-context read. It does not explicitly contrast itself with the sibling context_health, which is the closest alternative, so sibling differentiation is only implied.

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 one concrete selection rule ('Omit team to select every configured team'), which tells the agent how to broaden the scope. However, it never says when to prefer this over context_health or context_health_schedule, so the agent must infer that aggregation across teams is the deciding condition.

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, idempotentHint=false and readOnlyHint=false, so safety is covered. The description adds value beyond them by defining the approval gate and, crucially, the blast radius ('shared and review-only proposals are never mutated'), telling the agent what will not be touched.

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 sentences with no filler; the approval prerequisite is front-loaded and the safety scoping follows immediately.

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 supplies the approval gate, input provenance and mutation scope. Minor gaps remain (no mention of rollback, failure behavior, or rate limits), but nothing essential to a 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?

Schema description coverage is 100%, so every parameter is already documented, including that proposalId/revision come from context_health_repair_preview. The description restates that provenance rather than adding syntax or constraints, so the baseline of 3 is appropriate.

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

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

States a specific verb (Apply) plus resource (one exact personal-memory repair) and scope ('one exact'), which separates it cleanly from the sibling context_health_repair_preview that produces proposals. An agent can tell this is the mutation step 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?

Gives a clear precondition ('after explicit approval') and a hard exclusion ('shared and review-only proposals are never mutated'), and points at the preview step for the required inputs. It stops short of naming the alternative tool by its full ID or spelling out the not-yet-approved case, so it is strong but not exhaustive.

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

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

Annotations already cover the safety profile (readOnly, non-destructive), so the bar is lower, and the description usefully adds that repairs are 'bounded' and 'exact' and that the semantic-supersede path is gated on fields sourced from a prior preview. It stops short of describing what the preview returns or how paging interacts.

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 zero filler; the core purpose is front-loaded and the conditional requirement follows. Nothing is redundant against the schema or annotations.

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

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

The description captures the trickiest conditional (semantic supersede inputs) for a 10-parameter tool, and the schema covers parameters fully. But with no output schema, it never explains what a preview actually returns, and it leaves the 'after' cursor/paging behavior and kind/topic/category intersection to the schema.

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

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

With 100% schema coverage the baseline is 3, and the description goes beyond it by explaining that the four semantic-direction fields must be supplied together and originate from a prior preview. That clarifies the all-or-nothing relationship the per-field schema notes only hint at.

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 — 'Preview bounded, exact context-health repairs' — which clearly opposes the sibling context_health_repair_apply (preview vs apply). It doesn't name that sibling explicitly, but the preview/apply contrast is inferable from the name and description.

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 one real precondition: semantic supersede suggestions require an explicit contradiction ID, report revision, stale URI and current URI from a prior preview. However, it offers no broader when-to-use guidance, no when-not, and does not name the apply step or alternatives, so usage 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 readOnlyHint=true and destructiveHint=false, but the description adds genuinely new behavioral facts: the plan is network-disabled and provider-neutral, and it does not install a schedule. That last point is the key non-obvious guarantee for an agent deciding whether this has side effects.

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 sentences with the core purpose front-loaded and the safety/scope caveat immediately after. No filler, no repetition of the tool name.

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 render tool with full schema coverage and annotations covering the safety profile, the description is nearly sufficient. The only gap is that, with no output schema, it does not hint at the shape of the rendered 'contract' an agent will receive.

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

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

Schema description coverage is 100%, so team, project, and cadenceMinutes are already documented with their constraints (5-43200, omit team for all teams). The description adds no parameter-level detail beyond that, so the baseline 3 applies.

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

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

States a specific verb (Render) and resource (scheduled invocation contract) scoped to local context health aggregation, and the closing clause ('does not install a schedule') distinguishes it from an install/apply action. It stops short of naming the sibling it complements (e.g. context_health_aggregate), 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?

The description conveys that this is a render/preview step rather than an install step, which implies when to reach for it, but gives no explicit when-to-use rule or comparison against the other context_health_* siblings. Usage must be inferred from 'the plan is read-only... it does not install a schedule.'

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, idempotentHint=true and readOnlyHint=false, so the bar is lower; the description still adds real value by disclosing the compare-and-swap concurrency model and the fail-closed behavior when memories are shared or have changed since preview. It does not say what a failed or partial apply returns, but the key safety-critical invariant is present.

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 with no filler; the precondition ('explicitly approved previewed') is front-loaded before the failure mode. Every clause 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 12-parameter, destructive, open-world mutation with no output schema, the description covers the essential precondition, the concurrency guard, and the failure semantics. Remaining gaps — return shape on partial failure and explicit sibling routing — are minor against a fully documented schema.

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

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

Schema description coverage is 100% across all 12 parameters (revision, proposalId, expectedContentHash, clear* exclusivity rules), so the schema carries the semantics. The description only reinforces the 'explicitly approved' gating on the approved flag and adds no syntax or format detail beyond the schema.

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

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

States a specific verb+resource: applying one metadata proposal, with the qualifiers 'explicitly approved' and 'previewed' narrowing scope. The CAS framing and the preview/apply pairing make it distinguishable from siblings, though the description never names context_metadata_preview as the counterpart and 'CAS' is left undefined jargon.

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?

'one explicitly approved previewed metadata proposal' establishes a clear prerequisite workflow — a preview must exist and be approved before this call — which implicitly routes the agent away from ad-hoc direct application. It stops short of explicitly naming the alternative tool or stating when not to use this 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful scoping ('metadata-only', 'one active personal durable memory') and confirms 'No write occurs', but says nothing about validation behavior or what a preview returns — notable given there is no output schema.

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

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

Two short sentences, front-loaded with the action and the scope, with zero filler. Every phrase earns its place.

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

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

For an 8-parameter, zero-required tool with no output schema, the description states what it does but omits the return shape of a preview and the relationship to context_metadata_apply. Adequate but with clear gaps an agent would have to infer.

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

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

Schema description coverage is 100% and each of the 8 parameters is documented in the schema, including the mutually exclusive clear*/value pairs. The description adds no parameter-level detail, so the baseline 3 applies.

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

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

Names a specific verb (preview) and resource (metadata-only update for one active personal durable memory), which is precise and clearly the read-side counterpart to context_metadata_apply. It does not explicitly name that sibling, but the preview/apply naming pattern makes the distinction legible.

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 only implied by the preview/apply naming convention; the description never states when to call this versus context_metadata_apply, nor that it should precede an apply. No explicit exclusions or prerequisites are given.

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

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=true, idempotentHint=true, openWorldHint=true). The description adds useful behavior beyond that: a negative capability ('Never indexes') and a batch cap of 25. It still does not explain what 'finalize' does destructively to the citations or what state changes occur.

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, front-loaded sentences with essentially no filler; purpose comes first, then constraints. 'Never indexes' is terse to the point of slight ambiguity but still earns its place as a behavioral exclusion.

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, no-output-schema tool, the description covers purpose, batch cap, and default behavior but omits what finalization actually changes and what the agent gets back. Adequate but with a clear gap around the mutation's effect.

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 one parameter at 100% schema coverage, the baseline is 3. The description goes beyond the schema's terse 'Pending memory URI' by explaining the default behavior when uri is omitted (finalize up to 25 pending personal memories), which materially clarifies the parameter's optional semantics.

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 (finalize) and resource (deferred private code citations from ready graphs), which is more precise than a generic 'process'. It also gives a clarifying negative ('Never indexes'). However, it does not explicitly distinguish itself from siblings like apply_memory_candidates or complete_activation_retrieval_proof.

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 condition for the optional parameter ('Omit uri to finalize up to 25 pending personal memories') and implies a prerequisite ('from ready graphs'). But it never says when to choose this tool over the many sibling context/memory tools, leaving usage only partially 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?

Goes meaningfully beyond annotations by warning that output is untrusted evidence, that ready evidence may be deferred, that path/impact require current evidence, and by enumerating possible states (unavailable/indexing/timed-out/partial). Annotations alone (readOnlyHint false, idempotentHint true, openWorldHint true, destructiveHint false) would not convey these evidence-quality caveats.

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?

It is short with essentially no filler, and the routing tip is front-loaded. But the telegraphic semicolon-clause style reads like scratch notes and makes the structure hard to parse, which offsets the economy.

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 21-parameter tool with seven operations and no output schema, the description should explain what each operation yields and at least outline the return shape. It instead provides hints on only a handful of edges of the surface, leaving an agent unable to call 'topology', 'explain', or 'path' correctly from the description 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 coverage is 100%, so the schema already documents all 21 parameters, making 3 the baseline. The description adds a few genuine touches ('node/neighbors accept cgs_/cgr_', 'Omit budgetTokens'), but leaves most operation-specific parameter bindings 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?

The description never states what the tool does; it opens with operating advice ('Use semantic truncation before broad text search') rather than a verb+resource such as 'inspects a code knowledge graph across seven operations.' The agent must infer purpose from the name and scattered fragments (cgs_/cgr_ nodes, worksets, generations). It distinguishes itself from 'analyze_code_graph' only implicitly.

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 real when-to-use fragments: use semantic truncation before broad text search, omit budgetTokens, path/impact require current evidence, worksets read published generations while workset prepare does otherwise. However, no sibling tool is named as an alternative and the conditions are too compressed to act on confidently.

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, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds only the provenance of the URI and nothing about hidden-file defaults, recursion behavior, or what a listing returns; the idempotentHint=false on a list operation is also left unexplained.

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 short sentence with no filler, front-loading the action and resource. 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?

For a six-parameter listing tool with no output schema, the description is minimal but not misleading. It omits any hint of return shape or the default scope (threadnote://), leaving the agent to rely entirely on the schema.

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

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

Schema description coverage is 100%, so every parameter (all, uri, simple, nodeLimit, node_limit, recursive) is documented in the schema itself. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb (List) and resource (a threadnote:// directory), and ties the resource back to its origin (recall_context), which helps separate it from the other context-reading siblings. It is clear, but does not explicitly contrast itself with read_context or inspect_code_graph.

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?

'returned by recall_context' implies the workflow this tool belongs to (list what recall produced), which is useful implied context. However, there is no explicit when-to-use, when-not-to-use, or alternative-naming 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?

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds one meaningful trait beyond them: preview is the default, so an agent knows a bare call does not mutate anything. It says nothing about what preview returns, permission needs, or what apply actually overwrites.

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 action and the safe default both front-loaded. Nothing 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?

With five parameters, no output schema, and a preview/apply duality, the description is adequate but thin: it never explains what a preview produces (diff, list, file paths) or how force interacts with an existing projection, leaving the agent to guess at the preview result shape.

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

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

Schema description coverage is 100%, so all five parameters (including the uri/uris alias and force) are already documented in the schema, giving a baseline of 3. The description only loosely maps to them via 'selected memories' and 'configured Obsidian projection' without adding syntax or format 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 names a specific verb pair (preview/publish), the resource (selected memories), and the destination (a configured Obsidian projection), which is clear. It stops short of distinguishing itself from the similarly named publish siblings (procedure_publish_preview, share_publish), so an agent must infer the difference from the resource noun.

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?

'Preview is the default' gives one concrete usage rule for choosing between the two modes, which is genuinely useful. However, it offers no guidance on when to use this tool versus the sibling publish tools or on prerequisites (e.g., a projection must already be configured).

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 write, destructive, idempotent, and openWorld traits. The description adds value beyond them by disclosing two gating behaviors: an explicit approval requirement and the constraint that the proposal ID must be unchanged since preview. It does not describe side effects like Git push/commit behavior or auth scope for the shared team.

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 with zero filler; the action and destination come first, followed immediately by the preconditions. Every clause earns its place.

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

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

For a destructive publish with no output schema, the description covers the critical preconditions (approval, unchanged preview ID) that an agent must satisfy. It is slightly incomplete in not indicating what a successful publish returns or that it mutates the shared Git history, though annotations signal the destructive scope.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema. The description reiterates the meaning of 'approved' and 'proposalId' but adds no syntax, format, or default detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb ('Publish') and a specific resource ('an exact procedure proposal') with the destination ('configured team Git share'). This clearly distinguishes it from the sibling publish tools (share_publish, obsidian_publish, share_propose), which act on different artifact types.

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 mention of 'the unchanged preview proposal ID' and the 'explicit approval' gate makes it clear this must follow procedure_publish_preview, giving the agent the required precondition. It stops short of naming the alternative sibling explicitly or stating when not to use this tool, so it is slightly short of a 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 already declare readOnlyHint/idempotentHint/destructiveHint=false, so the bar is lower, and the description usefully reinforces this with 'Never writes, commits, or pushes' — which also reconciles the confusingly named 'push' parameter against the read-only behavior. It stops short of describing determinism guarantees or what the proposal contains.

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 sentences, zero filler, with the core action front-loaded and the safety constraint immediately after. Every clause earns its place.

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

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

With no output schema, the description should ideally hint at what the returned proposal is (ID, commit shape) so an agent can chain into procedure_publish_apply, but it does not. For a read-only preview tool with full annotation and schema coverage, the description is adequate but leaves the return-value gap.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters, giving a baseline of 3. The description's phrase 'locally verified procedure bytes' loosely maps to receipt/manifest/artifact but adds no syntax or semantics beyond what the schema provides.

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

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

States a specific verb and resource ('Build a deterministic Git-share proposal') scoped to 'exact locally verified procedure bytes', which is a clear, non-tautological purpose. It does not name the sibling procedure_publish_apply explicitly, though the preview/apply naming plus 'Never writes' 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 only implied: the read-only caveat suggests this is the safe step before procedure_publish_apply, but the description never says when to prefer this over the apply tool or share_propose. No prerequisites or exclusions are given.

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 readOnly=true, destructive=false, openWorld=true, so safety is covered. The description adds substantive behavior beyond that: a 65536-byte size ceiling, response format modes (agent default, text=canonical, dual=structured), and an oversize-handling strategy via outline/section/offsetBytes. It does not explain the unusual idempotentHint=false, but overall it discloses real operational traits.

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?

Terse and front-loaded, leading with the core action before limits and mode guidance. The telegraphic 'Default agent; text=canonical; dual=structured' is dense but each clause earns its place.

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

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

Covers limits, formats, and oversize handling adequately for a read tool with no output schema. It is less complete on the odd zero-required-parameter design (how uri/uris resolve) and does not distinguish itself from recall_context, leaving gaps an agent must infer.

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 71%, so the schema does much of the work; the description largely restates responseFormat values already in the schema. It does add value by tying offsetBytes/mode/section together as an oversize strategy, but leaves the uri vs uris relationship and the lack of required parameters 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 verb+resource: 'Read a recalled threadnote:// or compact memories/ pointer as evidence,' which is distinct from recall_context in that it reads a single pointer rather than performing recall. The scope ('as evidence', pointer-based) is clear, though it does not explicitly name how it relates to the recall_context sibling.

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 'a recalled ... pointer' implies this is used after recall, and it gives conditional guidance for oversized content ('mode=outline or section, or offsetBytes=0'). However, it never explicitly states when to choose this over recall_context or list_context.

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

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

Annotations already declare readOnly/openWorld/non-idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: results are unread threadnote:// pointers rather than evidence, and output defaults to compact TN-RECALL/1 text with dual adding structured content. It does not cover rate limits or cost, keeping it at 4.

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, no waste, and front-loaded with the primary search action before the navigation mode and the read_context handoff. Every clause earns its place.

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

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

For a 13-parameter read tool with no output schema, the description supplies the key missing context: that results are pointers, not evidence, and what the default output format is. It reasonably defers parameter detail to the 100%-covered schema, though budget/threshold defaults are left entirely to the schema.

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

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

Schema description coverage is 100%, so the schema already documents all 13 parameters; the baseline is 3. The description only marginally adds by noting query is optional when memoryRefs seeds navigation, which the schema also states. No new syntax or format detail beyond structured data.

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 gives a specific verb+resource ('Search memory by query') plus a second mode ('navigate verified one-hop relations with memoryRefs alone'), and explicitly distinguishes itself from the sibling read_context, which is used to read the returned pointers. An agent can tell this apart from read_context and list_context without opening any 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?

It clearly routes the agent: use read_context for results worth reading, and use memoryRefs alone (query optional) when navigating relations. It states context for both modes but offers no explicit when-not or exhaustive alternative comparison across the many sibling context 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?

Annotations declare write/non-idempotent/non-destructive status, and the description adds real behavior beyond them: only a query fingerprint is stored, feedback cannot bypass topical relevance, and it decays over time. These are meaningful effect/disclosure details, though auth or rate-limit context is absent.

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 front-loaded sentences with little waste; the enum clarification and privacy/decay notes each earn their place. Slightly dense but efficient.

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-idempotent write tool with no output schema, the description covers purpose, key behavioral constraints (decay, relevance), and the privacy model. Minor gaps around response format and permission requirements remain, but nothing critical is missing.

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

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

Schema coverage is 75%, and the description compensates for the undescribed 'action' enum by explaining that 'applied' means the item materially informed a plan and differs from 'useful'. It also confirms the query-fingerprint behavior, adding value beyond the schema text.

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 ('Record ... feedback for one recall result'), which an agent can distinguish from siblings like recall_context. The 'bounded local' qualifier is slightly jargon-y but the core action is unambiguous.

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 by 'for one recall result' and the clarified 'applied' vs 'useful' distinction, but there is no explicit when-to-use / when-not guidance or routing to an alternative tool. Adequate but leaves context 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, openWorldHint=true and non-idempotent, so the risky write profile is covered structurally. The description adds a genuine safety constraint (no secrets/credentials/customer data/raw logs) and a workflow note ("Skip Knowledge Delta review"), but says nothing about what replaceUri overwrites or how superseding mutates existing memory — the area most in need of disclosure for a destructive 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?

It is aggressively short and front-loads the action, which is good, but it resorts to telegraphic fragments and unexplained jargon ("Knowledge Delta review", "compact resume") that an outside agent cannot decode. Density without clarity costs it here.

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 15-parameter, non-idempotent, destructive memory-write tool with no output schema, the description covers the safety rule and one content shape but omits the replace/supersede semantics and most parameter behavior. It is adequate to identify the tool but not to invoke it correctly on the first try.

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 only 60% across 15 parameters, and the description adds meaning for just two of them (codeRefs enable compact resume; handoff content maps to the text/kind=handoff path). It leaves replaceUri, status, topic, relations, references, citationPolicy and the keyword flags entirely to the schema, which is thin for this many 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 opening verb+resource ("Store memory") is specific and pairs naturally with the sibling recall_context/read_context family, and the handoff sentence names the content the tool is for. It stops short of explicitly naming which sibling to prefer when, so the differentiation is inferred rather than stated.

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 (handoffs, decisions, verification, blockers) and gives a hard negative rule ("Never store secrets, credentials, customer data, or raw logs"). However it never says when NOT to store, or when to prefer apply_memory_candidates/threadnote_guide instead, 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?

Adds real behavioral context beyond the annotations: it is preview-only, requires explicit approval to apply, and nothing is auto-shared, which meaningfully qualifies destructiveHint=false and openWorldHint=true. It also discloses that handoff is required even though the schema reports zero required parameters, a useful constraint the schema alone hides. It does not explain what the preview returns or whether preview state persists, which is the residual gap.

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 zero filler; the reviewed object and its fields come first, then the preview/approval constraint. Dense but every phrase 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?

For a 19-parameter tool with no output schema and terse per-parameter descriptions ('Task', 'Why', 'Risks'), the description covers the delta grouping and the approval gate but says nothing about the preview result or the remaining ~14 metadata parameters. Adequate as a minimum-viable framing, not 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 100%, so the baseline is 3, but the description adds grouping semantics: which five fields constitute the Knowledge Delta and that handoff is a separate, required input. That framing helps the agent assemble the payload correctly across 19 loosely-described 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?

States a specific verb (Review) and resource (a five-field Knowledge Delta), and enumerates the delta's fields, so the agent knows the subject matter precisely. It also separates 'handoff' from the delta, which disambiguates two things that might otherwise look like one payload. It does not differentiate itself from sibling tools (e.g., share_propose, procedure_publish_preview), so it stops short of a 5.

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

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

Gives implied usage via 'Preview only; explicit approval is required to apply', which tells the agent this is the pre-approval step of a two-phase flow. However, it never names the tool that performs the apply, nor states when NOT to call this (e.g., when the delta is empty or handoff is missing), leaving the agent to infer the workflow.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with a precise negative scope: 'never writes files, commits, branches, pull requests, or network state.' That is genuine added value beyond the annotation flags, though the idempotentHint=false implication (non-deterministic output) is not addressed.

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 core action front-loaded and the safety constraint following immediately; no filler and every clause earns its place.

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

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

For a read-only export tool with full schema coverage and no output schema, the description covers purpose and safety adequately. It could say a bit more about the shape of the emitted proposal JSON, but 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?

Schema description coverage is 100%, so the schema already documents all five parameters, and the description adds no syntax, format, or constraint detail beyond what is in the schema. Baseline 3 applies.

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

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

States a specific verb (Export) and resource (approved, applied Knowledge Delta candidates as provider-neutral Git proposal JSON), with enough specificity to distinguish it from siblings like share_publish or apply_memory_candidates. An agent can identify the operation 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 phrase 'explicitly approved, applied Knowledge Delta candidates' implies a precondition, but there is no explicit when-to-use vs when-not, and no routing to the related share_publish or apply siblings. Usage is inferable rather than stated.

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; the description earns credit by specifying what is destroyed ("removes the source after push") and requiring confirmation before the write. That is additive context beyond the annotation flags.

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 sentences, verb front-loaded, with the destructive consequence and the safety gating stated in order of importance. 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 destructive, open-world mutation with a fully documented seven-parameter schema and no output schema, the description covers the key behavioral risks (source deletion, confirmation, content exclusions). It omits that preview offers a non-destructive dry run, which an agent deciding how to call it would benefit from.

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

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

Schema description coverage is 100%, so all seven parameters are already documented in the schema. The description hints at the scanning/redaction and filtering behavior but gives no per-parameter syntax or defaults, so the baseline 3 applies.

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

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

Names a specific verb ("Publish") and resource ("a personal durable to the team repo") and adds scope details (scanning, source removal). It never names the natural alternative (share_propose) or explains what a "durable" is, so the agent gets a clear action but no sibling differentiation.

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 a precondition ("Confirm first") and explicit exclusions ("never publish handoffs or preferences"), which is real when-not guidance. It stops short of naming share_propose or preview mode as the routing alternative.

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 this is a read-only, non-destructive, open-world call, so the safety profile is covered. The description adds two genuinely useful traits beyond that: the output is state-aware (content varies with session state) and should be delivered incrementally rather than dumped at once. It doesn't say anything about length, sections, or how to advance between steps.

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, and the core purpose is front-loaded. The second sentence is a delivery instruction rather than a description of the tool, which is slightly off-center but still 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 zero-parameter tool with no output schema, the description carries most of the burden. It tells the agent the tour is state-aware and should be presented step by step, but not what the tour contains, how many steps to expect, or how the agent should handle the 'one step at a time' sequencing. Adequate but with a clear 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. Schema coverage is reported at 100% regardless, and the empty schema with additionalProperties=false is self-explanatory.

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: returns a capability tour of Threadnote. It is clearly distinct from the sibling tools, which are all context/code/memory operations rather than onboarding material. It stops short of saying what the tour covers, but the purpose is unambiguous.

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 when-to-use guidance is given: it doesn't say to call this on first contact, after a state change, or instead of some alternative. The only instruction, 'present it conversationally, one step at a time,' is about delivery, not about when to invoke the tool.

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