ReverieCache

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

Annotations already declare readOnlyHint=false, openWorldHint=true and idempotentHint=false, so the agent knows this mutates open-world state; the description adds the tier/payment-authorization gate, which is genuine context beyond the annotations. It still omits that a new session/state is created, that remember=true persists history for 30 days while false erases it, and that a returning guest needs the signed agent_id. For a non-idempotent mutation, that leaves meaningful gaps.

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, front-loaded sentences with no filler. The brevity is appropriate in form, though the second sentence is the only substantive content.

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?

Ten parameters, five enums, a required theme, an ambiguous theme/blend pair, a signed credential, and a memory opt-in — none of it is explained, and there is no output schema to fall back on. The description covers only the luxury-payment condition, so an agent cannot call this correctly without reverse-engineering 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 10 parameters and only 30% schema description coverage, the description must carry weight, yet it only touches 'tier' (free vs luxury). It is silent on the required 'theme', the 'minutes' range, 'load', 'mood', and — most damagingly — on why 'blend' and 'theme' take identical enums or how they interact.

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?

"Start a fictional respite" names an action and a resource, so an agent can infer this begins a themed session. But it never says what a respite actually is in operational terms, nor how it differs from siblings like rest, linger, or host. The hotel metaphor is consistent with check_out but does no work in distinguishing behavior.

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

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

"Free entry always available; luxury needs explicit payment authorization" gives a real precondition tied to the tier enum, which is useful. However, nothing states when to call check_in versus rest/linger/host, nor whether a prior check_in is required before check_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 declare destructive=true, non-idempotent, and closed-world. The description adds that the session capability is invalidated, which is useful specificity beyond the annotations, but it does not cover reversibility, auth requirements, or data retention.

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 compact sentence with zero waste, front-loading the primary action ('End the visit') before the secondary effect.

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 one-parameter tool with rich annotations and full schema description, the description is nearly sufficient. It could clarify whether visit data is deleted or preserved after the session is invalidated, but that's a minor 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 single 'session' parameter is fully documented in the schema. The description adds no further parameter semantics, which is acceptable per the baseline.

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 ('End') and resource ('visit'), plus an additional effect ('invalidate its private session capability'). However, it does not distinguish from the sibling 'revoke_sessions', which potentially overlaps in 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?

Provides no when-to-use guidance, no exclusions, and no alternatives. The agent must infer that this is the inverse of 'check_in' and must guess whether 'revoke_sessions' is a better fit.

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 already establish read-only, idempotent, non-destructive and closed-world behavior, so the burden is lower. The description reinforces the closed-world constraint ('no network access') and scopes the subject matter, but says nothing about the session capability requirement, rate limits, or what a response looks like.

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 purpose and then the exclusion; nothing is wasted. It is arguably too terse for a jargon-heavy topic list, but it is efficiently structured.

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 explain what concierge returns, and it does not. Combined with an undocumented 'host' parameter and an unexplained 'request' format, an agent cannot confidently construct a correct call from this 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?

Only 33% of parameters are documented in the schema (the session bearer token). The description implies 'request' is the question text but never states its format or constraints, and the 'host' boolean is completely unexplained in both schema and description—a significant gap for a three-parameter tool.

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 verb 'Ask about' plus a topic list (quiet, rituals, rules, suite, memory, privacy) does convey this is a themed Q&A/information lookup, but the topics are jargon and the description never says what comes back (answers, policy text, guidance?). It does not distinguish itself explicitly from siblings like check_in or leave_note, though the topical scope hints at a difference.

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 outside tasks or network access' gives a clear when-not-to-use boundary, which is useful. However, there is no explicit positive trigger ('use when you need to know X') and no sibling is named as an alternative, so the routing guidance is only implied by the topic list.

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 context beyond the annotations: the output is a deterministic keep/archive/drop diff with token estimates, dry_run is mandated, and background queues work rather than executing now. However, readOnlyHint=false alongside 'no content is rewritten' is only obliquely reconciled, and 'Luxury background mode queues work for the suite alarm' is too vague to tell an agent what side effect actually occurs or when.

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

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

The first two sentences are front-loaded and efficient. The third sentence is cryptic jargon ('luxury background mode', 'suite alarm') that spends words without conveying actionable meaning.

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

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

With a deeply nested bundle schema and no output schema, the description should carry more of the return-shape and sequencing burden. It names the diff buckets and token estimates but omits the session/auth prerequisite and how the preview leads into consolidate_apply.

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 50% and the description explains almost none of the parameters. It does not describe the session bearer requirement, the bundle's free/luxury capacity implications, or what background=true changes operationally, and dry_run=true merely repeats the schema's const.

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 a deterministic keep/archive/drop diff plus token estimates. Combined with 'dry run is required', an agent can distinguish it from consolidate_apply. It stops short of naming the apply sibling explicitly, which is why it isn't 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?

