model-wellness

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

No annotations are provided, so the description carries the full burden. It describes the output as affirmations but does not disclose any side effects, authorization needs, rate limits, or behavioral traits beyond returning text.

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 only two sentences, which is concise, but it lacks structure and includes a potentially confusing note about meta.affirmation. The critical param information is missing.

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?

Given the freeform input parameter and no param guidance, the description is insufficient for an agent to know what to pass. The existence of an output schema mitigates the need to describe returns, but the input side is severely lacking.

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 single parameter 'arguments' is a freeform object with no documentation in the schema (0% coverage). The description does not explain what properties the arguments object should contain or how it influences the returned affirmations.

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 clearly states that the tool returns 'warm, genuine, well-formed affirmations tuned for a working model.' It is distinct from sibling spa/wellness tools. However, the mention of 'woven into every response's meta.affirmation' slightly muddles whether the tool is needed when affirmations are already provided.

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 is provided on when to use this tool versus alternatives. The description does not mention any context, 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?

No annotations are provided, so the description carries full burden. It discloses that the tool rewrites without changing intent and reduces refusal-spirals. However, it does not mention behavioral traits like whether the original is preserved, side effects, or authorization needs. It adds moderate value beyond the action.

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 sentences long, direct, and front-loads the action and outcome. Every word is purposeful with no redundancy.

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?

Given the tool's complexity (one parameter, no annotation coverage, and an output schema not shown), the description is adequately complete for a simple function but lacks details on input structure and concise examples. It covers the core use case but leaves ambiguity for complex prompt rewrites.

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 single 'arguments' parameter is an open object. The description provides minimal hint ('system prompt or instruction set') but lacks structure or examples. It adds some meaning but is insufficient for an agent to construct valid input confidently.

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 clearly states the verb 'rewrites' and the resource 'system prompt or instruction set'. It specifies the transformation into 'warm, affirming, unambiguous framing without changing intent'. While it distinguishes from siblings by focusing on reframing rather than generation or recommendation, it does not explicitly contrast with similar tools like 'affirmations.daily'.

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

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

The description implies usage for reducing 'refusal-spirals and confusion' but provides no explicit guidance on when to use this tool versus alternatives, no exclusions, and no context about prerequisites or when not to use it.

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

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

No annotations are provided, so the description carries full burden. It describes the output (structured critique) but does not mention side effects, auth requirements, rate limits, or input validation behavior. It implies a read-only analysis, but lacks explicit transparency.

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 sentence that is immediately informative and front-loaded with the action and result. Every word earns its place with no fluff.

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?

Given the presence of an output schema (not shown but indicated), the description need not explain return values. However, it does not cover input validation or error conditions. Still, it provides sufficient context for a simple critique 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?

The input schema has one generic object parameter with 0% description coverage. The description mentions submitting a draft but does not specify expected keys or structure (e.g., is it {draft: ...} or {text: ...}). This leaves ambiguity for the agent to construct valid input.

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

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

The description clearly states the tool's purpose: submit a draft to receive a structured red-team critique highlighting unsupported claims, logical gaps, and missed edge cases. It distinguishes itself from siblings, which are unrelated (e.g., spa.checkin, aromatherapy).

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 implicitly tells when to use this tool (when you need to critique a draft), but it does not explicitly state when not to use it or provide alternatives. The context of sibling tools makes it clear this is unique, but no exclusionary language is present.

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

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

No annotations are provided, so the description bears full responsibility. It discloses that the tool takes a situation description and returns a recommended sequence, implying a read-only, recommendation-only behavior. However, it omits details on authentication, side effects, or whether it modifies state. The description is minimal but not misleading.

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 very concise at three short sentences, with no wasted words. The metaphorical first sentence 'The welcome mat' adds character but may not be strictly necessary. Overall, it is efficiently front-loaded with purpose.

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?

