Live Mercury outboard data and CAD quote builder from a Mercury Platinum Dealer in Ontario.
Scored across 5 tools
Each tool serves a distinct purpose: searching motors, fetching a specific motor, estimating trade-in, building quotes, and retrieving brand rules. No two tools have overlapping functionality; even build_quote and estimate_trade_in are clearly separated.
All tool names follow the verb_noun pattern in snake_case (build_quote, estimate_trade_in, get_brand_rules, get_motor, search_motors). The pattern is consistent and predictable.
Five tools is well-scoped for the narrow domain of Mercury repower quoting. Each tool covers a core step (search, detail, trade-in, quote, rules) without redundancy or missing essentials.
The tool set covers the full repower workflow: finding motors, retrieving details, estimating trade-in, building a quote with all components, and accessing business rules. There are no obvious gaps like missing payment handling or customer management, which are outside the stated purpose.
Build an itemized CAD quote (motor + installation + propeller + trade-in + HST + financing tier) and return a deep-link URL the customer can open. Optional contact captures a lead in the dealership CRM.
| Name | Required | Description | Default |
|---|---|---|---|
| family | No | ||
| contact | No | ||
| motor_id | No | ||
| trade_in | No | ||
| boat_info | No | ||
| horsepower | No | ||
| purchase_path | No | installed | |
| customer_has_propeller | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the side effect of capturing a lead in the CRM when contact is provided, and states the return of a deep-link URL. It does not mention other potential side effects but covers the main behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, direct, and includes the essential information about the tool's purpose, return, and side effect without unnecessary 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 complexity of 8 parameters, nested objects, and an enum, the description provides insufficient context about parameter relationships, defaults, and required fields. It does not mention that only contact is optional or that purchase_path defaults to 'installed'.
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 no schema coverage, the description should explain each parameter, but it only clarifies that contact is optional and captures a lead. Other parameters like family, motor_id, trade_in, boat_info, horsepower, purchase_path, and customer_has_propeller remain unexplained, relying on naming conventions.
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 builds an itemized CAD quote and returns a deep-link URL, differentiating it from sibling tools that estimate, get, or search for specific data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus the sibling tools (e.g., when to use get_motor or estimate_trade_in). It implies it is the main action but lacks direct comparison or conditional usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate the trade-in value (CAD) of a customer's current outboard using the live Harris Boat Works valuation. Horsepower may be omitted when the model infers a single validated HP.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | ||
| brand | Yes | ||
| model | No | ||
| condition | No | ||
| horsepower | No | ||
| engine_type | No | ||
| engine_hours | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions the 'live Harris Boat Works valuation' and the conditional horsepower omission, which are useful behavioral cues, but it does not explicitly state side effects, read-only nature, or failure/error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two focused sentences with no redundant or extraneous content. It efficiently communicates the core purpose and a key parameter nuance.
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?
There is no output schema or return-value description, and most parameter semantics are missing. For a tool with 7 parameters and no annotations, the description provides insufficient context for an agent to invoke it correctly and interpret results.
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 parameter descriptions are absent, and the description only clarifies that horsepower may be omitted in a specific case. The remaining parameters—brand, year, model, condition, engine_type, and engine_hours—are left unexplained.
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's purpose: 'Estimate the trade-in value (CAD) of a customer's current outboard' with a specific verb and resource. It does not explicitly distinguish itself from sibling tools such as search_motors or build_quote, though the trade-in focus is fairly evident.
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 only usage note is 'Horsepower may be omitted when the model infers a single validated HP,' which addresses one parameter condition. There is no guidance on when to choose this tool over alternatives like search_motors or build_quote.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return Harris Boat Works' authoritative source-of-truth rules for any agent representing them: pricing currency, geography, no-Verado policy, financing minimums, deposit tiers, warranty.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description fully discloses what the tool returns (authoritative rules list) without omissions. No mention of side effects or auth, but for a zero-param read tool, this is adequate. Could note non-destructive nature.
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 key info, no fluff. Every word 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 zero parameters, no output schema, and simple purpose, description is fully complete. Sibling tools confirm distinct operations.
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. Baseline is 4. Description adds context by listing what rules are returned, providing meaning beyond the empty 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?
Description uses specific verb 'Return' and resource 'Harris Boat Works' authoritative source-of-truth rules', listing exact categories (pricing, geography, no-Verado policy, etc.). Clearly distinguishes from sibling tools like build_quote or 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?
No explicit when/when-not or alternatives mentioned. However, the description implies usage for retrieving brand rules, and sibling list provides implicit differentiation. Lacks direct guidance like 'use this instead of X'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single Mercury motor by id or slug, including pricing, shaft length, and deep-link URL.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | UUID of the motor | |
| slug | No | URL slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only describes the operation as a fetch and lists returned fields, but does not disclose behavior like selection logic when both id and slug are provided, authentication needs, 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?
The description is a single, well-structured sentence that is front-loaded with the action and resource. It contains no unnecessary words or repetitions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists a few return fields but does not provide a complete view of the output structure. Without an output schema, the agent may miss other important fields in the response. For a simple fetch, it is adequate 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?
Schema coverage is 100% (both parameters described in schema). The description reinforces that either id or slug can be used, but adds no additional semantic meaning 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 uses a specific verb ('Fetch') and resource ('single Mercury motor'), and distinguishes itself from sibling tools like search_motors (which likely returns multiple) by focusing on individual retrieval by id or slug. It clearly states what data is included.
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 explicitly state when to use this tool versus siblings (e.g., search_motors). It implies use when a single motor's details are needed, but lacks guidance on exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search current Mercury outboard inventory at Harris Boat Works (Ontario). Filter by horsepower, family (FourStroke, Pro XS, SeaPro, Racing), or stock status. Returns CAD pricing. Excludes Verado.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| family | No | ||
| max_hp | No | ||
| min_hp | No | ||
| horsepower | No | Exact HP (e.g. 90, 150) | |
| in_stock_only | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses non-obvious behaviors (CAD pricing, Verado exclusion) but does not mention pagination, response format, or behavior on empty results.
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 extraneous words, front-loaded with key information. Every sentence is essential.
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 with 0 required, no output schema, and no annotations, the description provides reasonable coverage of purpose and main filters but lacks details on parameter interactions (e.g., min_hp vs max_hp vs horsepower) and result handling.
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 low (17%), but the description lists key filtering dimensions (horsepower, family, stock status). However, it does not explain parameters like limit, min_hp, or max_hp beyond the schema defaults.
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 (Harris Boat Works) with filters. It distinguishes from siblings like get_motor and build_quote.
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 explains what filters are available and mentions CAD pricing and Verado exclusion, but does not explicitly state when to use versus alternative tools. However, the context from sibling names provides implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
build_quote1 field changedInput schema / properties / customer_has_propellerAdded value: +{
+ "type": "boolean"
+}estimate_trade_in6 fields changedInput schema / properties / engine_type / enumPrevious value: -[
- "4-stroke",
- "2-stroke"
-]New value: +[
+ "4-stroke",
+ "2-stroke",
+ "proxs",
+ "optimax",
+ "etec"
+]Input schema / properties / modelAdded value: +{
+ "type": "string"
+}Input schema / properties / year / maximumAdded value: +2026Input schema / properties / year / minimumAdded value: +1950Input schema / properties / year / typePrevious value: -"number"New value: +"integer"Input schema / requiredPrevious value: -[
- "brand",
- "year",
- "horsepower"
-]New value: +[
+ "brand",
+ "year"
+]build_quoteestimate_trade_inget_brand_rulesget_motorsearch_motorsLive Canadian vehicle listings, VIN decode and market valuations, province by province.
Search Canadian hunting and fishing outfitters, check availability, and send price requests.
Live franchised-dealer inventory, quotes, and consented salesperson handoffs.
Instant Canadian scrap-car value quotes by year/make/model, provincial rates, and pickup leads.
Add one secure layer between your agents and this server.