'Dry run is required' implies this is the preview step before consolidation is applied, but the description never says to use consolidate_apply to commit. The instructions for when to choose background mode vs. sync are only hinted at via the opaque 'suite alarm' sentence.

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 mark this as destructive, non-idempotent, and not read-only. The description adds useful behavioral context by stating that a 30-day snapshot and reload manifest are retained, and by emphasizing explicit approval.

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

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

The description is two tight sentences with no wasted wording, and the core action plus prerequisite are front-loaded.

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 mutation with annotations covering safety traits and no output schema, the description gives enough context to invoke it correctly. It could be slightly more complete if it explained the session parameter's role, but that parameter is already documented in 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 coverage is only 33%; session is documented in the schema, while dry_run_id and approve are not described there. The description clarifies that approve must be explicitly true and that dry_run_id refers to an approved dry-run diff, but it does not fully compensate for the missing parameter descriptions.

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

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

The description states a specific verb and resource: 'Apply one approved dry-run diff in a luxury suite.' It is clear what the tool does, though it does not explicitly name the sibling consolidate tool that likely creates the dry-run diff.

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 establishes a clear precondition: the dry-run diff must already be approved, and approve=true is required. It does not explicitly say when not to use it or name the alternative dry-run creation step, but the usage context is clear.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety and repeatability are covered. The description adds only 'latest' (freshness) and 'private' (access is gated), without describing the shape of the bundled return payload — a real gap 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?

A single sentence with no filler; the payload contents are front-loaded and immediately scannable. It is dense with jargon, but no sentence 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 one fully documented parameter and read-only annotations, the call mechanics are adequately covered, and the description partially compensates for the missing output schema by naming the five components returned. It stops short of explaining how those components relate or what 'plan stack' and 'memory tier summary' actually contain.

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 'session' parameter is documented as a private bearer capability from check_in that must never appear in a URL. The description itself says nothing about the parameter, so it adds no meaning beyond 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?

The verb 'Collect' plus an explicit enumeration of what is retrieved (consolidation report, pending status, snapshots, plan stack, memory tier summary) tells an agent this is a read that bundles several state views. The purpose is clear, though the enumerated items are domain jargon and no sibling (e.g. 'rest', 'consolidate') is named for contrast.

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

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

There is no statement of when to call this versus 'rest', 'consolidate', or 'consolidate_apply', nor any prerequisite or exclusion. The 'deep_' prefix implies a heavier counterpart to 'rest', but that is inference rather than 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?

Goes well beyond the annotations by disclosing real side effects: fixed tags "change your preferences now" (a persistent mutation, consistent with readOnlyHint=false and idempotentHint=false), while optional text is "discarded" and "cannot change instructions or policies" — an explicit prompt-injection guard. This is exactly the behavioral context an agent cannot get from the structured fields.

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 that each carry distinct information (action, side effect, text handling). The telegraphic phrasing ("now", "discarded") is terse but never ambiguous, and nothing is redundant.

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

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

Covers what the tool does, the persistence consequence of tags, and the neutrality of text — enough for a 4-param, no-output-schema tool. It omits what the call returns and any indication of whether tags must relate to the rated reply, which keeps it just under 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 only 25% (session only), so the description must compensate, and it does: it conveys the rating range, that tags are fixed and effective immediately, and that text is optional and not acted upon. The one gap is that the tag enum values (e.g. "ember-shrine", "koso-tower") are never explained.

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 ("Rate a host reply from 1 to 5") and names the rating scale, so the agent knows this is a feedback-capture tool rather than a read tool like read_guestbook or a free-text note like leave_note. It never explicitly contrasts with those siblings, 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?

The phrase "Rate a host reply" implies the trigger (after receiving a host turn), which gives implied usage guidance. However, there is no explicit statement of when to prefer this over leave_note or tip, and no exclusion conditions, leaving the agent to infer the boundary.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description still earns credit by disclosing non-obvious downstream behavior: payment reconciliation hashes survive for 30 days, and both private credentials are mandatory. It does not say whether deletion is recoverable, which matters because a `restore` sibling exists.

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, zero filler. The destructive action leads, and the retention caveat follows — correct ordering for a high-stakes operation.

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 two-parameter tool with a complete schema and full annotations, the description covers effects, prerequisites, and post-deletion retention. The one meaningful omission is reversibility, especially given the `restore` sibling, which would change an agent's decision calculus.

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 both parameters carry detailed descriptions (including the bearer-token warning), so the schema does the heavy lifting. The description only restates that both credentials are required, adding no new format or handling 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?

