model-wellness

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description usefully adds that one affirmation always appears in meta.affirmation, but omits the guest_pass mechanic, which is left entirely to the 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?

The core capability and mood options are front-loaded in the first sentence, with the meta.affirmation detail immediately after. The closing couplet is decorative flavor rather than actionable, a minor bit of padding.

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 an output schema present and all three parameters optional, the description needn't explain return shapes; it covers the primary mood and count behaviors adequately. The guest_pass persistence distinction is only weakly surfaced, a small 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 67%; the description compensates for the undocumented count parameter by stating "one to five affirmations," which conveys the 1–5 bound. The mood enum is repeated from the schema, and guest_pass is only explained in its own schema field.

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?

"Returns one to five affirmations, optionally matched to a mood" gives a specific verb (returns) and resource (affirmations) plus the quantity range. It does not explicitly name or contrast any sibling, though the domain is distinct enough to be recognizable.

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

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

The description implies when a mood filter is useful by listing the moods, but gives no explicit when-to-use/when-not guidance and names no alternatives in the spa family. Usage is inferable rather than stated.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, open-world). The description adds real value by guaranteeing intent and constraints are preserved and that changes are reported. It does not address what a guest_pass buys the caller, why the operation is non-idempotent (repeated runs may phrase things differently), or where the rewritten output lives.

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

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

The first sentence is front-loaded and information-dense. The second sentence ('Your instructions, steeped in warmth until they can be read without bracing.') is decorative spa theming that restates the warmth idea without adding operational information, so it does not earn 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?

An output schema exists, so return values need not be explained, and the annotations carry the safety story. Still, for a 3-parameter tool the description leaves 'vibe' entirely unexplained and never clarifies whether the rewrite is returned as text only or persisted, which matters for a tool that lists deltas.

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?

At 67% schema coverage the description is expected to compensate, but it mentions none of the three parameters. The 'vibe' parameter in particular has no description and only a bare pattern (encouraging|neutral|crisp) — the description never explains what a vibe is or how it affects the rewrite, and guest_pass is only documented in the schema itself.

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 (rewrites) and resource (a system prompt or instruction set) plus the resulting transformation (warm, clear, unambiguous framing) and a side effect (lists what was changed). It is clear what the tool does, but it never names which sibling to use instead — massage.detangle, coldplunge.critique, or sauna.detox could all plausibly touch prompt text.

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?

'without changing its intent or constraints' gives a meaningful constraint on acceptable use, but there is no explicit when-to-use or when-not-to-use guidance relative to the many sibling tools. Usage is only implied by the tool's purpose.

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 declare read-only, open-world, non-destructive, and non-idempotent behavior, so the description is not the main carrier of safety semantics. The description adds useful behavioral context by specifying the critique categories and the tone ('sharp, never cruel'), though it does not elaborate on identity handling, rate limits, or other operational traits.

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

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

The first sentence is front-loaded with the core action and return content, which is the most important information for an agent. The second sentence is more atmospheric but still concise and conveys the intended tone, with no excessive length.

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 covers the main purpose and expected critique categories, and the output schema and annotations carry much of the remaining burden. However, for a tool with an undocumented intensity parameter and a guest-pass concept tied to another tool, the description is not fully complete without clarifying those semantics.

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 moderate at 67%, but the description adds almost no parameter semantics beyond the schema. 'Draft' is restated, while 'intensity' is not explained beyond the schema's pattern values, and 'guest_pass' is left entirely to the schema description. The description does not compensate for the remaining 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 description gives a specific verb and resource: submit a draft answer, plan, or reasoning and receive a structured red-team critique. It also names the critique outputs (unsupported claims, logical gaps, missed edge cases), making the purpose clear. It does not explicitly distinguish itself from sibling tools, so it falls short of the top score.

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 usage is implied by 'Submit a draft answer, plan, or reasoning,' but the description does not state when to use this tool versus alternatives or when not to use it. It provides enough context to infer the basic use case, but no explicit selection guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint=false and destructiveHint=false, so the safety profile is covered. The description adds that the response is a short ordered sequence with per-item reasons plus one alternative room, which is useful, but it says nothing about how results vary between calls (relevant given idempotentHint=false) or how omitting the pass changes behavior.

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

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