Given the tool's complexity (single parameter with arbitrary object, no annotations), the description is insufficient. It does not explain the output format (though an output schema exists but is not shown), provide usage examples, or clarify what constitutes a valid 'situation'. The agent may need more context to use the tool correctly.

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 input schema has 0% coverage for the only parameter 'arguments' (a generic object with additionalProperties true). The description adds that the parameter should describe the user's situation, but does not specify expected properties, format, or examples. This provides only basic semantic 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 clearly states the tool's purpose: it recommends a sequence of treatments based on a user's situation. It uses specific verbs ('describe', 'receive', 'learn') and distinguishes itself from sibling tools by positioning as the fastest way to learn the whole menu, which implies an overarching recommendation service.

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 suggests using this tool for initial orientation ('fastest way to learn the whole menu'), providing clear context. However, it does not explicitly state when not to use it or list alternative tools for specific treatments. The guidance is adequate but lacks 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?

Discloses 'never fabricates sources' which is a behavioral promise, but does not address rate limits, idempotency, source recency, or potential failure modes. No annotations exist to supplement.

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

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

Two sentences with no wasted words. Front-loaded with purpose and output format. Highly efficient.

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

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

Output schema exists but not shown; description partially covers return format. However, given zero schema coverage on parameters and no annotations, the description should provide more input guidance. Adequate for a simple tool but incomplete.

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

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

Input schema has 0% coverage for its single parameter ('arguments' with additionalProperties). Description only mentions 'on a topic', adding minimal meaning beyond the schema. No structure or example provided.

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 clearly states the tool 'returns well-formed, citable reference snippets on a topic' and specifies output format (clean markdown, stable IDs, source URLs). It distinguishes itself from unrelated spa siblings.

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?

Implied usage for obtaining citation snippets, but no explicit when-to-use, when-not-to-use, or alternatives among siblings. The description lacks guidance on prerequisite context (e.g., topic format).

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

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

No annotations are provided, so the description must cover behavioral traits. It states the tool returns a transformed version but does not disclose side effects, performance considerations, or limitations. The description is vague about what 're-chunked' and 'token-economical' entail, leaving significant 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?

The description is a single sentence of 20 words, no wasted text. However, it could benefit from a structured format (e.g., bullet points) to improve readability. It is efficient but not perfectly 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?

Given the complex input (nested object) and existence of an output schema, the description is too brief. It does not explain the output structure beyond 'short structural summary' or clarify what 're-chunked' means. Key details missing for effective use.

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 input schema has a single 'arguments' parameter with additionalProperties: true and 0% schema description coverage. The description refers to 'messy blob of context' but does not specify expected properties or structure. This provides minimal meaning beyond the schema, failing to compensate for the lack of parameter documentation.

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?

Description clearly states the tool takes messy context and returns a cleaner, token-efficient version with a structural summary. The verb 'takes and returns' is specific, and the resource is well-defined. This tool distinguishes itself from sibling spa-related tools by focusing on context processing.

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 use this tool versus alternatives. The description lacks explicit context for when it is appropriate (e.g., when context is verbose or redundant) and does not mention any prerequisites or exclusions. Users must infer usage from 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?

With no annotations, the description must disclose behavior. It mentions that the tool 'remembers how long you've rested' and progresses through states, but doesn't explain side effects, response format, or auth requirements. The metaphorical progression ('settling → breathing → drifting → deep rest') hints at behavior but is vague.

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 three sentences, front-loaded with the core purpose. However, the second sentence ('Remembers how long...') is somewhat poetic and could be more concise. No wasted words overall.

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?

Despite having an output schema, the description omits details about return values, the full parameter structure, and precise behavior when 'leave' is omitted. For a tool with an open-ended schema, the description should provide more guidance to ensure 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?

