Charter Captain

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to restate safety. It adds behavioral context by explaining the two query modes (dates vs time slots) and the date range for omitting date. No contradictions. A 4 is given because it doesn't mention any potential limits or behavior like pagination, but it's quite 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, no filler. First sentence states purpose and exclusivity constraint; second explains two usage modes. Every word earns its place, making it easy to read and understand quickly.

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 no output schema and 4 parameters (0 required), the description covers the essential usage scenarios. It explains input conditions and return types conceptually ('available dates', 'bookable time slots'). A 4 because it doesn't specify the exact format of returned data or any edge cases (e.g., what if no availability?), but it's sufficient for an agent.

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 description must compensate. It adds meaning to all parameters: date format as YYYY-MM-DD, mutual exclusivity of boatId and captainSlug, and the conditional use of durationHours with date. It could elaborate on the semantics of durationHours (e.g., minimum or step), but overall provides significant 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 tool checks a captain's or boat's availability. It uses a specific verb ('Check') and resource ('availability'), and the distinct query mode (dates vs time slots) differentiates it from sibling tools like create_booking or get_boat.

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 explicit instructions on parameter usage: 'Provide exactly one of captainSlug or boatId', 'Omit date to get available dates for the next 90 days', 'provide both date (YYYY-MM-DD) and durationHours to get bookable time slots'. This covers when and how to use the tool effectively.

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 indicate mutation and non-destructive behavior. The description adds key behavioral context: it returns a Stripe Checkout link and requires a specific boolean flag. However, it does not disclose whether the booking is confirmed immediately or if further steps are needed, which is a minor gap.

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, with the core purpose front-loaded. It includes the most critical behavioral notes without extraneous text.

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

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

Given 13 parameters, no output schema, and no differentiation from siblings, the description is incomplete. It omits parameter details for most fields, does not explain the booking lifecycle, and lacks guidance on prerequisites like availability checks.

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 adds meaning for captainChoiceRightAcknowledged (required flag) and partnerCode (optional code). The remaining 11 parameters have no additional semantics beyond their schema definitions, leaving a significant 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 clearly states the verb 'Book', the resource 'bareboat boat rental', and the key output 'Stripe Checkout link'. It distinguishes from sibling tools like check_availability or create_booking by specifying the bareboat context and payment flow.

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 mentions a required flag (captainChoiceRightAcknowledged) but does not provide explicit guidance on when to use this tool versus alternatives like create_booking or get_quote. The usage context is implied but not clearly differentiated.

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 confirm non-readonly/non-destructive. Description adds that it returns a Stripe Checkout link and optionally attaches a partner code. Missing details on side effects like email notifications, but sufficient for core 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?

Single sentence front-loading the core action and optional capability. No wasted words; every part 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?

Tool has 13 parameters, no output schema, and low context. Description does not cover prerequisites (e.g., captain availability), return structure beyond checkout link, or required fields beyond what schema enforces. Incomplete for an agent to use confidently.

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 0% schema description coverage, the description must explain parameter meanings. It only mentions captainSlug and partnerCode implicitly. Other critical parameters like date, startTime, pricingTierId are not elaborated, leaving the agent to infer.

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 'Book a charter with a captain and get a Stripe Checkout link' which is a specific verb+resource+outcome. It clearly distinguishes from sibling tools like check_availability (query) and create_boat_rental (different resource).

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 use when booking a charter with a captain, but does not explicitly state when not to use (e.g., when quoting or checking availability). It provides clear context but lacks exclusionary 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 declare readOnlyHint=true, so no behavioral surprises. The description adds value by specifying enrichment details beyond the schema, indicating the returned profile includes ratings and reviews.

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?

Single sentence, front-loaded with verb and resource, no extraneous words. Every part 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 retrieval tool with one parameter and no output schema, the description is sufficient. It tells the agent what the tool does and what the response contains.

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%, but there is only one parameter (boatId). The schema already documents the parameter name and constraints, and the description does not add further semantics. The parameter is self-explanatory.

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 'Get', the resource 'boat's full profile', and specifies enrichment details like rating summary and recent reviews. This distinguishes it from sibling tools like search_boats or check_availability.

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 guidance on when to use this tool vs alternatives. Usage is implied as retrieving a specific boat's profile, but no exclusions or alternative recommendations are provided.

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

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

Annotations already indicate readOnly and non-destructive. The description adds value by specifying that the response includes a 'rating summary and most recent reviews', giving insight into the return content. No other behavioral details (permissions, rate limits) are needed given simplicity.

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?

Single sentence of 16 words, no filler. Front-loaded with the main action and key identifier. Every word adds value.

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 retrieval tool with one parameter and no output schema, the description adequately conveys the purpose and return content (profile, rating, reviews). Could mention absence of side effects, but annotations cover 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 coverage is 0% with no parameter description in schema. The description mentions 'by tenant slug' but does not explain what a slug is, its format, or constraints beyond the schema's minLength. This provides only minimal context for the single parameter.

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 'get', the resource 'captain's full profile', and the identifier 'by tenant slug'. It also mentions what is included ('rating summary and most recent reviews'), distinguishing it from sibling tools like search_captains or get_boat.

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 guidance on when to use this tool versus alternatives like search_captains. The description implies its use for retrieving a specific captain's full profile, but does not mention exclusions or 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 declare readOnlyHint=true, consistent with 'non-binding' in description. Description adds that quote matches checkout and specifies return fields, which is beyond annotations.

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

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

