Plan a built-in grill and outdoor kitchen: real MSRP, priced layouts, 3D renders and dealer quotes.
Scored across 9 tools
The list_* tools (cabinets, grill_brands, layouts) and get_suggestions each have clearly distinct purposes. However, start_planning overlaps heavily with search_built_in_grills and price_design (it returns grill options AND a priced starter layout), and open_designer_for_render vs request_formal_quote both create an account and return a designer link with only subtle intent differences. Descriptions work hard to route the agent, which mitigates but does not eliminate the confusion.
Every tool uses the identical outdoor_kitchen_ prefix followed by a consistent verb_noun pattern (get_suggestions, list_cabinets, list_grill_brands, list_layouts, open_designer_for_render, price_design, request_formal_quote, search_built_in_grills, start_planning). The convention is uniform and predictable throughout.
Nine tools is well-scoped for a domain spanning browsing, planning, pricing, and quote/render workflows. Each tool maps to a distinct stage of the shopper journey and none feel redundant padding.
Coverage is strong: listing cabinets/brands/layouts, searching appliances, pricing, suggestions, planning, renders, and formal quotes all exist, supporting the full shopping lifecycle. Minor gaps exist around multi-shape pricing and post-quote operations, but the core surface is essentially complete.
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 readOnlyHint/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful behavior: returns only applicable suggestions, each flagged 'offered' true/false, and the agent should tell the shopper what each would change and let them decide. It also reinforces the unprompted-call prohibition.
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 call condition is front-loaded, and the long enumeration largely earns its place as routing logic absent from the schema. There are typos and duplicated words ('when when', 'shopper_as_about_other_costs', 'stainles_steel') that slightly hurt readability but not structure.
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-shape explanation is optional and the brief 'offered' true/false note suffices. Combined with the annotations and the exhaustive situation routing, an agent has what it needs to decide when to call and what to send; only the design/appliance object contents rely solely on the 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 description coverage is only 33%, and the schema's situation enum has no per-value descriptions, so the description carries real weight by defining the trigger meaning of each enum value. It also specifies what payload to send for 'fill_space' (design) and 'lower_cost' (grill brand/size/msrp), compensating for the coverage gap, though design/appliance field-level detail is left to the 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 opening sentence, 'Suggestions for the shopper's outdoor kitchen', is close to a restatement of the title, but the enumerated situations immediately make concrete what kind of suggestions this returns (cost, fill-space, materials, ROI, DIY, etc.). An agent can distinguish it from siblings like outdoor_kitchen_price_design or outdoor_kitchen_list_cabinets, though the single-sentence purpose statement itself is thin.
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 states 'Call ONLY in one of these situations' and then maps each of the 15 situation values to a concrete shopper utterance, plus 'Never call it unprompted.' This is about as strong a when-to-use / when-not-to-use routing spec as a description can carry.
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":"designer",...}]}
| 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 readOnly/idempotent/non-destructive/openWorld=false, but the description adds genuinely new behavioral context: it explains the semantic meaning of the 'how' field in the return payload and maps each value to the next tool the agent should call. That routing behavior is not captured by annotations or a vanilla output schema.
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 shape list, then triggers, then routing, then a compact example. Dense but every sentence earns its place; only mild over-packing of the routing clause keeps it from a 5.
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 explainer with an output schema, the description is fully sufficient: it defines the domain values, the call triggers, the returned field semantics, and the follow-up paths. An agent has everything needed to invoke and act on the result.
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?
Zero parameters, so baseline is 4. The description includes a concrete example invocation ({} -> {...layouts...}), which confirms the no-argument contract, but there is no parameter nuance to add beyond that.
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 (Explain) on a specific resource (outdoor kitchen shapes) and enumerates the exact values returned: Straight, Galley, Corner L, Corner 45, U-Shape, Promenade. An agent can immediately distinguish this explainer tool from siblings like list_cabinets or price_design.
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 trigger conditions are given ('Call when the user asks about layouts, shapes, corners, L-shaped, U-shaped, wrap-around or island-with-seating'), and it names the follow-up siblings by tool name and condition (price_design for price_here, open_designer_for_render for designer, request_formal_quote for our_design_team). 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, Corner 45, U-Shape or Promenade, 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", "U" or "promenade". 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 declare readOnlyHint=false, idempotentHint=false, destructiveHint=false; the description adds real behavioral context on top: it creates a shopper account, returns a designer link, delivers the render by email, and has the server prompt the shopper directly for missing name/email when the client supports it. It does not address repeat calls (relevant given idempotentHint=false) or any rate limits, so it falls short of a 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?
Purpose and call conditions are front-loaded, then the design/kitchenLayout branching, then two concrete payload examples for the nested object. Some redundancy exists (the straight-only constraint is restated in both prose and the 'kitchenLayout'/'design' schema descriptions), and the run-on first sentence mixes three facts, but nothing is 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?
An output schema exists, so return values need not be spelled out, and the description still names the two most agent-relevant outputs (designer link, emailed render). For a complex nested-object tool with 11 params and 0 required fields, the description covers the triggering intent, the identity fields, the fallback collection behavior, and the layout branching, which is enough to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 64%, and the description clarifies the most consequential semantics: 'design' is the already-priced straight layout (mutually exclusive with a non-straight 'kitchenLayout'), and named shapes must use the kitchenLayout path. It also ties cabinet 'type' values back to outdoor_kitchen_list_cabinets. The remaining undocumented inputs (city, phone, state, gasType, purchaseTimeframe) get no explanation anywhere, so it is not complete.
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 precise verb and resource: create the shopper's account and return a link to the 3D outdoor kitchen designer with an emailed photoreal render. The purpose is clearly separable from siblings like outdoor_kitchen_price_design (pricing) and outdoor_kitchen_request_formal_quote (quoting), which the description implicitly routes away from.
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 trigger conditions are given ('Call when the user wants to see their outdoor kitchen or BBQ island, wants a render, picture or 3D design'), plus an explicit branch rule: pass 'design' only for the straight layout priced with outdoor_kitchen_price_design, otherwise pass 'kitchenLayout' and omit 'design'. This tells the agent both when to call and which variant to use.
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, Corner 45, U-Shape or Promenade 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, Corner 45, U-Shape or Promenade, 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 readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds real value beyond that: nothing is persisted, no email is sent, it returns MSRP (not a quote), and it explicitly warns the straight-layout price is only a guide for multi-run layouts.
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 prose is front-loaded and tight: purpose, trigger, then the straight-only caveat with routing. The trailing canonical JSON example is long but earns its place by disambiguating the nested payload format.
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 it does not need to explain return values, yet it still names the returned components. Combined with the layout limitation, persistence behavior, and a full worked input, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description goes further with a canonical worked example showing width, kitchenLayout, color, countertopType and a cabinets array with grill fields, which reinforces how nested cabinet objects and the straight-layout constraint combine.
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 (Return the MSRP) and resource (straight outdoor kitchen) plus the itemized scope (cabinets, grill/appliances, countertop, total). It clearly distinguishes itself from siblings like outdoor_kitchen_open_designer_for_render and outdoor_kitchen_request_formal_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?
Explicit trigger ('Call whenever the user asks what an outdoor kitchen or BBQ island would cost') plus explicit when-not and alternative routing ('Straight only... send the shopper to the designer'). Also states no email is needed and nothing is saved, clarifying it is not the formal-quote path.
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. 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", "U" or "promenade". 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 disclose a non-read-only, non-destructive, non-idempotent write, so the bar is lower; the description still adds real behavioral context: a shopper account is created, a dealer follow-up is triggered, and the server may prompt the shopper directly for missing name fields. It does not disclose that repeat calls may create duplicate accounts/leads, 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?
The purpose and trigger clause are front-loaded in the first two sentences, and the example earns its length by demonstrating the nested payload. Some sentences are dense run-ons, and the example could be trimmed without losing meaning.
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, the description needn't explain return values, and it still signals the designer link. For an 11-parameter nested tool it covers the critical path (identity, ZIP, straight-layout design, other shapes), but the undocumented city/phone/gasType parameters and the relationship to price_design as a prerequisite remain residual gaps.
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 64% and the description compensates: it names the three needed identity fields, explains ZIP's role in dealer matching, and supplies a fully populated canonical example that clarifies the nested cabinet/design structure far beyond the schema. It leaves city, phone, and gasType unmentioned, which keeps it from a 5.
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 chain and outcome: creates the shopper's account, returns a designer link, produces a formal itemized quote, and triggers a local dealer follow-up. The trigger clause ('wants a quote, an exact price from a dealer, or to buy') distinguishes it from the pricing/render siblings an agent might otherwise pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear when-to-call conditions ('quote', 'exact price from a dealer', 'buy an outdoor kitchen or built-in grill') and specifies that first/last/email are needed, with the server fallback if the client can't supply them. It stops short of naming the alternative siblings (price_design, open_designer_for_render) or stating when NOT to use this tool.
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. The "size" field is the real size class; some brands call a 36" class grill "40-inch" in the name, which is marketing, not a bigger grill.
| 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 establish readOnly/idempotent/non-destructive/openWorld=false, and the description adds real behavioral context on top: MSRP is not final (dealer-determined), models without msrp carry priceOnQuote: true, and the canonical grill-to-cabinet sizing rule. This goes well beyond the annotation layer.
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, filters, then example, then domain rules. It is dense and long, but nearly every sentence (sizing rule, marketing-name caveat, priceOnQuote note) delivers non-obvious domain knowledge. Slightly overpacked for a single 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?
For a read-only search with an output schema, the description supplies the query semantics, the alternate tool, an example call/response, and the domain caveats (cabinet sizing, size-class vs marketing). Nothing an agent needs 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?
Schema coverage is 100%, so baseline would be 3, but the description meaningfully enriches the params: it explains applianceType usage ("Griddles", "Side Burners", "Refrigeration", "all"), and critically clarifies that the "size" field is the real size class while brand marketing names (e.g. "40-inch" for a 36 class) are not actual size. That is genuine added meaning beyond the 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?
Opens with a specific verb+resource ("Find built-in grills") and immediately enumerates the returned fields (brand, width, SKU, cabinetSize, MSRP), so the agent knows exactly what this returns. It is clearly distinguishable from siblings like outdoor_kitchen_list_cabinets and outdoor_kitchen_start_planning.
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 trigger conditions are stated ("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"), and an alternative is named with its selecting condition (start_planning for someone just starting to shop). Also notes all filters are optional.
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 / design / properties / kitchenLayout / descriptionPrevious value: -"Always \"straight\": these tools build one run of cabinets. For a Galley, Corner L, Corner 45 or U-Shape, open the designer with kitchenLayout set and no design."New value: +"Always \"straight\": these tools build one run of cabinets. For a Galley, Corner L, Corner 45, U-Shape or Promenade, open the designer with kitchenLayout set and no design."outdoor_kitchen_open_designer_for_render2 fields changedInput schema / properties / design / properties / kitchenLayout / descriptionPrevious value: -"Always \"straight\": these tools build one run of cabinets. For a Galley, Corner L, Corner 45 or U-Shape, open the designer with kitchenLayout set and no design."New value: +"Always \"straight\": these tools build one run of cabinets. For a Galley, Corner L, Corner 45, U-Shape or Promenade, open the designer with kitchenLayout set and no design."Input schema / properties / kitchenLayout / descriptionPrevious value: -"The shape the shopper wants: \"straight\", \"galley\", \"corner_L\", \"corner_45\", \"U\", or \"promenade\" (our design team draws it; 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."New value: +"The shape the shopper wants: \"straight\", \"galley\", \"corner_L\", \"corner_45\", \"U\" or \"promenade\". For anything but straight, leave out \"design\"; the designer opens on this shape and the shopper lays it out."outdoor_kitchen_price_design1 field changedInput schema / properties / kitchenLayout / descriptionPrevious value: -"Always \"straight\": these tools build one run of cabinets. For a Galley, Corner L, Corner 45 or U-Shape, open the designer with kitchenLayout set and no design."New value: +"Always \"straight\": these tools build one run of cabinets. For a Galley, Corner L, Corner 45, U-Shape or Promenade, open the designer with kitchenLayout set and no design."outdoor_kitchen_request_formal_quote2 fields changedInput schema / properties / design / properties / kitchenLayout / descriptionPrevious value: -"Always \"straight\": these tools build one run of cabinets. For a Galley, Corner L, Corner 45 or U-Shape, open the designer with kitchenLayout set and no design."New value: +"Always \"straight\": these tools build one run of cabinets. For a Galley, Corner L, Corner 45, U-Shape or Promenade, open the designer with kitchenLayout set and no design."Input schema / properties / kitchenLayout / descriptionPrevious value: -"The shape the shopper wants: \"straight\", \"galley\", \"corner_L\", \"corner_45\", \"U\", or \"promenade\" (our design team draws it; 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."New value: +"The shape the shopper wants: \"straight\", \"galley\", \"corner_L\", \"corner_45\", \"U\" or \"promenade\". For anything but straight, leave out \"design\"; the designer opens on this shape and the shopper lays it out."outdoor_kitchen_get_suggestions1 field changedInput schema / properties / design / properties / kitchenLayout / descriptionPrevious value: -"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."New value: +"Always \"straight\": these tools build one run of cabinets. For a Galley, Corner L, Corner 45 or U-Shape, open the designer with kitchenLayout set and no design."outdoor_kitchen_open_designer_for_render2 fields changedInput schema / properties / design / properties / kitchenLayout / descriptionPrevious value: -"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."New value: +"Always \"straight\": these tools build one run of cabinets. For a Galley, Corner L, Corner 45 or U-Shape, open the designer with kitchenLayout set and no design."Input schema / properties / kitchenLayout / descriptionPrevious value: -"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."New value: +"The shape the shopper wants: \"straight\", \"galley\", \"corner_L\", \"corner_45\", \"U\", or \"promenade\" (our design team draws it; 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."outdoor_kitchen_price_design1 field changedInput schema / properties / kitchenLayout / descriptionPrevious value: -"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."New value: +"Always \"straight\": these tools build one run of cabinets. For a Galley, Corner L, Corner 45 or U-Shape, open the designer with kitchenLayout set and no design."outdoor_kitchen_request_formal_quote2 fields changedInput schema / properties / design / properties / kitchenLayout / descriptionPrevious value: -"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."New value: +"Always \"straight\": these tools build one run of cabinets. For a Galley, Corner L, Corner 45 or U-Shape, open the designer with kitchenLayout set and no design."Input schema / properties / kitchenLayout / descriptionPrevious value: -"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."New value: +"The shape the shopper wants: \"straight\", \"galley\", \"corner_L\", \"corner_45\", \"U\", or \"promenade\" (our design team draws it; 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."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.
Home-improvement cost estimates, tier comparisons, quote checks and permit guidance for US homes.
Get quotes from local shops for a home repair or project anywhere in the US. Free for homeowners.
Measure property from satellite imagery, price 24 trades, and install contractor quote widgets.
Add one secure layer between your agents and this server.
