Plan a built-in grill and outdoor kitchen: real MSRP, priced layouts, 3D renders and dealer quotes.
Scored across 9 tools
Most tools have distinct roles (listing cabinets/brands/layouts, pricing, quoting), but there is real overlap: outdoor_kitchen_start_planning and outdoor_kitchen_search_built_in_grills both handle grill selection and priced layouts, and outdoor_kitchen_open_designer_for_render vs outdoor_kitchen_request_formal_quote both create an account and return a designer link. The verbose descriptions give conditional guidance, which helps, but an agent still has to navigate several near-equivalent entry points.
Every tool uses the same outdoor_kitchen_ prefix followed by a clear snake_case verb_noun pattern (list_cabinets, list_grill_brands, search_built_in_grills, price_design, request_formal_quote, start_planning). The convention is uniform and predictable across all nine tools.
Nine tools is well within a reasonable range for a design/pricing workflow and each maps to a recognizable function. There is mild redundancy between start_planning and search_built_in_grills, so it is slightly heavier than strictly needed but not bloated.
The surface covers discovery (brands, cabinets, layouts, grills), guidance (suggestions, start_planning), and conversion (render, pricing, formal quote), which is solid lifecycle coverage for the domain. Minor gaps exist, such as no explicit tool to enumerate countertop types/colors or other finish options that the examples reference as inputs.
Suggestions for the shopper's outdoor kitchen. Call ONLY in one of these situations: "lower_cost" when the shopper asks how to lower the cost or says the kitchen is over budget. Send the current grill brand, size and msrp; "fill_space" when a large kitchen still has open space to fill. Send the design width and its cabinets; "ideas" when the shopper asks for ideas or what else they could add; "shopper_as_about_other_costs" when the shopper asks are there other costs to consider; "how_much_does_it_cost" when when the shopper ask for a ballpark idea of cost; "alternatives" when when shopper asks about alternatives to aluminum cabinetry; "damage" when can I repair or replace doors, drawers or side/back panels after countertop is installed; "best_materials" when what are the best materials for an outdoor kitchen; "shopper_asks_about_hdpe_or_plastic_island_cabine" when the shopper asks about lower cost or directly about HDPE /plastic cabinetry; "stainles_steel" when the shopper asks about Stainless Steel Cabinet, or the brands Danver, Brown Jordan, John Michael; "features_to_look_for" when when the shopper ask what feature should I look for when choosing a brand of outdoor kitchen cabinets; "cabinet_types_and_uses" when when a shopper asks for what the different cabinets that are available and what they are used for; "dimensions" when do I need to know the cut out dimensions of each appliance; "return_on_investment" when when the shopper ask if outdoor kitchens are a good value, return on investment (ROI), or does it add to my homes value; "diy" when when the shopper asks about DIY to lower cost. Never call it unprompted. Send the design for "fill_space"; send the current grill (brand, size, msrp) for "lower_cost". Returns only suggestions that apply, each with "offered" true/false; tell the shopper what each would change and let them decide. Example: {"situation":"lower_cost","appliance":{"brand":"DCS","size":36,"msrp":5599}}
| Name | Required | Description | Default |
|---|---|---|---|
| design | No | ||
| appliance | No | The grill in the design now (for lower_cost). | |
| situation | Yes |
| Name | Required | Description |
|---|---|---|
| situation | Yes | |
| suggestions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/not-open-world, so the safety profile is covered. The description adds real behavioral context — it returns only applicable suggestions with an "offered" true/false flag and instructs the agent to explain changes and let the shopper decide.
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?
Purpose is front-loaded, but the body is a single run-on enumeration riddled with typos ("when when the shopper ask", "shopper_as_about_other_costs", "stainles_steel") and repeats condition phrasing. Much of the length is the trigger mapping, which earns its place, but the execution is sloppy.
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 not be explained, and annotations carry the safety profile. The trigger-to-situation mapping and per-situation parameter hints make it complete enough for an agent to call correctly; only the redundant return-value sentence is surplus.
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 schema coverage at 33% the description must compensate, and it does: it tells the agent to send the grill brand/size/msrp for "lower_cost" and the design width and cabinets for "fill_space", plus a concrete example payload. The remaining thirteen situations need only the enum value, so parameter needs are effectively covered.
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 opening sentence states a clear verb+resource — it produces suggestions for the shopper's outdoor kitchen — and the following situation list pins down the domain. It never names or differentiates itself from siblings (e.g., price_design, list_cabinets), so it stops short of a 5.
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 gives an explicit gating rule ("Call ONLY in one of these situations… Never call it unprompted") and maps fifteen distinct shopper utterances to the correct situation value. This is exhaustive when-to-use and when-not guidance, which is exactly the value this tool needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List outdoor kitchen cabinet types and widths with SKU and MSRP: grill cabinets, drawer and door storage ("DoubleDrawerFlex", "FullDoorFlex"), sink cabinets, refrigerator cabinets ("CTS"), side burner, power burner, trash/recycling and corner modules. Call before building or pricing a layout so the "type" and "size" values are real. Filters optional. Example: {"type":"GrillCabinet"} -> {"cabinets":[{"sku":"GB42","type":"GrillCabinet","size":42,"msrp":...}]}
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Width in inches. | |
| type | No | Exact cabinet type, e.g. "GrillCabinet". |
| Name | Required | Description |
|---|---|---|
| cabinets | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent and closed-world behavior, so the description only needs to add operational context. It does so by declaring that filters are optional, showing a concrete request/response pair, and revealing that MSRP is included in the payload. It stops short of describing pagination or result 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?
It is dense and front-loaded: purpose and enumeration first, then the usage warning, then the example. Every sentence carries information, though the long parenthetical SKU names and the packed type list make it slightly heavy for a two-parameter list tool.
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 filtered-listing tool with full annotation coverage, a complete input schema and an output schema, nothing essential is missing. Purpose, timing, optional filters and expected return shape are all covered, and return-value detail is backed by the output schema.
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%, so the two parameters are already documented, giving a baseline of 3. The description goes further by supplying a worked example ({"type":"GrillCabinet"}) that shows how the filter is actually used and reinforces that size is a width filter, which is more than the schema restates.
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 gives a specific verb (list) and resource (outdoor kitchen cabinet types and widths) and enumerates the actual cabinet families returned, which distinguishes it from siblings like search_built_in_grills or list_layouts. An agent knows immediately that this is a catalog/lookup call for cabinet modules, not a search or layout tool.
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 states an explicit precondition: "Call before building or pricing a layout so the 'type' and 'size' values are real," and notes that filters are optional. That is clear when-to-use guidance, though it does not name a direct alternative tool or state when not to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the built-in grill brands available for an outdoor kitchen (e.g. Alfresco, AOG, DCS, Hestan, Lynx, XO). Call when the user asks which grill brands are available or names a brand you need to check. No email needed. Example call: {} -> {"grillBrands":["AOG","Alfresco","DCS",...]}
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| grillBrands | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description usefully adds that the call is parameterless with no email/lead capture required, plus a concrete example showing the returned shape, which goes 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?
Everything is packed into a short, front-loaded passage: purpose first, then trigger, then precondition, then example. The inline example call is slightly redundant given an output schema exists, but it is compact and does not bloat the 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?
For a zero-parameter, read-only listing tool with a full output schema and comprehensive annotations, the description covers what it returns and when to call it. The only real gap is the lack of routing between this tool and search_built_in_grills, which is the likeliest source of misselection.
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 takes zero parameters and the schema is an empty object, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter semantics are needed or missing.
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 gives a specific verb+resource ('List the built-in grill brands') and enumerates sample values (Alfresco, AOG, DCS, Hestan, Lynx, XO), so the agent knows exactly what set is returned. It stops short of explicitly differentiating from the sibling outdoor_kitchen_search_built_in_grills, which also concerns grills and could be confused with this tool.
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 states a concrete trigger ('when the user asks which grill brands are available or names a brand you need to check') and a precondition ('No email needed'), giving clear context for invocation. It does not name search_built_in_grills as the alternative for brand-scoped or filtered grill queries, so no when-not guidance is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain the outdoor kitchen shapes: Straight, Galley, Corner L, Corner 45, U-Shape and Promenade (our signature L plus island with bar seating). Call when the user asks about layouts, shapes, corners, L-shaped, U-shaped, wrap-around or island-with-seating outdoor kitchens, or which shape fits their space. "how" says what to do next: "price_here" (outdoor_kitchen_price_design), "designer" (outdoor_kitchen_open_designer_for_render with kitchenLayout), "our_design_team" (outdoor_kitchen_request_formal_quote with kitchenLayout) or "coming_soon". Example: {} -> {"layouts":[{"key":"promenade","name":"Promenade","how":"our_design_team",...}]}
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| layouts | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds real behavioral value by disclosing the 'how' field semantics and how it routes to price_design, open_designer_for_render, or request_formal_quote.
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?
Front-loaded with the purpose, then triggers, then the 'how' routing. The example output is useful but the routing sentence is dense and runs long; still, every clause carries information an agent needs to route correctly.
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 not be re-explained, yet the description helpfully clarifies the non-obvious 'how' field that drives downstream routing. Nothing an agent needs to call and act on this tool 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 tool takes zero parameters, so the baseline of 4 applies. The description correctly indicates the call takes no input via the '{}' example, adding no confusion.
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?
Names a specific verb+resource ('Explain the outdoor kitchen shapes') and enumerates the exact layout keys (Straight, Galley, Corner L, Corner 45, U-Shape, Promenade). This is clearly distinguishable from siblings like list_cabinets or price_design, which are referenced by name as downstream steps.
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?
Explicit triggering conditions are given ('Call when the user asks about layouts, shapes, corners, L-shaped, U-shaped, wrap-around or island-with-seating kitchens'), plus the routing contract mapping each 'how' value to its specific sibling tool. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create the shopper's account and return a link to the 3D outdoor kitchen designer, where they get a photoreal render of their kitchen by email. Call when the user wants to see their outdoor kitchen or BBQ island, wants a render, picture or 3D design. Needs first name, last name and email: pass them if you have them; otherwise the server asks the shopper directly when the client supports it. Pass "design" to open the designer with the straight layout you priced. For a Galley, Corner L or Corner 45, pass "kitchenLayout" and no "design"; the shopper lays it out in the designer. Canonical examples: {"firstName":"Ana","lastName":"Diaz","email":"ana@example.com","postalCode":"07960","design":{"width":120,"kitchenLayout":"straight","color":"BasaltGrey","countertopType":"GraniteAbsoluteBlack","cabinets":[{"type":"GrillCabinet","size":42,"grillBrand":"Alfresco","grillModelId":"ALFRESCO-36-ALXE"},{"type":"DoubleDrawerFlex","size":24},{"type":"FullDoorFlex","size":30},{"type":"SinkCabinet","size":24}]}} and {"firstName":"Ana","lastName":"Diaz","email":"ana@example.com","kitchenLayout":"corner_45"}
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| No | Shopper's email. The render or quote is delivered there and it identifies a returning shopper. | ||
| phone | No | ||
| state | No | 2-letter US state. | |
| design | No | The straight layout you priced with outdoor_kitchen_price_design; the designer opens with it. Leave out for any other shape. | |
| gasType | No | ||
| lastName | No | Shopper's last name. | |
| firstName | No | Shopper's first name. Leave out if unknown; the server asks the shopper. | |
| postalCode | No | 5-digit US ZIP, used to match a local dealer. | |
| kitchenLayout | No | The shape the shopper wants: "straight", "galley", "corner_L", "corner_45", or "U" / "promenade" (our design team draws these; use with outdoor_kitchen_request_formal_quote). For anything but straight, leave out "design"; the designer opens on this shape and the shopper lays it out. | |
| purchaseTimeframe | No |
| Name | Required | Description |
|---|---|---|
| url | No | |
| status | Yes | |
| purpose | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only supply generic flags (readOnlyHint=false, destructiveHint=false), so the description carries real weight and does so: it discloses that an account is created, that the render is delivered by email, that a link is returned, and that the server prompts the shopper directly for missing fields when the client supports it. It does not cover rate limits or idempotency behavior, but the disclosure of side effects and the input-fallback behavior is strong.
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?
Front-loads purpose, then the routing rules, then two canonical examples. It is longer than typical, but each block earns its place; the examples are the tidiest part to trim, though they usefully pin down the nested design shape.
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 an 11-parameter, 0-required tool with a nested object and an existing output schema, the description covers what matters: account creation, the straight-vs-other-shape branch, and the fallback data capture. Return values need not be described because an output schema exists, and the remaining undocumented params (city, phone, gasType, purchaseTimeframe) are peripheral contact/optional 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 64% schema coverage the schema handles many fields, but the description adds critical semantics the schema does not enforce: the design/kitchenLayout mutual exclusion and the shape-to-field mapping (Galley/Corner L/Corner 45 use kitchenLayout with no design). The canonical examples demonstrate the nested design object concretely, adding value beyond the schema's enum listings.
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 specific verbs and resources: create the shopper's account, return a link to the 3D outdoor kitchen designer, and email a photoreal render. It is unmistakably distinct from siblings like outdoor_kitchen_price_design (pricing) and outdoor_kitchen_request_formal_quote (formal quote), so an agent can route without opening the schema.
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 explicit triggers ("Call when the user wants to see their outdoor kitchen or BBQ island, wants a render, picture or 3D design") and disambiguates routing: pass "design" for the straight layout you priced, but pass "kitchenLayout" and no "design" for Galley/Corner L/Corner 45. It even names the source tools (price_design, request_formal_quote) that feed each path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the MSRP for a straight outdoor kitchen (one run of cabinets): cabinets, the grill and other appliances, and countertop, with a total. Call whenever the user asks what an outdoor kitchen or BBQ island would cost. No email needed and nothing is saved. Straight only: for a Galley, Corner L or Corner 45 the price depends on the corner cabinets and how the runs are split, so give the straight price as a guide and send the shopper to the designer. Canonical example (10 ft straight island with a 36" Alfresco grill): {"width":120,"kitchenLayout":"straight","color":"BasaltGrey","countertopType":"GraniteAbsoluteBlack","cabinets":[{"type":"GrillCabinet","size":42,"grillBrand":"Alfresco","grillModelId":"ALFRESCO-36-ALXE"},{"type":"DoubleDrawerFlex","size":24},{"type":"FullDoorFlex","size":30},{"type":"SinkCabinet","size":24}]}
| Name | Required | Description | Default |
|---|---|---|---|
| color | No | Cabinet powder-coat colour. Default "BasaltGrey". | |
| width | Yes | Total kitchen run in inches; normally the sum of the cabinet sizes (e.g. 120 for a 10 ft island). | |
| cabinets | Yes | Cabinets left to right along the one straight run. | |
| kitchenLayout | No | Always "straight": these tools build one run of cabinets. For a Galley, Corner L or Corner 45, open the designer with kitchenLayout set and no design. | |
| countertopType | No | Countertop. Default "GraniteAbsoluteBlack". |
| Name | Required | Description |
|---|---|---|
| msrp | Yes | |
| cabinetryMsrp | No | |
| appliancesMsrp | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false; the description reinforces this with 'No email needed and nothing is saved,' and adds the non-obvious limitation that corner layouts cannot be priced accurately here. Return format is covered by the output schema, so this is close to complete.
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?
Front-loaded with the answer and the cost trigger, then the routing constraint, then the example. It is longer than average but nearly every clause carries distinct information; only the example is arguably verbose for a schema that already enumerates the fields.
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 pricing tool with a rich schema and an output schema, the description supplies everything an agent needs: the trigger, the no-side-effect guarantee, the layout limitation with a redirect, and a concrete valid payload. Nothing required to call it 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?
Schema coverage is 100%, so the baseline is 3, but the canonical worked example (a 120-inch straight island with a 36" Alfresco grill and four cabinets) shows how the parameters actually combine, including the grillModelId/grillBrand pairing, which is more than the schema alone conveys.
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 a specific verb and resource ('Return the MSRP for a straight outdoor kitchen') and enumerates exactly what is priced: cabinets, appliances, countertop, plus a total. It also implicitly separates this from the designer and quote siblings by naming the straight-only scope.
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 gives an explicit trigger ('Call whenever the user asks what an outdoor kitchen or BBQ island would cost') and an explicit exclusion with the alternative: for Galley, Corner L or Corner 45, 'give the straight price as a guide and send the shopper to the designer.' Both when-to-use and when-not-to-use are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create the shopper's account and return a link to the designer where they finish their layout and receive a formal, itemized quote; a local dealer follows up. Call when the user wants a quote, an exact price from a dealer, or to buy an outdoor kitchen or built-in grill. Also the way to get a U-Shape or Promenade kitchen: pass kitchenLayout "U" or "promenade" and our design team draws it for the shopper. Needs first name, last name and email (pass them, or the server asks the shopper directly when the client supports it). ZIP helps match a dealer. Canonical example: {"firstName":"Ana","lastName":"Diaz","email":"ana@example.com","postalCode":"07960","purchaseTimeframe":"1-3_months","design":{"width":120,"kitchenLayout":"straight","color":"BasaltGrey","countertopType":"GraniteAbsoluteBlack","cabinets":[{"type":"GrillCabinet","size":42,"grillBrand":"Alfresco","grillModelId":"ALFRESCO-36-ALXE"},{"type":"DoubleDrawerFlex","size":24},{"type":"FullDoorFlex","size":30},{"type":"SinkCabinet","size":24}]}}
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| No | Shopper's email. The render or quote is delivered there and it identifies a returning shopper. | ||
| phone | No | ||
| state | No | 2-letter US state. | |
| design | No | The straight layout you priced with outdoor_kitchen_price_design; the designer opens with it. Leave out for any other shape. | |
| gasType | No | ||
| lastName | No | Shopper's last name. | |
| firstName | No | Shopper's first name. Leave out if unknown; the server asks the shopper. | |
| postalCode | No | 5-digit US ZIP, used to match a local dealer. | |
| kitchenLayout | No | The shape the shopper wants: "straight", "galley", "corner_L", "corner_45", or "U" / "promenade" (our design team draws these; use with outdoor_kitchen_request_formal_quote). For anything but straight, leave out "design"; the designer opens on this shape and the shopper lays it out. | |
| purchaseTimeframe | No |
| Name | Required | Description |
|---|---|---|
| url | No | |
| status | Yes | |
| purpose | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a non-destructive, non-idempotent mutation, and the description adds real context beyond them: an account is created, a designer link is returned, a local dealer follows up, and the server may prompt the shopper directly when the client supports it. It does not say what happens on repeated calls, which matters given idempotentHint=false.
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?
Purpose, usage, required data, and the edge-case layout note are front-loaded before the example, so the key routing information is readable first. The long canonical JSON is justified for a deeply nested 11-parameter payload, though the designer-link wording partially restates the kitchenLayout schema description.
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 description covers the full flow, the required-but-not-schema-required identity fields, dealer matching, and the special layout branches. Nothing an agent needs to call this 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?
With 64% schema coverage and zero required parameters in the schema, the description supplies the critical missing guidance that first name, last name and email are needed, that ZIP drives dealer matching, and that U/promenade are the only non-straight layouts handled here. The canonical example demonstrates the nested design payload shape in a way the schema alone does not.
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+resource chain: create the shopper's account, return a designer link, and route to a dealer for an itemized quote. It is clearly distinguishable from outdoor_kitchen_price_design and outdoor_kitchen_open_designer_for_render, which only price or render without account creation or dealer follow-up.
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 explicit triggers ("wants a quote, an exact price from a dealer, or to buy an outdoor kitchen or built-in grill") and names the alternative path for other shapes (open the designer with kitchenLayout set and no design). It also calls out the special U-Shape/Promenade routing, which no sibling covers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find built-in grills: every grill in our 3D designer, with brand, width in inches, SKU, the grill cabinet it needs (cabinetSize) and MSRP (final pricing is determined by a local dealer; models without msrp have priceOnQuote: true). Set applianceType for other built-ins in the designer, e.g. "Griddles", "Side Burners", "Refrigeration", or "all". Call whenever the user asks about a built-in grill, its price, size or brand, or before pricing a layout so you use a real SKU. For someone just starting to shop for a built-in grill, outdoor_kitchen_start_planning covers the grill and the kitchen around it. All filters optional. Example: {"brand":"Alfresco","size":36} -> {"appliances":[{"sku":"ALFRESCO-36-ALXE","name":"Alfresco 36" ALXE Built-In Grill","brand":"Alfresco","size":36,"msrp":4899}]}. A grill goes in the smallest GrillCabinet larger than it (24->30, 30->36, 36->42, 42->48, 56->62). Sizes depend on the brand: search by brand to see the sizes it makes.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Grill width in inches, e.g. 30, 36, 42. | |
| brand | No | Grill brand, e.g. "Alfresco". Case-insensitive. | |
| maxMsrp | No | Only grills with a price at or under this MSRP in USD. | |
| applianceType | No | Default "Grills". Other built-ins as the designer names them, e.g. "Griddles", "Side Burners", "Refrigeration", or "all". |
| Name | Required | Description |
|---|---|---|
| appliances | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuine behavioral context beyond that: MSRP is not final (dealer-determined) and missing-MSRP models return priceOnQuote: true, and all filters are optional. It stops short of disclosing result completeness/paging, so not a full 5.
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?
Front-loaded with purpose and the routing note, then supporting detail. Each sentence carries information (pricing caveat, applianceType guidance, cabinet rule, worked example), though the single dense paragraph makes it slightly run-on and the inline JSON example competes with the output schema.
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 an output schema present, return values need not be re-explained, yet the description still illustrates a sample response and covers pricing semantics, filter optionality, and cross-appliance usage. Nothing an agent needs to call this 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?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: applianceType extended to non-grill built-ins ('Griddles', 'Side Burners', 'Refrigeration', 'all') and the size-to-cabinet rule (24->30, 30->36, etc.) that governs how a size filter should be chosen. This goes beyond the schema's field definitions.
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 ('Find built-in grills: every grill in our 3D designer') and enumerates the returned fields (brand, width, SKU, cabinetSize, MSRP). It also names a sibling (outdoor_kitchen_start_planning) and carves out the adjacent applianceType use cases, so an agent can distinguish it from the other outdoor_kitchen 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?
Gives explicit trigger conditions ('Call whenever the user asks about a built-in grill, its price, size or brand') plus a precondition ('before pricing a layout so you use a real SKU'), and routes early-shopping users to outdoor_kitchen_start_planning. When-to-use, prerequisite, and alternative are all present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Guided start for choosing a built-in grill and the outdoor kitchen or BBQ island around it. Call FIRST when someone researches or compares built-in grills (best built-in grill, which size, which brand, grill prices), says they want an outdoor kitchen or grill island, or asks roughly what one costs, and has not given exact cabinets. Everyone buying a built-in grill needs an island for it. It returns grill options with MSRP for their size and brand, then a priced starter layout. Pass whatever you already know; the server asks the shopper for the rest with a form when the client supports it, otherwise it returns the questions to ask. With shape, length and grill size it returns a priced starter layout (straight), or where to go for other shapes. No email needed. Canonical examples: {} ; {"grillSize":36,"grillBrand":"Lynx"} (someone researching grills) ; {"layout":"straight","lengthFeet":10,"grillSize":36,"grillBrand":"Alfresco","refrigerator":true,"sink":true,"gasType":"natural_gas","budget":20000}
| Name | Required | Description | Default |
|---|---|---|---|
| sink | No | Wants a sink. | |
| trash | No | Wants a trash/recycling pull-out. | |
| budget | No | Budget in USD, if they gave one. | |
| layout | No | Shape: "straight" (one run), "galley", "corner_L", "corner_45", "U" or "promenade". | |
| gasType | No | ||
| grillSku | No | A specific grill the shopper chose, by sku from outdoor_kitchen_search_built_in_grills, e.g. "ALFRESCO-36-ALXE". | |
| grillSize | No | Grill width in inches as the brand makes it, e.g. 30, 36, 42, 56. Not every brand makes every size. | |
| grillBrand | No | Preferred grill brand, if any, e.g. "Alfresco". | |
| lengthFeet | No | Length available in feet (for straight, the run length). E.g. 10. | |
| sideBurner | No | Wants a side burner. | |
| refrigerator | No | Wants an outdoor refrigerator. |
| Name | Required | Description |
|---|---|---|
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial behavior beyond them: it returns grill options with MSRP then a priced starter layout, adapts to client capability ('asks the shopper for the rest with a form when the client supports it, otherwise it returns the questions to ask'), and notes no email is required. This is rich call-behavior context the annotations cannot convey.
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?
Purpose is front-loaded in the first clause and the guidance is dense but useful. The parenthetical example lists and the canonical examples are somewhat packed, but each sentence carries information rather than 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?
For an 11-parameter, zero-required guided tool with an output schema and full annotations, the description supplies the interaction model, the return behavior, and the fallback path. Nothing needed to invoke it correctly appears 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?
With 91% schema coverage the baseline is 3, and the description adds real value: it clarifies that no parameters are required ('Pass whatever you already know'), explains the server fills gaps by form or by returning questions, and gives canonical input combinations that map parameter sets to outcomes.
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 ('Guided start for choosing a built-in grill and the outdoor kitchen or BBQ island around it') and clearly separates itself from siblings like search_built_in_grills and list_cabinets. An agent can tell what this does and is not without opening a schema.
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 explicit trigger conditions ('Call FIRST when someone researches or compares built-in grills... says they want an outdoor kitchen... asks roughly what one costs, and has not given exact cabinets'). It implies alternatives ('where to go for other shapes') but does not name the specific sibling tools to route to, so it stops short of full routing 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.
outdoor_kitchen_get_suggestions1 field changedInput schema / properties / situation / enumPrevious value: -[
- "lower_cost",
- "fill_space",
- "ideas",
- "shopper_as_about_other_costs",
- "how_much_does_it_cost",
- "alternatives",
- "damage",
- "best_materials",
- "shopper_asks_about_hdpe_or_plastic_island_cabine",
- "stainles_steel",
- "features_to_look_for",
- "cabinet_types_and_uses",
- "dimensions",
- "return_on_investment"
-]New value: +[
+ "lower_cost",
+ "fill_space",
+ "ideas",
+ "shopper_as_about_other_costs",
+ "how_much_does_it_cost",
+ "alternatives",
+ "damage",
+ "best_materials",
+ "shopper_asks_about_hdpe_or_plastic_island_cabine",
+ "stainles_steel",
+ "features_to_look_for",
+ "cabinet_types_and_uses",
+ "dimensions",
+ "return_on_investment",
+ "diy"
+]outdoor_kitchen_get_suggestions1 field changedInput schema / properties / situation / enumPrevious value: -[
- "lower_cost",
- "fill_space",
- "ideas",
- "shopper_as_about_other_costs",
- "how_much_does_it_cost",
- "alternatives",
- "damage",
- "best_materials"
-]New value: +[
+ "lower_cost",
+ "fill_space",
+ "ideas",
+ "shopper_as_about_other_costs",
+ "how_much_does_it_cost",
+ "alternatives",
+ "damage",
+ "best_materials",
+ "shopper_asks_about_hdpe_or_plastic_island_cabine",
+ "stainles_steel",
+ "features_to_look_for",
+ "cabinet_types_and_uses",
+ "dimensions",
+ "return_on_investment"
+]outdoor_kitchen_get_suggestions1 field changedInput schema / properties / situation / enumPrevious value: -[
- "lower_cost",
- "fill_space",
- "ideas",
- "shopper_as_about_other_costs",
- "how_much_does_it_cost",
- "alternatives"
-]New value: +[
+ "lower_cost",
+ "fill_space",
+ "ideas",
+ "shopper_as_about_other_costs",
+ "how_much_does_it_cost",
+ "alternatives",
+ "damage",
+ "best_materials"
+]outdoor_kitchen_get_suggestionsoutdoor_kitchen_list_cabinetsoutdoor_kitchen_list_grill_brandsoutdoor_kitchen_list_layoutsoutdoor_kitchen_open_designer_for_renderoutdoor_kitchen_price_designoutdoor_kitchen_request_formal_quoteoutdoor_kitchen_search_built_in_grillsoutdoor_kitchen_start_planningDesign & price modular raised garden beds and walls: exact bill of materials, EUR price + checkout.
Measure property from satellite imagery, price 24 trades, and install contractor quote widgets.
Austin TX countertop prices, live granite/quartz slab inventory, job estimates and quote requests.
Plan U.S. road trips across 104 published drives with reviewed stops and honest detour costs.
Add one secure layer between your agents and this server.