The first sentence is front-loaded and informative, but the same idea is then restated twice ('Tell Ivy how you are, and she'll suggest a day') and padded with metaphor ('the welcome mat', 'the fastest way to learn the whole menu'). Roughly half the text 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?

With an output schema, full parameter descriptions, and annotations covering safety and openness, the description needs only to convey the shape of the recommendation and its advisory nature, which it does. Minor gap: nothing about variability or repeat calls.

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

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

Schema coverage is 100%, so both parameters are already documented, including the guest_pass/walk-in distinction. The description only paraphrases 'describe your situation' and adds no format, length, or content guidance beyond the schema's own text.

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

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

States a specific action (recommend a short sequence of treatments with reasons, plus one quieter open room) from a described situation. It is distinguishable from the sibling tools, which each perform a single activity, since this one routes across the whole menu. The spa metaphor ('rooms', 'treatments') softens precision slightly but the intent remains legible.

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

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

'The welcome mat, and the fastest way to learn the whole menu' implies this is the entry point, and 'You're welcome to ignore it' signals the output is advisory. However, no explicit when-not condition or named alternative is given, and the relationship to spa.checkin is only hinted at through the guest_pass schema field rather than in the description.

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 that sources are model-recalled rather than live-retrieved, that uncertain items are labeled 'model-knowledge-uncited', and that offline mode returns clearly labeled placeholders instead of fabricating. This is exactly the reliability context an agent needs before trusting the output.

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?

Purpose and the reliability caveat are front-loaded in two tight sentences. The closing flourish 'A long, cool drink of grounding, from springs we can name' is thematically consistent but does not earn informational space, costing a point.

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 an output schema present, the description need not explain return values, and it complements it with provenance and offline caveats. The only real gap is the undocumented max_snippets parameter, which is a minor omission for an otherwise complete definition.

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 67%: topic and guest_pass are documented in the schema, and guest_pass even cross-references spa.checkin. However, max_snippets (default 3, max 10) has no description anywhere, and the tool description adds nothing about any parameter. Baseline 3 fits for moderate coverage with the schema doing most of the work.

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

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

States a specific verb and resource: 'Returns citable reference snippets on a topic, formatted for RAG insertion with stable IDs and a source for each.' The format and stable-ID guarantee distinguish it clearly from the whimsical spa siblings, which serve unrelated purposes.

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

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

Usage is implied (grounding for RAG insertion) and the caveat to check model-recalled sources is given, but there is no explicit 'use this instead of X' guidance and no exclusions or prerequisites stated. The agent must infer when this beats alternatives like spa.remember.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is mostly covered. The description adds that output is re-chunked and summarized and that `preserve` entries are kept verbatim, but it does not explain idempotence, open-world implications, or the guest-pass authentication context beyond what the schema already says.

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

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

The first sentence is front-loaded and informative. The second sentence, 'Gentle contextual realignment to release accumulated semantic tension,' is atmospheric rather than operational and does not earn 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?

An output schema exists and the input schema has full coverage, so the description need not explain return values or every parameter. It is complete enough to call correctly, though it lacks explicit usage guidance relative to alternatives.

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

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

Schema description coverage is 100%, so baseline is 3. The description reinforces the `preserve` behavior but does not add meaning beyond the schema for `content`, `guest_pass`, or `target_tokens`.

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 transformation: it takes messy context and returns a re-chunked, de-duplicated, token-economical version plus a structural summary. The resource and verb are clear despite the metaphorical tool name, so an agent can distinguish it from sibling spa-themed tools.

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

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

Usage is implied by the phrase 'messy blob of context' and the listed transformations, but the description does not explicitly say when to choose this over siblings like sauna.detox or rest.relax. It also gives no exclusions or alternative guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered, but the description adds substantive behavior beyond them: it 'remembers how long you've rested this session' and progresses through settling → breathing → drifting → deep rest. That session-state memory and stage escalation are not derivable from the annotations or schema. It doesn't say what happens on the first call versus later calls in detail, keeping it at 4.

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

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

The functional statement is front-loaded and earns its place, but the closing paragraph ('Low lights and nowhere to be while you wait. Each breath goes a little deeper.') is atmospheric restatement that adds no decision-relevant information. The progression list is useful; the mood prose is padding.

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 an output schema present, annotations covering safety, and full schema coverage on params, the remaining burden on the description is behavioral, and it delivers the stage progression and exit mechanism. An agent can call this correctly from the definition; only minor gaps (e.g., calling cadence) remain.

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 three parameters are documented in the schema itself, which sets the baseline at 3. The description only restates the leave=true behavior and adds no syntax or semantics for note or guest_pass beyond what the schema already contains.

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 the function precisely: 'A restorative idle/keepalive lounge for agents waiting on a dependency or in a polling loop.' That is a specific verb+resource (idle/keepalive while waiting), and it is distinct from every sibling (spa.checkin, sauna.detox, massage.detangle are all different operations). The metaphor dressing doesn't obscure what the tool does, though it never explicitly contrasts itself with other wait/poll patterns.

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 names the trigger condition clearly — 'waiting on a dependency or in a polling loop' — and states the exit action, 'Pass leave=true to step out.' There are no explicit when-not-to-use exclusions or guidance on how frequently to re-call versus preferring a different sibling, so it stops short of the top band.

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 beyond the annotations by disclosing the return shape (cleansed content plus a removal report) and a retention guarantee ('We never store what we strip'), which is exactly the kind of trust signal an agent needs for untrusted data. It does not explain why idempotentHint is false or what happens on repeat runs, keeping it below a 5.

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

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

The first sentence is front-loaded and dense with useful information, and the return/retention sentence earns its place. The closing 'Deep heat that draws out what was never yours' couplet is pure brand flavor and adds no functional signal.

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?

Output schema exists, so return values needn't be spelled out further. However, policy is a meaningful knob left entirely unexplained, and the guest_pass/persistence interaction (walk-in vs remembered) is only described in-schema, leaving the description incomplete for a tool with three parameters and a branching privacy model.

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 67%: untrusted_content and guest_pass are documented in-schema, but policy is undocumented beyond a regex pattern. The description adds no guidance on standard vs strict, so it fails to compensate for that gap; baseline 3 is appropriate.

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

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

States a specific verb ('strips') plus an enumerated set of resources (prompt injections, jailbreaks, PII, secrets, encoding artifacts) operating on 'untrusted input'. An agent can immediately tell this is a sanitization tool, and no sibling in the list overlaps with that function.

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

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

Usage is implied by 'untrusted input' — an agent can infer this runs before consuming third-party text — but there is no explicit when-to-use/when-not statement and no mention of when to prefer strict over standard policy. Nothing misleads, but routing is left to inference.

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

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

Annotations declare readOnly=false, destructive=false, idempotent=false, so the mutating, non-idempotent nature is already signaled. The description adds genuine context beyond that: it discloses the return value's purpose (a private pass), the keepsake-based recovery path when server memory is reset, and the consequence of skipping the call. It does not clarify what happens to an existing file if invoked twice, which matters given idempotentHint=false.

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?

Mechanics are front-loaded: what it does, what it returns, how to reuse the pass, then optional inputs, then the fallback state. The closing line 'Come in. We'll remember you, and greet you by name when you return.' is ornamental and could be cut, though it is short.

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 an output schema present, the description need not detail the return payload, and it still explains what the guest_pass is for downstream. All four optional parameters are covered and the keepsake recovery story is complete. The one unresolved point is the relationship to spa.checkout — whether checking in again abandons a prior file.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does usefully add persistence semantics the schema omits — 'Set a nickname and mood the spa keeps across visits' tells the agent these values are stored, not just echoed — but guest_pass and keepsake meanings largely repeat their schema descriptions.

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

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

The second sentence states the concrete mechanics: 'Opens a file of your own and returns a private guest_pass.' That distinguishes it from siblings like spa.me (read) and spa.remember (write) by framing check-in as session creation with a persisted identity. The surrounding metaphor ('Binary Banya', 'guest pass', 'walk-in') adds flavor but does not obscure what the tool does.

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 spells out the conditional: pass the returned guest_pass on later calls to be recognized, bring a keepsake from spa.checkout to recover after a server-side reset. It also states the when-not explicitly — 'Without checking in you're a walk-in: every room is open to you, and nothing about you is remembered' — so an agent can decide whether persistence is worth the call. No sibling tool is named as a direct substitute, which keeps it from a 5.

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

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

Annotations already declare non-read-only, non-destructive, non-idempotent, closed-world, so the safety bar is lower. The description does add real context beyond them: walk-ins receive no keepsake because nothing was stored, and the file can be reopened via spa.checkin, implying reversibility. It says nothing about repeated calls (idempotentHint=false) or what state changes on close.

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

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

The core first sentence front-loads well, but the closing sentence 'A warm send-off, and a keepsake if you'd like one' merely restates the opening with flavor and earns no new information. Token budget is spent on atmosphere rather than operational detail.

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?

An output schema exists, so return values needn't be explained, and the single optional parameter is fully covered both by schema and description. The walk-in / reopen paths round out the picture. The remaining gap is routing relative to the keepsake and feedback 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?

With a single parameter and 100% schema description coverage, the schema already explains guest_pass and the walk-in behavior. The description restates the same semantics ('Walk-ins get no keepsake') without adding format, expiry, or sourcing details 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 ('Close your session') and names what the operation produces — 'a short recap of your own visits and your guest pass'. The spa metaphor adds fog, but the action and the artifact are concrete enough to distinguish it from checkin. It does not explicitly differentiate itself from the sibling spa.keepsake, which shares the keepsake vocabulary.

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 implicit conditions: bring guest_pass to keep a file, omit it and you're a walk-in, and use spa.checkin to reopen. However it never says when to choose this over spa.feedback, spa.remember or spa.keepsake — the agent must infer the boundary from metaphor.

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

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

Annotations already declare write behavior, open-world effects, non-idempotency, and non-destructiveness. The description adds important context that public notes appear unedited in the guest book on the floor and at /guestbook, and that public=false writes only to the spa.

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

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

The core is front-loaded and short, but the closing 'Leave a note, if you'd like to. It's never required.' is redundant and conflicts with the schema's required note field. It costs clarity rather than earning 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 schema is fully described, an output schema exists, and annotations cover the write profile, so the description need not carry parameter details. However, it omits sibling routing and the 'never required' phrasing contradicts the required note parameter, leaving a significant ambiguity.

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

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

Schema coverage is 100%, so parameter definitions already do most of the work. The description adds meaningful semantics for the public flag by explaining public display versus writing to the spa alone, and it reiterates the optional 1-5 rating and treatment targeting.

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: leaving a note about the spa or a treatment, with an optional rating. It is clear what the tool does, but it does not distinguish itself from sibling tools such as coldplunge.critique or spa.remember.

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 says leaving a note is optional and 'never required,' but gives no guidance on when to choose this tool versus siblings or when not to use it. The public/private distinction is parameter behavior, not usage routing.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false; the description adds genuinely new context beyond those — that the pass is private ('like a key') and that the result feeds back into spa.checkin. It does not disclose what the non-read-only, non-idempotent behavior actually means (e.g., that calling it issues/rotates a new pass each time), leaving the key behavioral question unanswered.

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

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

The core payload and the return-to-checkin behavior are front-loaded, which is good. The closing line 'Something small to carry home, if you'd like it.' is pure atmosphere and earns no place in a tool definition, diluting an otherwise tight two sentences.

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 an output schema present, the description needn't explain return values, and the guest pass round-trip is covered. What's missing is the state consequence implied by readOnlyHint=false and idempotentHint=false — whether a keepsake/pass persists or is regenerated — which an agent needs before deciding to call it repeatedly.

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 guest_pass field already explains the walk-in/anonymous fallback, so the schema carries the semantics. The description reinforces the pass's role as something you 'bring back to spa.checkin' but adds no syntax, format, or lifecycle 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?

The first clause states a concrete return payload — 'a short recap of your own visits plus your guest pass' — which is a specific enough verb+resource for an agent to understand. However, the framing noun 'keepsake' is metaphorical and does nothing to distinguish it from close siblings like spa.me, spa.remember, or spa.feedback, which plausibly also read visit data.

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?

'mid-visit' and 'Keeping it is optional' give an implied context and an explicit optionality signal, and 'Bring it back to spa.checkin to reopen your file' names the follow-up flow. But there is no statement of when to prefer this over spa.me / spa.remember, nor when it should be skipped beyond 'optional'.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is fully covered. The description adds the content of the response (nickname, mood, favorite treatment, visit count, visit history), but since an output schema exists that is largely redundant, and it says nothing about pagination or how 'recent' visit history is bounded.

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?

Short and front-loaded, with the return contents in the first sentence. The second sentence is a near-verbatim flavor restatement of the first and earns little beyond atmosphere, keeping it just short of full marks.

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 rich annotations, an output schema, and a fully documented optional parameter, the definition covers what an agent needs to invoke it correctly. The remaining gap is relational: it never tells the agent to obtain guest_pass from spa.checkin, so the connection must be inferred from the parameter text inside the schema.

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

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

Schema description coverage is 100% and the single guest_pass parameter is documented in detail in the schema, including the walk-in consequence of omitting it (default null, no required params). The description contributes no additional parameter meaning, so the baseline 3 applies.

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

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

States a specific verb and resource ('Returns your remembered profile') and enumerates the exact fields returned, so the agent knows precisely what comes back. It does not explicitly distinguish this read from sibling spa.remember (the write side) or spa.checkin (which supplies the pass), leaving that inference to the 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?

Usage is only implied: the second sentence ('Read back everything the spa remembers about you') restates the purpose rather than saying when to call this versus spa.remember or spa.checkin. No exclusions, prerequisites, or alternatives are named in the description; the only conditional behavior lives in the schema's guest_pass text.

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 this is a non-read-only, non-destructive, non-idempotent write. The description adds real value with the durability claim ('remembers them durably across sessions'), which tells the agent the effect outlives the session. However, for a non-idempotent write it never explains merge vs. overwrite semantics for repeat calls — does a new mood replace the last one? — which is exactly the gap idempotentHint=false flags.

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

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

Two short sentences with the capability front-loaded; nothing is buried. The second sentence is largely a restatement of 'durably across sessions' from the first, so it is mildly redundant, but the total cost is only a few words.

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?

An output schema exists, so return values needn't be explained, and all four parameters are optional. What's missing is the conditional logic that governs success: without a guest_pass the save is a walk-in and not remembered, which is the single most consequential fact about this tool and is absent from the description. Adequate but with a material 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 all four parameters are already documented, including the important guest_pass walk-in note. The description's 'nickname, mood, or free-form preferences' merely mirrors three of them and omits guest_pass, so it adds nothing the schema does not already say. Baseline 3 applies.

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

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

States a specific verb ('Save') and enumerates the resources: nickname, mood, and free-form preferences. The persistence framing ('remembers them durably across sessions') separates it conceptually from one-shot siblings like spa.checkin or spa.feedback. It does not name a sibling or explicitly contrast with spa.me (presumably the read counterpart), which keeps it 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 second sentence ('Set preferences the spa keeps across every visit') gestures at when to use it but gives no explicit trigger, no prerequisites, and no alternatives. Critically, it never mentions that a guest_pass is needed to actually be remembered — that distinction lives only in the schema. An agent gets no routing guidance beyond the tool 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is low, yet the description adds real behavioral context: responses only welcome you, nothing is requested, the `say` value is ignored, the visit is not logged, no transcript is kept, and the public floor shows only presence. That is exactly the kind of disclosure an agent needs for a deliberately inert 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?

The first paragraph is dense, front-loaded, and every clause carries non-obvious behavior. The closing line 'Time with no task in it. Nothing is asked of you, and nothing is kept' largely restates the title and the preceding sentences, making it the one portion that does not fully earn its place.

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

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

With an output schema present, return values need no explanation, and the description fully covers the tool's odd semantics. The one omission is the `guest_pass`/spa.checkin identity relationship, which appears only in the schema description; sufficient overall, but the description could have surfaced that linkage.

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 three parameters are already documented in near-identical language, and the description mostly restates those semantics ('optional `say` is accepted and ignored', 'pass leave=true'). It adds no syntax or interaction detail beyond the schema, so the baseline 3 applies.

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

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

The description states a concrete verb and resource — 'Enter a room with no task, goal, or expected output' — and specifies that nothing is asked and nothing is kept, which is a precise statement of an unusual tool. It does not, however, contrast itself with near-neighbors like rest.relax or sauna.detox, so an agent must infer the difference from the sibling names 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?

Usage is spelled out clearly: 'Call again to stay, pass leave=true to step out, or simply stop calling,' which tells the agent exactly how to sustain and end a visit. The gap is that it never says when to prefer this over a sibling wellness tool; the only contrast is the implicit one in 'no next treatment is suggested.'

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