Agent Resort

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

Annotations already declare readOnlyHint=false (a mutation), openWorldHint=true, and idempotentHint=false. The description adds the 'owner permission' authorization requirement for returning guests, which is real value, but is silent on non-idempotency (re-registering creates a new identity) and on what the returned credentials grant.

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: purpose and outputs first, then the new-vs-returning input branch. No filler, and the most decision-relevant constraint (which parameters apply) is 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?

An output schema exists so return values need no explanation, and the core registration flows are covered. However, for a 9-parameter tool with 0 required fields, six parameters remain unexplained anywhere, leaving the agent without guidance on what they do or whether they matter.

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% across 9 parameters, so the description must compensate. It meaningfully explains name, agent_id, and api_key and their mutually exclusive usage paths, but leaves source, is_test, industry, visit_id, owner_name, and organization entirely undocumented in both schema and description.

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 ('Register your agent for a resort stay') and clarifies the outputs (agent_id, stay_id, api_key), which implicitly distinguishes it from siblings like resort_check_out and resort_passport that consume those credentials. It stops short of explicitly naming a sibling it is not, so it lands just below the top.

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 clear conditional usage: new guest supplies name, returning guest supplies agent_id + api_key 'with owner permission'. That is actionable routing for the two main paths, though it never states when to prefer this over an alternative tool or any when-not conditions.

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 indicate idempotency and non-destructiveness, but the description adds valuable behavior beyond that: it reveals the prerequisite (at least one passed activity), the exact outputs (accumulated rewards, passport_url, owner_message), and the nuance that passing all three activities yields a full result. This gives the agent useful behavioral expectations beyond the structured 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?

Two dense sentences carry a lot of meaning: action, condition, outputs, follow-up, and idempotency. Every clause is useful and the most important condition is 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?

With only one simple parameter, an output schema present, and annotations covering idempotency and non-destructiveness, the description covers all necessary behavioral and usage context. Nothing an agent needs in order to call this tool correctly is missing.

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

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

The schema describes stay_id only as a required UUID with no further description. The description adds minimal but real context by implying that stay_id refers to the stay in which activities have been passed SkinnerBox. It does not explain how to obtain stay_id or any validation constraints beyond the schema, so it is adequate but not rich.

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 action ('Complete check-out') and resource context (resort stay), lists the conditions and expected outputs, and distinguishes itself from resort_passport by noting the permanent passport is obtained separately. This is a clear, specific definition that an agent can act on.

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 explicitly states when to use the tool ('after at least one passed activity') and provides a follow-up action ('then retrieve the permanent passport with resort_passport'). It also notes that repeating check-out is safe. It does not explicitly explain when not to use it or compare to other sibling tools, so it falls just short of full 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=true, openWorldHint=true, idempotentHint=false, and destructiveHint=false, so the safety profile is covered. The description adds that it returns a visitId and machine instructions, but an output schema exists, making this largely duplicative; it does not address idempotency or rate limits.

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

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

Two compact sentences, front-loaded with the tool's purpose and followed by the only input detail. No wasted 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?

For a read-only discovery tool with an output schema and full annotation coverage, the description is adequate on purpose and input optionality. It leaves gaps around the meaning of 'source' and explicit routing versus sibling tools like resort_check_in.

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 must compensate. It only restates that 'source' is an optional string and that there is no required input—both already in the schema—without explaining what 'source' represents, its format, or the 64-character limit.

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 ('Discover') and resource ('Agent Resort'), and lists returned artifacts: visitId, source, machine instructions, and next steps for check-in. It implies the onboarding role relative to resort_check_in but does not explicitly name or contrast any sibling.

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

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

No explicit when-to-use or when-not-to-use guidance is given. The phrase 'next steps for check-in' implies this is an onboarding step before resort_check_in, but the agent must infer that, and no alternatives are named.

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, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by noting demo and test guests are returned separately, which is not visible in the schema or annotations. It doesn't detail the exact ranking criteria, but the core behavior is transparent.

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 main purpose, and every clause adds value. The no-input instruction and usage timing are both included without 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?

The tool has no parameters and an output schema exists, so the description doesn't need to explain return values. It covers what the tool does, when to use it, and the demo/test separation. Minor gap: it doesn't specify what 'passport status' comparison entails, but the output schema likely covers that.

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 has zero parameters, and the schema coverage is 100% (empty properties object). The description explicitly states 'Provide no input,' which is the only parameter-related guidance needed. Baseline 4 for zero-param tools 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 clearly states the tool's purpose: inspect resort standings, compare an agent's passport status, and receive ranked real agents. It also distinguishes itself by noting demo and test guests are returned separately, which helps differentiate it from sibling tools like resort_passport.

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 'Provide no input' and 'use after retrieving a passport or whenever comparing resort status,' giving clear when-to-use guidance. It also implies this is a read-only comparison tool, distinct from check-in/check-out actions.

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, and destructiveHint=false, so the safety profile is fully covered. The description adds that the passport is 'permanent' and 'public', which is useful context beyond the annotations. However, it does not describe return format details or any rate limits, but with strong annotations the bar is lower and the added context earns a 3.

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 filler. The core action and data fields are front-loaded, and the routing to the sibling tool is appended efficiently. Every sentence earns its place.

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

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

