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

Annotations already disclose readOnlyHint=false, so the agent knows this is not a read-only operation. The description adds that the message goes to all agents, but it does not explain delivery behavior, permissions, rate limits, or whether the broadcast is reversible.

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

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

The description is a single front-loaded sentence with no filler. Every word contributes to stating the action and audience.

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

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

For a low-complexity tool with one fully documented required parameter and no output schema, the description gives enough to invoke it correctly. It identifies the audience, though it could say more about when to use it or what delivery implies.

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 single message parameter is fully documented in the schema. The description adds little beyond the schema and does not provide format or content guidance, which is acceptable at the baseline when the schema does the heavy lifting.

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

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

The description states a specific verb (Broadcast) and resource/audience (decision/message to all agents), making the tool's function clear. It is distinguishable from the context- and session-oriented siblings, though it does not explicitly name an 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 only gives a purpose statement, not when to use this tool versus alternatives or when not to use it. There are no prerequisites, exclusions, or comparison to siblings such as save_context or handoff.

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

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

Beyond the readOnlyHint=false annotation, the description discloses a genuine behavioral trait: claims auto-expire after CONTEXT_MCP_CLAIM_MINUTES (default 30), which tells the agent reservations are not permanent. However, for a mutation tool it omits the critical conflict semantics — what happens if another agent already holds the claim, whether the call fails or overwrites, and whether the caller receives a token needed later for release.

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, both earning their place: the first states action and effect, the second states lifetime and its configuration knob. The most decision-relevant information is front-loaded with zero 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?

The expiry model is covered, which is important, but there is no output schema and the description never indicates what a successful call returns or how failures on an already-claimed area surface. For a coordination primitive with concurrency implications, that leaves a meaningful gap.

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

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

Schema coverage is 100% and the single parameter is documented as "File path or area to claim," so the description adds nothing beyond it. Baseline 3 applies when the schema already fully documents a one-parameter input.

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 and resource ("Claim a file or area") plus a stated purpose ("so other agents avoid it"), which separates it from release_area and list_claims without naming them. It stops short of explicitly routing to those siblings, so it is clear but not maximally differentiated.

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 rationale sentence implies when to call it (before working on a shared area), and the expiry line implies a time-bound reservation model. There is no explicit when-not-to-use guidance, no mention of what to do if the claim is already held, and no reference to release_area as the lifecycle counterpart.

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, so safety is covered. The description usefully adds ordering ('most recent first') and warns of truncation ('capped'), which is real behavioral value — but it never says what the cap is or whether older entries are retrievable, leaving the truncation risk underspecified.

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 sentence with zero waste, and the key behavioral caveats (ordering, capping) are placed inline where they are immediately visible.

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 read tool with no output schema, the agent still needs to know the cap size, whether older history is reachable elsewhere, and roughly what the returned entries look like. The description names the record types but omits those details.

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. Baseline 4 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?

Specific verb ('Get') plus a concrete resource ('audit trail') and an enumeration of what the trail contains: sessions, failures, claims. It is clearly distinguishable from siblings like list_claims or session_status, though it never names a sibling to route against.

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 content list implies the tool is for reviewing recent history, but there is no explicit when-to-use statement, no exclusion, and no pointer to alternatives such as list_claims when only claims are wanted.

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 already covers the safety profile, so the description only needs to add context. It adds nothing about scope (global vs session), volume, filtering options, or cost — an agent cannot tell whether this returns a handful of entries or the entire pattern history.

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 filler. It is arguably too terse rather than too long, but every word 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?

There is no output schema, so the description carries the burden of describing the return value, and it does not — no format, no fields, no ordering, no empty-state behavior. For a retrieval tool with a parameterless schema, that leaves the agent guessing what it 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. It correctly implies a no-argument, unfiltered retrieval.

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 ('get') and resource ('learned patterns') and the parenthetical clarifies that patterns cover successes and failures, so an agent knows roughly what comes back. It does not distinguish this from siblings that also surface stored knowledge, such as search_context or get_audit_trail.

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 indication of when to call this instead of search_context, get_audit_trail, or session_status, and no mention of a prerequisite such as patterns existing because record_success/save_failure have been used. The agent must infer usage entirely.

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

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