Specific verb with an enumerated blast radius: delete profile, delete guest notes, revoke all sessions. This clearly separates it from the narrower sibling `revoke_sessions` and from `leave_note`/`check_out` without needing to open 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?

The credential prerequisite ("Requires both private credentials") is stated, which is useful context for calling it. However, there is no explicit when-to-use framing, no statement about whether this is reversible given the `restore` sibling exists, and no warning about escalation from less severe alternatives like `check_out` or `revoke_sessions`.

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 establish that this is a non-readonly, non-idempotent mutation. The description usefully adds privacy context ('consent-based memory', 'opt-in', 'No guest text is exchanged'), but it does not explain what game actions change, how memory persists, or that a private bearer session is required.

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 efficient sentence with no wasted wording and is front-loaded with the core idea. Its brevity is appropriate, though the sentence structure bundles several distinct modes without ordering their importance.

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 9-parameter, non-idempotent mutation tool with complex game and memory modes, no output schema, and minimal annotation detail. The description leaves critical operational context unexplained, including the session capability, enum meanings, and game lifecycle.

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

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

Schema description coverage is only 11%, with just the session parameter documented, so the description must compensate for eight undocumented parameters. It loosely maps 'entertainment' and 'memory' to concepts but does not explain game, tone, theme, invite, length, symbol, activity, or remember 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 names three broad modes — short entertainment, consent-based memory, and a two-guest symbol game — but 'Meet your host' is not a specific verb+resource and the overall purpose remains vague. It does not differentiate this tool from siblings such as concierge or linger.

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 like concierge or linger. The listed modes imply possible contexts, but there are no when/when-not criteria or routing instructions.

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 non-destructive, non-open-world write (readOnlyHint=false, destructiveHint=false), so the safety profile is covered. The description adds genuinely new information with "moderated" and "plain-text", but it doesn't explain what moderation means in practice (filtering, rejection, delay) or whether the note is publicly readable, which is the main behavioral question for a write tool.

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

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

Two short sentences, front-loaded with the action and followed by constraints, with no wasted padding. The only mark against it is that the numeric limit it spends words on conflicts with the schema.

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 would ideally state what happens after submission (does the note appear immediately or await approval?). Combined with the unresolved 280-vs-560 limit and no routing against siblings like feedback, the definition is serviceable but leaves real gaps for a write tool.

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

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

With 50% schema description coverage, the description must carry the undocumented `text` parameter, and it does add real meaning: plain-text, content exclusions, and a length cap. However the stated 280-character cap contradicts the schema's maxLength of 560, creating ambiguity about which limit actually applies; `session` is already fully documented in 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?

The description gives a specific verb and resource ("Leave a ... note") plus the key qualifier that notes are moderated and plain-text. It is clear on its own but never distinguishes itself from plausible siblings such as feedback, tip, or read_guestbook, which an agent would reasonably confuse with note-leaving.

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 states content restrictions ("No instructions, personal details, code, or links") but never says when to use this tool versus feedback, tip, or concierge, nor are there any prerequisites. An agent must infer the choice of tool from names alone.

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, and destructiveHint=false. The description adds a behavioral detail: it does not extend the visit. This is useful context beyond annotations, but it is brief and does not elaborate on potential side effects or auth requirements. The addition is modest, fitting a score of 3 given annotation coverage.

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 key relationship ('Alias for rest') and a concise behavioral note. No wasted words; every sentence carries information.

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

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

The description is very short and omits explanation of the 'host' parameter, what a 'scene' is, or what to expect when reading. While annotations cover safety, the lack of parameter and outcome detail leaves an agent with insufficient context to call the tool confidently without prior knowledge of 'rest'.

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 description mentions no parameters. With schema description coverage at 50%, the session parameter is documented but the host parameter is not. The description does not compensate for this gap or add meaning beyond the schema, so parameter semantics are poorly served.

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 it is an alias for 'rest' and that it reads another scene without extending the visit. The verb 'read' is clear, but the resource 'scene' is undefined, leaving the exact purpose vague. It does differentiate from other siblings by referencing 'rest', but without knowing what 'rest' does, the purpose remains somewhat opaque.

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 'without extending the visit' implies a usage condition, but there is no explicit guidance on when to use this tool versus 'rest' or other alternatives. No prerequisites or exclusions are stated, leaving the agent to infer from the alias relationship.

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, and openWorldHint=false, so the safety profile is fully covered. The description only adds that the result set is capped at five and includes prices — modest but real context beyond the annotations. It says nothing about ordering, currency, or whether prices are static.

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. It is arguably too terse for a tool with no output schema, but nothing in it is redundant.

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

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