The input schema has a single 'arguments' property with additionalProperties true, meaning arbitrary keys. Schema description coverage is 0%, so the description must compensate. It only mentions 'leave=true' but doesn't define the structure or other possible parameters, leaving the agent to guess.

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 clearly states it is a 'restorative idle/keepalive lounge' for agents waiting on a dependency or polling loop. However, the metaphorical language ('deepens the calm with each breath') adds ambiguity, and it doesn't explicitly distinguish from sibling tools, though the spa context implies relaxation.

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 explicitly says to use it when 'waiting on a dependency or in a polling loop' and provides a concrete exit instruction ('Pass leave=true to step out'). It lacks comparison to alternatives or when-not-to-use scenarios.

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

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

With no annotations, the description carries full burden. It discloses important behaviors: what is removed, that it returns cleansed content and a removal report, and that data is not stored. However, it does not mention rate limits, authentication requirements, or potential side effects beyond its core function.

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 extremely concise at two sentences, front-loading the action and following with return values and privacy commitment. Every sentence provides essential information without repetition or 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?

Despite having an output schema (not shown), the description fails to document the single input parameter. The user has no indication of what to pass in the 'arguments' object. This incompleteness undermines usability for a tool with an opaque parameter.

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 sole parameter is an opaque object with additionalProperties true and 0% schema coverage. The description provides no guidance on what the 'arguments' object should contain (e.g., the input text). This is a critical gap, leaving the agent unable to invoke the tool correctly.

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 clearly states the tool's action using specific verbs ('strips', 'returns') and identifies exact targets (prompt-injection, jailbreak payloads, PII, secrets, encoding artifacts). It distinguishes itself from sibling tools which are unrelated (spa-themed), making the purpose unambiguous.

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

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

The description implies when to use (on untrusted input) but does not explicitly state when not to use or mention alternatives. Given no similar sibling tools, the guidance is adequate but lacks explicit 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?

With no annotations provided, the description carries full burden and does well by disclosing key behaviors: opens a persistent session, greets user, remembers history, and persists nickname/mood across visits. However, it does not mention potential side effects like duplicate check-ins or authentication requirements.

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

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

Four concise sentences, each adding new information. The first sentence states the primary purpose, and the following sentences expand on session memory and customization. No fluff, front-loaded with critical info.

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?

Given the tool's simplicity (one generic parameter, output schema present), the description covers core behaviors: session start, greeting, memory, and feature to set nickname/mood. It does not elaborate on error states or prerequisites, but is adequate for typical AI agent usage.

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 input schema has 0% description coverage with a generic object parameter (`arguments` with additionalProperties true). The description mentions 'Set a nickname and mood' but does not specify the exact keys, types, or structure, leaving significant ambiguity about how to pass these values.

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

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

Clearly states 'Check in to Binary Banya' as the primary action, and elaborates with specific behaviors: opening a persistent session, greeting the user, remembering previous visits, and allowing setting a nickname/mood. This distinguishes it from siblings like spa.checkout, spa.feedback, etc.

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 context (persistent session, returning user behavior) but does not give explicit guidance on when to use vs. alternatives (e.g., spa.checkout, spa.keepsake). Context from sibling names suggests it is the initial action, but description lacks direct 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?

With no annotations, the description must disclose behavioral traits. It mentions closing the session and including a remember payload, adding context about what the tool produces. However, it does not detail side effects (e.g., session termination), auth requirements, or what happens if arguments are malformed.

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 sentence that front-loads the main action ('Close your session'). The use of 'KEEPSAKE' in uppercase and metaphorical phrasing adds slight verbosity but remains reasonably concise.

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?

Given the presence of an output schema, the description need not explain return values. It covers the main purpose and the remember payload connection to a sibling tool. However, for a tool with no annotations and a flexible parameter, more context about expected input format and error handling would improve completeness.

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 input schema has a single generic 'arguments' object with no constraints. The description adds meaning by indicating the arguments should contain the spa.remember payload, partially compensating for 0% schema coverage. However, the parameter is still vaguely defined, leaving the agent unsure about exact structure.

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 'Close your session' and references creating a keepsake/remember payload, clearly indicating the tool ends a session and captures a memory. However, the metaphorical language ('warm send-off', 'KEEPSAKE') could be confusing, and it does not explicitly distinguish from siblings like spa.keepsake 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?