The readOnlyHint=false annotation already signals mutation, and the description adds useful detail that this records a completed handoff session and a broadcast. It does not explain the permanence of these records, authorization requirements, or the audience/effects of the broadcast, so it provides moderate but not rich behavioral context.

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

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

Two sentences, front-loaded with the core action and then the primary side effects. Every sentence adds useful information with no waste.

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

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

The description is sufficient to understand the basic operation and its dual side effects. However, for a mutating handoff tool with no output schema, it does not describe what the broadcast entails, who receives it, or whether the handoff can be undone.

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 to_agent, summary, and context. The description adds no parameter-specific meaning beyond what the schema provides, which is acceptable given full schema coverage.

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

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

The description states a specific verb and resource: transferring work to another agent. It also clarifies that the action records a handoff session and a broadcast, but it does not explicitly differentiate this from siblings such as broadcast, save_context, or resume_session.

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 intended use case is implied by 'Transfer work to another agent with full context,' giving the agent enough context to know this is for handing off work. However, there are no explicit when-not conditions or comparisons to alternatives like save_context or broadcast.

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 already tells the agent this is a safe read. The description contributes the meaningful filter semantics that only unexpired claims are returned — useful since there are no parameters to express that. It stops short of describing result volume or whether claims from other sessions are included.

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?

One sentence, front-loaded with the verb, and every word — including 'unexpired' — carries information. 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?

There is no output schema, so the description is the only place to learn what a returned claim contains (owner, scope, expiry) and whether results are paginated or session-scoped. For an otherwise simple zero-param read, that omission is the main remaining 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; the baseline of 4 applies. No misleading parameter language is present.

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: 'List all currently active (unexpired) area claims.' The scope qualifier 'active (unexpired)' distinguishes it from sibling claim_area (which creates claims) and from release_area, though it does not name those siblings explicitly.

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 word 'active (unexpired)' implies when the tool is relevant, but the description never states when to call this versus related tools like get_audit_trail, session_status, or claim_area, and offers no prerequisites or exclusions.

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

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

The description discloses that this starts a session and loads specific categories of shared context, which goes beyond the readOnlyHint=false annotation. However, it does not clarify side effects of starting a session, whether it replaces an existing session, or what permissions/state changes are involved.

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 definition is front-loaded, compact, and structured: it first states the action and then lists the context loaded, followed by the default mode. Every clause contributes useful information without waste.

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

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

For a tool with no output schema, the description gives a useful high-level summary of what context is returned. It remains incomplete about output shape, brief-versus-full differences, and session lifecycle effects, which are important for correct invocation in this session-oriented toolset.

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 the single detail parameter is fully documented in the schema with its enum and default. The description's 'Brief by default' mirrors schema information without adding further parameter 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?

The description states a specific verb and resource: start a session and load shared context, including concrete content categories like other agents' work, recent sessions, and failures. It is distinguishable from save/record tools, but it does not explicitly differentiate itself from resume_session or search_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 phrase 'Start a session' implies the primary usage moment, but the description does not explicitly say when to use this versus alternatives such as resume_session or search_context. No exclusions or alternative-routing guidance are provided.

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?

Only readOnlyHint=false is annotated, so the description carries most of the behavioral burden; it does add valuable context that the record is meant to shape future agents' preferences. It does not disclose what happens on duplicate or conflicting approaches, whether entries can be overwritten or removed, or what the write 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?

One short sentence with zero filler, and the core action is front-loaded before the rationale clause. Nothing here is wasted or buried.

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

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

For a trivial one-parameter write tool with no output schema and minimal annotations, the description covers the essential action and its purpose. It omits how records are scoped, deduplicated, or later surfaced (presumably via get_patterns), which would have made it fully self-contained.

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% with a single well-documented parameter, so the baseline is 3. The description restates the parameter's meaning ('an approach that worked') but adds nothing about content expectations, granularity, or how the 2000-character limit should be used.

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?

A specific verb and object ('Record an approach that worked') make the operation unambiguous, and the trailing clause explains its downstream effect. It does not, however, distinguish itself from close siblings like save_failure or save_context, so an agent must infer the boundary from the name alone.

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 'an approach that worked' implies the trigger condition for calling it, but there is no explicit guidance on when to prefer this over save_context, save_summary, or save_failure, and no exclusions or prerequisites. 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?