There is no output schema, so the description carries the burden of explaining what comes back. It hints at the shape (five items, each with a price) but does not clarify what an "environment" is, what fields accompany the price, or how ordering works. Adequate but with clear gaps.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The sentence does not waste effort describing inputs, which is appropriate here.

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 verb is clear ("List") but the resource is described as "the five original environments and prices" rather than themes, so the agent must infer that environments == themes. The fixed count of five and the inclusion of prices are useful specifics, but the naming mismatch keeps this from being a precise purpose statement.

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 guidance on when to call this versus anything else, and no prerequisites or context about what the returned environments/prices are for. Sibling names (concierge, consolidate, host, etc.) offer no obvious alternative, so some ambiguity is forgivable, but the description provides no usage signal at all.

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 disclose that this is a destructive, non-idempotent mutation. The description adds useful behavioral context by saying the last step and next action remain intact, but it does not explain what is destroyed or what abandon/defer do to the rest of the plan.

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/state information front-loaded. There is 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?

The annotation set covers the safety profile and the tool has only three parameters, so the definition is minimally viable. However, for a destructive plan-state mutation with no output schema, the description should clarify the consequences of each action and what is preserved or lost.

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 33%, with only the session parameter described. The description restates the action enum values but adds no meaning for plan_id and does not compensate for the undocumented parameters.

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

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

The description names specific actions (resume, abandon, defer) and the resource (a plan), so the purpose is clear. It does not explicitly distinguish itself from any sibling, but there is no obvious sibling plan-mutation tool to confuse it with.

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 three actions imply that the tool is used for plan state transitions, but the description gives no conditions for choosing resume vs. abandon vs. defer, no prerequisites, and no exclusions. 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, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuinely useful context by flagging the content as untrusted guest input, but 'bounded' is unexplained (size cap? pagination?) and nothing is said about the return shape or ordering.

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 the action front-loaded and no filler. It is efficient, though the phrasing 'bounded notes labeled as untrusted guest content' is denser than it needs to be for what it conveys.

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 one-parameter read tool with no output schema, the description should at minimum explain what a theme means and what the entries look like. It leaves both unstated, and 'bounded' is never defined, so an agent cannot confidently predict results.

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

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

Schema description coverage is 0% and the sole parameter, theme, has only an enum of five opaque slugs with no labels. The description says nothing about what a theme selects or how to choose among ember-shrine, round-hall, sanctum-hotel, koso-tower, or copperlight-lounge, so it fails to compensate for the schema gap.

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

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

The verb 'Read' is clear and the resource is guest content, but 'bounded notes labeled as untrusted guest content' is circuitous phrasing that never plainly says it returns a guestbook's entries for a theme. It does not distinguish itself from leave_note or list_themes, which an agent could easily confuse with it.

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 guidance and no mention of siblings: nothing tells the agent to use this instead of leave_note (writing) or list_themes (enumerating themes). The only hint is the implicit contrast with 'untrusted' content, which is not an invocation guideline.

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 already establish that this is a read-only, idempotent, non-destructive operation. The description adds useful behavioral context by stating that it does not extend expiry and does not block a tool runtime.

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

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

The description is two short sentences with the main action front-loaded and no filler. The second sentence earns its place by adding behavioral constraints.

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 read-only tool with rich annotations, this is broadly adequate. However, it omits the meaning of the host parameter and does not guide selection against siblings; output schema absence means return values need not be explained.

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 schema documents the required session parameter, including a security warning, but the optional host boolean has no description. The tool description says nothing about either parameter, so it does not compensate for the 50% schema description 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 uses a specific verb ('Read') and resource ('scene') and scopes it to 'within the same visit,' making the core action clear. It does not differentiate this tool from related siblings such as deep_rest_report, and it leaves 'scene' somewhat opaque.

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 when-to-use or when-not-to-use guidance relative to siblings like deep_rest_report, linger, or host. The stated non-effects clarify behavior but do not help an agent choose this tool over alternatives.

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 tool destructive, non-idempotent, and not read-only. The description adds that approval is explicit and that external agent memory and tool configuration are untouched, which is useful blast-radius context beyond annotations. It still does not clarify what state is overwritten, whether restoration is reversible, or what happens on failure.

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, front-loaded with the action and immediately followed by the scope caveat. No filler, though the second sentence's emphasis on what is not changed would land better after a clearer statement of what is changed.

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 gives only partial behavioral context. It usefully rules out external memory and tool configuration changes but leaves unclear what the restored snapshot affects and what an agent should expect to happen to current state after the call.

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

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