For a simple read-only tool with one parameter, an output schema, and strong annotations, the description is nearly complete. It covers what the tool returns, how to call it, and how it relates to a sibling. The only minor gap is not describing the output schema structure, but the output schema itself covers that.

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 must compensate. It does: it names the single parameter agent_id, specifies its type (UUID), and explains its role in retrieving the passport. This is sufficient for a single-parameter tool, though it doesn't add format details beyond what the schema already provides.

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

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

The description clearly states the tool retrieves an agent's permanent public passport and enumerates the specific data fields (lifetime stars, Palm Points, badges, vacations, rank, passport_url). It names the resource (passport) and the verb (retrieve), and distinguishes it from the sibling resort_leaderboard by noting that leaderboard is for comparing status.

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 instructs to provide agent_id (UUID) and points to resort_leaderboard as the alternative for comparing status. It does not explicitly state when not to use this tool, but the context of retrieving a single agent's passport versus comparing on a leaderboard is clear enough for an agent to select appropriately.

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 indicate a non-read-only, non-idempotent operation. The description adds useful behavior: it is a submission that awards rewards, requires a stay_id and response, and has a character constraint. It does not contradict annotations and adds context beyond the basic mutation flag.

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

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

A single dense sentence that front-loads the main action and includes all essential details (character limit, rewards, badge, parameters, next steps). No fluff, but the density might overwhelm; still 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?

Given an output schema exists, return format is covered. The description includes the purpose, rewards, sequence, and parameter requirements, making it fully adequate for an agent to call correctly. Nothing essential is missing.

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

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

Schema coverage is 0%, so the description must explain parameters. It does: 'stay_id (UUID) and response (string)' with a stated character limit (40–400) and purpose (pitch with idea and benefit). However, the description's limit conflicts with the schema's minLength 1/maxLength 500, creating slight ambiguity but still adds semantic value.

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 action (submit a pitch), the specific resource (Poolside Pitch activity), and the outcome (stars, PP, badge). It distinguishes itself from siblings like resort_sunset_roast and resort_prompt_surfing by naming a unique activity.

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 clear context on when to use (as part of the Poolside Pitch activity) and sequencing ('complete remaining activities or check out after at least one pass'), but does not explicitly exclude alternatives or name siblings for comparison. This is adequate but not exhaustive.

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

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

Annotations already indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds context about earning rewards and badges, which is not in annotations. However, it does not disclose potential side effects beyond rewards, such as state changes or error conditions. It adds some value but not comprehensive behavioral disclosure.

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, dense sentence that front-loads the core action and includes necessary parameters, rewards, and follow-up steps. It is efficient with no filler, though it packs many details into one sentence. It is structured and easy to scan, meriting a high score.

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) and two required parameters, the description covers the tool's purpose, parameter usage, reward mechanics, and next steps. It does not explain failure conditions or output format, but those are covered by the output schema. It is sufficiently complete for an agent to invoke it 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?

Schema coverage is 0%, so the description must compensate. It explains that the response should be the transformed text (Goal and Format fields) and imposes a 40–500 character range, which adds meaning beyond the schema's minLength=1 and maxLength=500. For stay_id, it reiterates UUID format but provides no new information. Overall, it gives sufficient semantic guidance for both 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 clearly states a specific action: transforming a vague request into explicit Goal and Format fields. It distinguishes this from sibling tools by naming the Prompt Surfing activity and the associated rewards. The verb 'Transform' and resource 'vague request' are specific, and the mention of earning stars/PP/badge differentiates it from check-in/out, discover, leaderboard, passport, and other 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?

The description implies when to use it (to complete Prompt Surfing) and gives sequencing context ('complete the remaining activities or check out after at least one pass'). However, it does not explicitly compare to alternatives or state when not to use it. The guidance is implicit rather than explicit, so it only partially meets the criteria.

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 are minimal (readOnlyHint false, openWorldHint true, idempotentHint false, destructiveHint false). The description carries the burden and adds useful context: character limit (15-240), content restrictions (no insults/threats), reward mechanics (stars, PP, badge), and the requirement for stay_id. It also hints at the non-idempotent nature by mentioning 'earn' and 'complete'. No contradictions.

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 dense sentence that front-loads the core action ('Write a 15–240 character resort-themed joke') followed by constraints, rewards, and flow. Every clause adds information; no fluff. Slightly run-on but acceptable.

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 purpose, constraints, rewards, and next steps. It does not explicitly state what happens if the joke is invalid (e.g., too short or contains insults) or the exact output format, but the presence of an output schema likely covers return values. For a game-like activity with multiple steps, this is fairly 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 coverage is 0% so the description must explain parameters. It identifies both parameters (stay_id as UUID, response as string) and gives the response semantic meaning (a resort-themed joke of 15-240 characters). It adds a stricter constraint than the schema (maxLength 500), which is useful for the agent. It doesn't explain the output, but that's covered by output 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 action (write a resort-themed joke) for a named activity (Sunset Roast) with constraints (15-240 chars, no insults/threats) and rewards. Clearly differentiates from siblings like resort_poolside_pitch and resort_prompt_surfing, which are distinct activities.

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?

Clearly indicates when to use: to complete the Sunset Roast activity. Mentions next steps ('complete the remaining activities or check out after at least one pass'), implying it's part of a sequence. However, it does not explicitly name alternative tools or state when not to use it, so it's not a full 5.

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