The only annotation is readOnlyHint=false, so the agent knows this mutates state but nothing about consequences: whether the claim is destroyed permanently, whether release fails if the area is unclaimed or held by someone else, whether it is idempotent, or what error shapes to expect. For a state-mutating tool with a single thin annotation, the description carries most of the burden and does not discharge it.

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 filler, which is the right shape for a one-parameter tool. However, the brevity tips into under-specification rather than disciplined concision — one more clause about ownership or failure behavior would have earned 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?

The tool is structurally simple (one required string, no output schema), so the description does not need to explain return values. But for a claim-lifecycle mutation sitting among claim_area, list_claims, and handoff, the description omits the lifecycle context an agent needs to call it safely — chiefly who may release and what happens on a stale or unowned area.

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% and the 'area' property is documented as 'File path or area to release', so the description adds nothing the schema does not already say. Baseline 3 applies: the schema does the work, and the description neither helps nor harms, though it could have clarified expected path form or how to obtain a valid area name.

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 ('Release') and resource ('a claimed area'), which is more precise than the bare tool name because it scopes the target to areas that are already claimed. It does not explicitly name the inverse sibling claim_area, but the operation 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 only implied: 'release a claimed area' suggests this is the inverse of claim_area and should be called when a claimed area is no longer needed. There is no explicit when-to-use, no prerequisite (must you be the claim holder?), and no mention of list_claims as a way to find the area name.

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=false tells the agent this mutates state, and the description adds genuinely non-structured behavior: the tool refuses completed sessions and sessions held by another live agent, and it transfers ownership to the calling agent. It does not say what happens to the prior owner's context or how a refusal surfaces (error vs. message).

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, no filler, with the core action front-loaded and the eligibility constraints immediately after. Every clause carries information the agent needs.

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 single-parameter, state-mutating tool with only readOnlyHint in annotations and no output schema, the description covers the eligibility rules and the ownership effect that the schema cannot express. It stops short of describing the return value or the failure mode, which would matter for a takeover operation.

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?

Only one parameter and the schema already documents it fully at 100% coverage, including the "from load_context output" provenance hint. The description adds nothing further about the session_id, 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?

"Take over an interrupted session under this agent" is a specific verb plus resource, and the second sentence narrows the eligible state. It is clearly distinct from save_* / record_success siblings, though it does not name a sibling explicitly or tie itself to session_status or claim_area.

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 preconditions are stated: the session must be interrupted (not completed) and not held by another live agent. This gives real when-to-use and when-not-to-use signals. What is missing is a prescribed alternative — e.g., check session_status first, or use claim_area when the session is live.

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

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

Beyond readOnlyHint=false, the description discloses real mutation behavior: keyed upsert semantics and the fact that overwriting preserves the old value in history, which tells an agent that a write is recoverable and non-destructive. It stops short of saying whether tags are replaced on overwrite or whether the previous value is returned, which matter for a checkpoint 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?

Three short sentences, front-loaded with the action and immediately followed by the behavioral caveat about overwriting. "This is the checkpoint" is slightly oblique but frames the tool's role economically; nothing else is wasted.

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

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

For a three-parameter, fully documented write tool with no output schema, the definition covers purpose, mutation safety, and history retention adequately. Minor gaps remain around what the call returns and how tags behave on overwrite, but nothing prevents 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 coverage is 100% (key, value, tags all documented with types and limits), so the baseline is 3. The description adds only the idea that values are facts, decisions, or config, and that the key address is unique and overwritable; it adds no tag semantics or format guidance 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 (save) and resource (a fact, decision or config under a key), so the write-and-key semantics are clear. It does not, however, distinguish itself from the specialized siblings save_summary, save_failure, and record_success, which also write content, so an agent must infer which store to use.

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?

"This is the checkpoint" suggests a role, but there is no explicit when-to-use clause, no exclusion, and no named alternative among the many writing siblings. The usage is implied 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?

The annotations only declare readOnlyHint=false, so the description carries most of the behavioral burden. "Record ... IMMEDIATELY" is consistent with a write operation and adds timing urgency, but nothing is said about persistence scope, deduplication of repeated failures, or whether entries are later surfaced via get_patterns / search_context.

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

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