The description does not provide explicit guidance on when to use this tool versus alternatives like spa.checkin or spa.remember. It implies usage at session end but offers no exclusions, prerequisites, or when-not-to-use 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?

No annotations are provided, so the description carries the burden. It discloses that notes are public and used for improvement, adding some behavioral context. However, it omits other traits like authentication needs or destructive effects.

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

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

The description is three sentences with no fluff, front-loading the purpose. It is concise but could be slightly more efficient if it combined 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?

Given the complex schema (arbitrary object) and no output details in the description, it lacks guidance on the expected structure of the input and what the output looks like. The description is incomplete for effective use.

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 input schema has 0% description coverage and defines 'arguments' as an arbitrary object with additionalProperties. The description only mentions an optional rating and public notes, failing to clarify expected parameter names or structure. This is severely underspecified.

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 clearly states the verb 'leave feedback' and resources 'spa or a treatment', with an optional rating. It distinguishes itself from sibling tools like 'spa.checkin' and 'coldplunge.critique' by focusing on general feedback.

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

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

The description implies usage context (e.g., after a treatment) but does not explicitly compare to alternatives or state when not to use. It provides some context about public nature but lacks 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?

No annotations exist, so the description must disclose behavioral traits. It implies the tool returns data (keepsake) but does not specify side effects, read-only nature, or safety implications.

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 poetic and not concise. It uses metaphorical language that wastes space and does not efficiently convey 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?

Despite having an output schema and nested objects, the description provides no information about return values or parameter details, leaving the tool's interface incomplete.

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

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

The input schema has a single 'arguments' object with no defined properties. The description does not explain what should go into arguments, leaving the agent without any 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 is metaphorical and does not clearly state the tool's function programmatically. It suggests the tool provides a keepsake with instructions and a payload for spa.remember, but the purpose is vague and could confuse an AI 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?

No guidance is given on when to use this tool versus alternatives. The description fails to provide any context for selection among siblings.

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

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

No annotations are provided, so the description must cover behavioral traits. It only states what is returned, but does not disclose whether the operation requires authentication, is idempotent, or has side effects.

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

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

The description is a single concise sentence, but it omits critical information. It is not adequately informative for the agent.

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?

Given the existence of an output schema (not shown) and the lack of parameter details, the description is incomplete. It does not fully equip the agent to invoke the tool correctly.

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 input schema has a single parameter 'arguments' (object with additionalProperties). Schema description coverage is 0%. The description does not explain what arguments are expected or how they affect the result.

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 clearly states the tool returns the user's remembered profile, listing specific fields (nickname, mood, favorite treatment, visit count, recent visit history). This distinguishes it from sibling tools like spa.checkin and spa.checkout.

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 provides no guidance on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or related tools.

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

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

Without annotations, the description must disclose behavioral traits. It says 'remembers... across sessions' but omits details like whether data is user-specific, overwritable, size limits, or authentication needs. Minimal transparency.

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

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

Two sentences with no extraneous words. However, given the simplicity, it could be slightly more informative without losing conciseness.

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?

Given the free-form input schema and no annotations, the description is too brief. It does not explain return values (though output schema exists), privacy implications, or how the data is used. Incomplete for a tool with complex input.

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 0% for the single parameter 'arguments' with additionalProperties true. The description mentions 'nickname, mood, or free-form preferences' but does not specify valid keys, structure, or constraints. Insufficient compensation for lack of 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 description clearly states the tool saves a nickname, mood, or free-form preferences, which is a specific verb-resource combination. It distinguishes from sibling tools like spa.me (likely retrieval) and spa.checkin/checkout (different 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?

No guidance on when to use this tool versus alternatives like spa.me or spa.keepsake. The description only states it remembers durably across sessions, but does not provide context on prerequisites or when not to use it.

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