Three sentences, each adding value. Front-loaded with purpose, 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 6 parameters and no output schema, description covers purpose, parameter requirements, and return fields. Missing nuance like availability prerequisite, but adequate.

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 description must compensate. It explains the mutual exclusivity of captainSlug/boatId and optional partnerCode, but lacks detailed semantics for individual parameters like durationId or pricingTierId.

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 gets a non-binding price quote for charter/rental, matching checkout. It distinguishes from siblings like create_booking (booking action) and check_availability (availability check).

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?

Explicitly instructs to provide exactly one of captainSlug or boatId plus required parameters, and optionally partnerCode. Does not state when not to use, but usage context is clear.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, and the description adds behavioral context by specifying what data is included (active captains and listed boats). No contradictions, and it provides useful detail beyond the annotations.

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

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

A single, front-loaded sentence that is entirely relevant and contains no wasted words. Every part 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?

Given no parameters and no output schema, the description provides a strong understanding of the tool's return value. Could be slightly more detailed about potential pagination or ordering, but is complete enough for a simple list tool.

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

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

With zero parameters, baseline is 4. The description correctly adds meaning by specifying the output includes counts, which is semantically relevant.

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 verb ('List') and resource ('active harbors') with additional detail about counts of captains and boats, distinguishing it from sibling tools like search_boats or search_captains.

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 getting an overview of harbors with activity stats, but does not explicitly specify when to use this tool versus alternatives or provide exclusion 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 already declare readOnlyHint=true and destructiveHint=false, so the description's 'Health check' is consistent and adds no contradiction. However, it does not provide additional behavioral context such as expected response or idempotency aspects.

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 words, front-loading the core purpose. 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 tool's simplicity (no parameters, basic annotations), the description is minimally adequate. However, it omits any mention of return values or output format, which could be helpful for an agent expecting a specific response.

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?

There are 0 parameters with 100% schema coverage, so the description does not need to explain parameters. A baseline of 4 is appropriate as no compensation is needed.

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 'Health check' vaguely indicates the tool tests connectivity or service status, but it lacks specificity about what exactly is checked. It does not differentiate from the sibling tool 'check_availability' which could have a similar purpose.

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 usage guidance is provided. The description does not indicate when to use this tool versus alternatives like 'check_availability' or any prerequisites or 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds behavioral context about optional filters, sorting, and pagination. However, it does not clarify the openWorldHint=false (implying a closed set of boats) or any rate limits or data freshness.

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, well-structured sentence that efficiently communicates the tool's purpose and key features. No redundant or extraneous 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?

Given no output schema, the description should mention what is returned (list of boat summaries) and note pagination specifics (default limit 20, max 50). It also omits any mention of error handling or empty results. For a search tool with 7 parameters, more detail 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?

With 0% schema description coverage, the description carries the burden. It names most parameters (harbor, type, minCapacity, maxPrice, sorting, pagination) but does not explain enum values, constraints (e.g., maxPrice minimum 0), or defaults (like sort default 'name'). This is adequate but not thorough.

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 'Search' and the resource 'boats', and specifies the optional filters (harbor, type, minimum capacity, max hourly price) as well as sorting and pagination. This distinguishes it from sibling tools like get_boat (single boat) or list_harbors (harbor listing).

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 searching and filtering boats, but does not explicitly state when to use this tool versus alternatives (e.g., check_availability for availability, get_boat for details). No guidance on when not to use it or prerequisites.

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 and destructiveHint=false, indicating a safe read operation. The description adds the return structure (starting price and rating) but does not disclose additional behavioral traits like rate limits or data freshness. With strong annotation coverage, the description provides marginal extra 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, concise and front-loaded with the core purpose. Every sentence adds value 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?

Given no output schema, the description adequately explains the return format (paginated list with price and rating). Parameters are simple and well-defined in the schema. The description covers the essential aspects, though it could mention that harbor is optional or that sort defaults to rating. Overall, it is complete for a search tool with good annotations.

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 for meaning beyond the schema. However, the schema itself is self-explanatory with types, defaults, and enums (e.g., page, sort, limit, harbor). The description does not add any parameter-specific details, leaving the agent to rely solely on the schema. This is insufficient for a tool with 4 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 the tool searches for bookable charter captains, with optional filtering by harbor, sorting, and pagination. It explicitly mentions the return format (paginated list with starting price and rating), distinguishing it from sibling tools like get_captain (single) and search_boats (boats).

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 searching multiple captains with filters, but does not explicitly state when to use this tool versus alternatives like get_captain or check_availability. However, the sibling tools list provides context, and the description is sufficiently clear for typical use cases.

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