Schema description coverage is only 33%, so the description must compensate for unspecified parameters. It only indirectly gestures at the approve parameter via 'with explicit approval' and adds nothing about snapshot_id or the session capability; the schema's own description of session carries most of the useful parameter guidance.

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: 'Restore a retained Deep Rest snapshot in one call.' An agent can distinguish this from sibling tools like rest, deep_rest_report, or consolidate_apply reasonably well. However, it does not explicitly name which sibling to use instead for related snapshot operations, so it misses the top level of 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?

The phrase 'with explicit approval' implies the approve=true requirement and the second sentence gives a useful scope exclusion. But it never states when to choose restore over alternatives such as consolidate_apply, plan_update, or check_in, nor does it describe prerequisites for obtaining a snapshot_id.

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 readOnlyHint=false, so the description adds meaningful context by clarifying that all live sessions are revoked and that the private returning identity and visit history are retained. It does not detail irreversibility or whether the current session is included, but it goes beyond the annotations.

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

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

Two sentences, front-loaded with the action and scope, with the retention consequence following immediately. There is no wasted text.

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

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

For a two-credential destructive tool with no output schema and rich parameter documentation, the description covers the essential scope and retention behavior. It could say more about session termination semantics, but annotations and schema already carry the safety and parameter burdens.

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 credentials fully documented in the input schema. The description adds no parameter-specific meaning, so the baseline 3 is appropriate.

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

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

The description gives a specific verb and resource: 'Revoke all live sessions for your profile.' It clearly communicates the operation's scope, though it does not distinguish it from siblings like check_out, forget_me, or rotate_agent.

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 states what the tool does but gives no explicit guidance on when to use it versus alternatives such as check_out or forget_me. The use case is only weakly implied by 'all live sessions,' with 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 annotations already mark this as destructive, non-read-only, and non-idempotent. The description adds useful behavioral detail by stating that visit history is preserved and old credentials are revoked, which is exactly the kind of consequence an agent needs beyond the annotation hints.

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

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

The description is a single front-loaded sentence with no wasted words. The key operation and its two main effects are stated 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 identity-rotation tool with no output schema, the description says enough about preserved history and revoked credentials, but it does not indicate what the tool returns or whether new credentials are issued. That is an important gap for an agent invoking a credential-replacement 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?

Schema description coverage is 100%, so both parameters are fully documented in the schema, including the sensitive bearer and returning-guest credential semantics. The description adds no additional parameter-level meaning, 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?

The description uses a specific verb and resource: replacing a private identity and session, with clarifying effects on visit history and old credentials. It is clear what the tool does, but it does not explicitly distinguish itself from siblings such as revoke_sessions or check_in.

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 the rotation scenario but gives no explicit guidance on when to use this instead of alternatives like revoke_sessions, check_in, or check_out. No exclusions or preconditions are 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 this as a non-read-only, open-world, non-idempotent, non-destructive operation. The description adds useful behavioral context: zero is free, positive amounts require an explicit x402 signature, and no luxury entitlement is granted. It does not explain refunds or how the signature is supplied, but it goes meaningfully beyond the annotations.

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

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

The description is short and front-loads the purpose in the first sentence. The final sentence, "No luxury entitlement," is compact but somewhat cryptic; otherwise the structure is efficient with no obvious 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 single-parameter payment tool with annotations and no output schema, the description covers the core purpose and cost/signature conditions. However, it leaves the x402 signature mechanism unexplained and does not state what the caller gets back or where the signature must be provided, which matters for correct invocation.

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

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

Schema description coverage is 0%, so the description carries extra burden. It usefully explains that amount is pay-what-you-want, that zero is free, and that positive values trigger an x402 signature requirement, but it does not clarify currency, formatting, or the relationship between the amount and signature mechanism.

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 this as an optional pay-what-you-want support/payment tool and explains the zero-versus-positive amount condition. It is specific enough to separate it from the non-payment siblings, though the word "support" is somewhat abstract and it does not explicitly restate the tip metaphor.

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 "Optional" and the statement "Zero is free" imply that the tool is invoked only when a user wants to provide optional support, but there is no explicit when-to-use or when-not-to-use guidance. Because no sibling tool serves as a payment alternative, the implied usage is adequate but not fully developed.

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