Harris Boat Works - Mercury Repower

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

No annotations are provided, so the description must carry the burden. It mentions returning a deep-link URL and optionally capturing a lead in CRM, but does not disclose whether the tool is read-only or creates/destroys data, nor any side effects or required permissions.

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

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

The description is short and front-loaded with the core purpose. However, the second sentence could be integrated better, and the lack of parameter explanation means some conciseness is achieved at the expense of clarity.

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 7 parameters (including nested objects) with no detailed explanations, the description leaves significant gaps. It doesn't cover the required parameters, return value format beyond 'deep-link URL', or behavior for optional vs required fields.

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 fails to compensate. It lists components (e.g., installation, propeller, HST) that are not in the schema, creating confusion. The schema has 7 parameters including nested objects, but the description does not clarify their meanings or relationships.

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 builds an itemized CAD quote with specific components (motor, installation, propeller, etc.) and returns a deep-link URL. This distinguishes it from siblings like estimate_trade_in or search_motors, which handle different aspects of the domain.

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 generating quotes and capturing leads, but does not explicitly state when to use this tool versus alternatives like estimate_trade_in. No exclusions or prerequisites are mentioned, so the guidance is only implied.

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

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

With no annotations, the description carries the full burden. It discloses brand penalties and currency (CAD), but lacks details on return format, read-only nature, error handling, or rate limits. Some transparency is provided, but significant gaps remain.

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 efficiently conveys purpose and key behavioral notes (brand penalties). It is front-loaded and contains no unnecessary 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?

Given 6 parameters and no output schema or annotations, the description is incomplete. It does not explain the return value structure, calculation factors beyond brand, or limitations. The agent lacks essential context to fully understand the tool's behavior.

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 has 6 parameters with 0% description coverage. The description only adds meaning for 'brand' via brand penalties. Parameters like 'year', 'horsepower', 'condition', 'engine_type', and 'engine_hours' are not explained, leaving the agent without guidance on their values or constraints.

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: 'Estimate the trade-in value (CAD) of a customer's current outboard.' The verb 'estimate' and resource 'trade-in value' are specific, and the tool is distinct from siblings like 'build_quote' or 'get_brand_rules'.

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 estimating trade-in values but does not explicitly state when to use this tool versus alternatives like 'build_quote' or 'get_brand_rules'. No exclusions or context for when not to use it 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?

No annotations provided, so the description must fully disclose behavior. It states return value but doesn't explicitly mention that the tool is read-only or has no side effects, though it's inferable.

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, well-structured, lists rule categories concisely with no redundant 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 zero parameters and no output schema, the description fully explains what the tool returns, making it 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?

No parameters exist and schema coverage is 100%, so baseline is 4. The description adds no param info, but none 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 clearly states the tool returns authoritative rules for Harris Boat Works, listing specific rule categories (pricing currency, geography, etc.), and distinguishes from siblings like build_quote and search_motors.

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

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

Usage is implied (retrieve rules before agent tasks), but no explicit guidance on when to use versus alternatives 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?

With no annotations, the description carries the behavioral burden. It implies a read-only fetch but does not disclose potential errors, rate limits, or response size. Adequate for a simple tool.

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

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

Single sentence, no wasted words, front-loaded with verb and resource.

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 fetch tool with no output schema, the description is complete: it identifies the resource, selection criteria, and included data.

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

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

Schema coverage is 100%, but the description adds value by explaining that one of id or slug is sufficient ('by id or slug') and listing the return fields, which is beyond schema.

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

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

The description clearly states it fetches a single Mercury motor by id or slug, and specifies the included data (pricing, shaft length, deep-link URL). This is specific and distinguishes it from sibling search_motors.

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 you need a single motor by ID or slug, providing clear context. However, it does not explicitly exclude cases or mention alternatives.

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

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

With no annotations, the description carries the full burden. It discloses that it is a read operation (search), returns CAD pricing, and excludes Verado. It mentions filtering capabilities but does not specify result format, pagination, or authentication requirements, which would enhance 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 two sentences, front-loaded with the core purpose, and contains no filler. Every sentence adds value: first sentence defines scope, second lists filters and pricing.

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 has 6 parameters, no output schema, and no annotations, the description provides adequate context: domain, inventory type, pricing, and filtering. It could mention the 'limit' parameter and return fields, but overall it is complete enough for basic 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?

Schema coverage is only 17%, so the description compensates by explaining that filtering is by horsepower, family (listing enum values), and stock status. It adds meaning beyond the schema for 'family' and 'in_stock_only', but does not explicitly cover 'limit', 'max_hp', or 'min_hp'.

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 searches Mercury outboard inventory at a specific dealer, with filtering options, pricing, and exclusions. It uses a specific verb ('Search') and resource ('current Mercury outboard inventory at Harris Boat Works'), distinguishing it from siblings like 'get_motor' which likely retrieves a single motor.

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 (searching inventory) but does not explicitly state when to use this tool versus alternatives like 'get_motor' or 'build_quote'. No when-not-to-use or exclusion criteria beyond not including Verado.

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