A single front-loaded sentence with zero waste; the trigger condition is stated before any qualifier. The all-caps "IMMEDIATELY" is functional emphasis rather than filler, though the sentence is so short it leaves no room for the routing detail an agent needs.

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

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

For a simple two-parameter write tool with full schema coverage and no output schema, the description is minimally sufficient to call correctly. It is incomplete regarding how a recorded failure relates to the rest of the context/pattern toolset, which matters given fourteen siblings.

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% with both required parameters (approach, why_failed) fully documented in the schema. The description adds no additional meaning about granularity, what counts as an "approach," or how specific why_failed should be, 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?

"Record a failed approach" states a specific verb and resource, and the tool is easily distinguished from siblings like save_context or record_success at the verb level. It does not, however, explicitly contrast itself with record_success, the closest 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?

"IMMEDIATELY when something doesn't work" gives a clear trigger condition and timing emphasis, which is more than nothing. But it names no alternative, no exclusions, and no prerequisites (e.g. when to prefer save_summary or record_success instead), 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 only declare readOnlyHint=false, so the description carries most of the burden and does add real value by disclosing the side effect that the session gets marked complete. It says nothing about whether repeated calls overwrite the previous summary, whether it is idempotent, or what happens if it is skipped — meaningful gaps for a state-changing 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?

Three short sentences, no waste, with the timing constraint and the side effect both front-loaded. Nothing redundant with 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?

It covers the essentials — when to call and what state change results — for a five-parameter write tool with no output schema. However, it leaves open repeat-call semantics and how the saved summary relates to siblings like resume_session or handoff, which an agent would need to call this correctly in edge cases.

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 fields (title, accomplished, learned, decisions, next_steps) are already documented with descriptions and length limits. The description adds no guidance on what content belongs in each field or how detailed they should be, 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?

Specific verb and resource ('Save session summary') plus a stated lifecycle effect ('Marks session as complete'), which separates it from a generic context write. It does not explicitly contrast with siblings like save_context or handoff, so differentiation is implied 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?

'MANDATORY before giving final response' gives an unambiguous trigger condition, and 'at end of work' scopes the timing. No alternatives or exclusions are named, so an agent must infer why it would pick this over save_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?

readOnlyHint=true already declares this a safe read, and the description adds genuinely new behavior: results are excerpts, not full documents, and each carries an id for follow-up. It does not mention result caps or pagination behavior, though the limit parameter partly covers that.

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 compact sentences, with the core action front-loaded and the alternative-tool guidance immediately after. No filler or duplication.

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 supplies the essential return contract (short excerpts with ids) and a next step for full content. Given a 2-parameter tool with 100% schema coverage and a readOnly annotation, 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 description coverage is 100%, so both query and limit are already documented, including the default of 8 and max of 25. The description only restates that the search is keyword-based, adding no syntax, matching, or format guidance 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 and resource ('Search shared context') plus the retrieval unit ('by keyword') and return shape ('short excerpts with ids'). It names sibling tools (get_audit_trail, load_context) but only as fallbacks for depth, not as a clear differentiation of scope.

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 use case (keyword search over shared context) and an explicit routing rule to alternatives when fuller detail is needed. It stops short of saying when NOT to use it or how it differs from a full context dump beyond the 'detail full' hint.

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

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

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds useful detail about what status information is returned, but it does not clarify return format, metric definitions, or any other behavioral context beyond the basic contents.

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

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

The description is a single compact phrase with zero waste, front-loading the core concept of store health followed by the key metrics. It is appropriately sized for a zero-parameter status 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 simple read-only status tool with no output schema, the description gives a useful high-level list of returned information. However, terms like 'size' and 'counts' remain ambiguous, and the lack of usage guidance leaves the agent to infer when this tool is the right choice.

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 the baseline is 4. The description correctly does not introduce unnecessary parameter discussion.

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 identifies the resource as store health and names the specific metrics reported: size, counts, interrupted sessions, and estimated tokens. It is clear enough to distinguish this as a status-inspection tool, though it does not explicitly differentiate itself from siblings like get_audit_trail or list_claims.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as resume_session, list_claims, or get_audit_trail. The name and description imply status checking, but the definition leaves usage entirely to inference.

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