Design & price modular raised garden beds and walls: exact bill of materials, EUR price + checkout.
Scored across 11 tools
Most tools target clearly distinct resources (catalog, plants, pricing, design creation, rules, FAQ, delivery countries). There is mild overlap between studio_templates_list and studio_design_options (both describe shapes/dimensions), and studio_bom_to_cart effectively duplicates/redirects to studio_pricing_quote, but the descriptions disambiguate those cases well.
All names are snake_case with a predictable studio_ prefix and descriptive noun phrases. Minor deviation: studio_create_design is verb-first while most others are noun-first (catalog_bricks, plant_catalog, pricing_quote), but this is readable and not confusing.
Eleven tools is well within a healthy range and each covers a distinct capability (catalogs, design creation, options, pricing, delivery, FAQ, rules, AI links). No bloat and no obviously trivial tools.
The surface covers discovery, configuration, pricing, and design creation comprehensively for the raised-bed/garden domain. Gaps: no shipping-cost calculation (explicitly deferred to checkout) and no working purchase/cart path since studio_bom_to_cart is a disabled dead end, but agents can work around both via pricing_quote and the external site.
Get links to GridGarden's AI garden design: the AI designer from a photo of the garden, and the AI design inside Studio. This tool ONLY returns links - it never starts AI generation (that costs money and needs the user's own action on the website). Use it when the user wants an AI-generated design or visualisation from a photo.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Language of the pages. Default en. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, but the description adds genuinely new behavioral context: it only returns links, it incurs no cost, and the user must act on the website themselves. That is meaningful side-effect and prerequisite disclosure beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core purpose followed by limits and trigger. The middle clause listing the two link types is slightly wordy, but nothing is wasted and structure is clear.
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 one optional parameter, full schema documentation, safety annotations, and no output schema, the description covers what an agent needs: what it returns (links) and when to call it. Naming the actual destination pages or link format would be the only marginal addition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single optional 'locale' parameter and schema description coverage is 100%, including a full enum list and a default. The description adds no additional meaning about locale handling, so the baseline of 3 applies.
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 ('Get links to GridGarden's AI garden design') and even enumerates the two link targets (photo-based designer, in-Studio design). It does not name or contrast a sibling tool, so it falls short of the top band, but the scope is unambiguous.
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 is given: 'Use it when the user wants an AI-generated design or visualisation from a photo.' It also clarifies the negative case (never starts generation), though it never names an alternative sibling such as studio_create_design, leaving that routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Purchasing through an AI assistant is temporarily unavailable. The customer can buy on https://gridgarden.eu. This tool does not create a cart; use studio_pricing_quote for the bill of materials and price.
| Name | Required | Description | Default |
|---|---|---|---|
| shape | Yes | Design type and the dimension fields it needs (all in mm, auto-snapped to the 60mm build grid): rectangle → length + width; lshape → length1 + width1 + length2 + width2; ushape → topLength + topWidth + arm1Length + arm1Width + arm2Length + arm2Width; wall → wallLength. Layers: raised beds 2–13, walls 1–25. Call studio_templates_list for ready example dimensions. | |
| width | No | Rectangle: outer width in mm. | |
| layers | Yes | Number of brick layers. Raised beds 2-13, walls 1-25 (1 = a single 60mm top-cap course). Each layer ≈120mm tall (top layer +60mm). | |
| length | No | Rectangle: outer length in mm. | |
| width1 | No | L-shape: first leg width in mm. | |
| width2 | No | L-shape: second leg width in mm. | |
| country | No | Delivery market as an ISO-3166-1 alpha-2 code (e.g. "DE", "AT", "SK"). Prices differ by market: SK is the base price list; every other market (CZ included) has its own list where structural pieces cost a little more (weight-based delivery surcharge; connector pins stay at base). Ask which country the order ships to; omit only if unknown — that returns SK (base) prices. | |
| length1 | No | L-shape: first leg length in mm. | |
| length2 | No | L-shape: second leg length in mm. | |
| topWidth | No | U-shape: back (top) width in mm. | |
| arm1Width | No | U-shape: arm 1 width in mm. | |
| arm2Width | No | U-shape: arm 2 width in mm. | |
| topLength | No | U-shape: back (top) length in mm. | |
| arm1Length | No | U-shape: arm 1 length in mm. | |
| arm2Length | No | U-shape: arm 2 length in mm. | |
| utm_source | No | Attribution source recorded on the Shopify cart (UTM). Defaults to "mcp". | |
| wallLength | No | Wall: single straight segment length in mm. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Against annotations that declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, the description adds genuinely useful state information (no cart is produced, service is offline, buy externally instead). It does not, however, say what invoking the tool actually returns or errors with, nor reconcile the 'does not create a cart' claim with the declared destructive-write/open-world profile, so the agent cannot tell whether calling it fails, no-ops, or still hits Shopify.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, zero filler, and the most decision-relevant fact (unavailable) is front-loaded ahead of the redirect. Nothing needs to be trimmed.
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 disabled tool, 'unavailable + buy here + use studio_pricing_quote for BOM/pricing' is close to what an agent needs, and no output schema exists to explain. It is slightly short of complete because the elaborate 17-parameter schema is left orphaned with no statement of whether it is inert, and the failure behavior on invocation is unstated.
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 100% across all 17 parameters (shape enum with per-shape dimensions, layers ranges, country pricing semantics, utm_source), so the schema carries the full parameter burden. The description contributes nothing about any parameter — baseline 3 is the correct ceiling when the schema already does all the work.
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 never states what the tool does (convert a bill of materials into a Shopify cart) — it only negates it: 'This tool does not create a cart.' Its actual operative message is a status statement ('purchasing through an AI assistant is temporarily unavailable') plus a redirect. An agent can infer the tool is a dead end, but the purpose is defined by negation plus the name and title rather than by the description itself.
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 explicit routing: the customer should buy on https://gridgarden.eu, and the agent should use studio_pricing_quote 'for the bill of materials and price' — a named alternative with its own scope. The one gap is that it never says outright 'do not call this tool' or what happens if it is invoked, leaving the exclusion implicit in 'temporarily unavailable.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the GridGarden Brick Premium modular components — middle and TOP planks in XS–XL sizes (plus a 1200mm XXL TOP) and the connector pin — with live EUR unit prices and availability from Shopify. Brick Premium only; no other materials are sold. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| catalog | Yes | |
| summary | Yes | |
| currency | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint. The description adds that prices are live from Shopify and in EUR, and that the tool is read-only, consistent with annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey purpose, scope, and constraints. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no parameters, the description fully covers what it does, what it lists, and the source of data. No 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?
There are no parameters, so schema coverage is 100%. Baseline is 4. Description does not need to add parameter info; it is complete for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists specific GridGarden Brick Premium components (planks and connector pin) with live prices and availability. It explicitly names the product line and components, distinguishing it from sibling tools like studio_pricing_quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that it is a read-only catalog for Brick Premium only, indicating when to use it. It implies not for other materials or pricing quotes, but does not explicitly state alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepare a design in GridGarden Studio for the user and return a link that opens it in the editor, plus the price WITH VAT and the parts list. Use it when the user wants to see/try a raised bed layout or a garden plan: a Brick Premium raised bed (rectangle / L / U / wall, mm) and optionally a whole garden (plot shape and size, house, entrance, style, wants, plants). Give what the user told you; for anything they did not say either omit it or pass it in assumed — never invent silently. Unknown values are rejected with a clear message (no silent fallback). The link opens the editor directly (no welcome window), the user can edit and order there. Price and parts are computed by Studio itself; quote price.total_incl_vat (with VAT) and say the country. Nothing is paid or ordered here, and no AI image generation is started. The design is saved anonymously (no personal data); anyone with the link can open it, the first edit makes the user their own copy.
| Name | Required | Description | Default |
|---|---|---|---|
| beds | No | How many identical beds (1–20). Needs shape. Price and parts are for all of them. | |
| link | No | Optional: a ready GridGarden Studio link (https://gridgarden.eu/studio/<lang>/design/new?v=1&…). Its query is used as the input; the other fields below override it. Normally leave this out and pass the fields. | |
| plot | No | Plot shape: rect | narrow | l | other (other = rectangle for now). | |
| entry | No | Where the gate/entrance is: left | middle | right (on the street side unless entrySide). | |
| house | No | Where the house stands (street at the bottom): street | middle | back | corner | none. | |
| north | No | North direction in degrees 0–360 (accepted, not used yet) | |
| plotD | No | Plot depth away from the street, mm (3000–200000) | |
| plotW | No | Plot width at the street, mm (3000–200000; 12 m = 12000) | |
| shape | No | Raised bed / wall type: rectangle | lshape | ushape | wall. Needs its dimensions and layers (see studio_design_options). | |
| style | No | Garden style: modern-minimal | cottage | scandinavian | naturalistic | family-productive | mediterranean-gravel | japanese | formal | open (let the design decide). | |
| wants | No | What the user wants: veg, seating, kids, pets, lowcare, nolawn. | |
| width | No | rectangle: outer width, mm | |
| entryX | No | Entrance position along the boundary, mm | |
| houseD | No | House depth, mm | |
| houseW | No | House width, mm | |
| houseX | No | House x, mm from the lower-left plot corner at the street (with houseY) | |
| houseY | No | House y, mm from the street (with houseX) | |
| layers | No | Brick layers (raised beds 2–13, walls 1–25; each ≈120 mm tall). | |
| length | No | rectangle: outer length, mm | |
| locale | No | Language of the Studio page the user will open (sk cs de en fr hu it nl pl ro). Use the language the user speaks. Default en. | |
| plants | No | Plant keys from studio_plant_catalog. They are saved as the user's planting wishes in the design; the planting itself (where each plant stands) is done in Studio. | |
| width1 | No | lshape: first leg width, mm | |
| width2 | No | lshape: second leg width, mm | |
| assumed | No | Fields the user did NOT say and you guessed (they are shown as "estimated" in Studio). Always list them honestly. | |
| country | No | Delivery country, ISO-3166-1 alpha-2 (DE, AT, SK…). Prices differ by market; ask the user. Omit only if unknown (then SK base prices, said in the result). | |
| length1 | No | lshape: first leg length, mm | |
| length2 | No | lshape: whole second leg length incl. the corner, mm | |
| plotCut | No | plot=l: which corner is missing (default ne = back right; the street is at the bottom). | |
| terrace | No | Existing terrace as a grid cell "1"–"9" (or "none"). | |
| plotArea | No | Plot area in m2 if the user knows only that (9–40000); the plot becomes a rectangle estimate | |
| plotCutD | No | plot=l: depth of the missing corner, mm | |
| plotCutW | No | plot=l: width of the missing corner, mm | |
| terraceX | No | Terrace x, mm (with terraceY) | |
| terraceY | No | Terrace y, mm (with terraceX) | |
| topWidth | No | ushape: back width, mm | |
| arm1Width | No | ushape: arm 1 width, mm | |
| arm2Width | No | ushape: arm 2 width, mm | |
| entrySide | No | Boundary of the entrance: street (default) | left | right | back. | |
| houseCell | No | House position as a 3x3 grid cell 1–9, keypad layout 7 8 9 / 4 5 6 / 1 2 3 (street below 1 2 3). | |
| houseSide | No | house=corner: which side. | |
| topLength | No | ushape: back length, mm | |
| arm1Length | No | ushape: arm 1 length, mm | |
| arm2Length | No | ushape: arm 2 length, mm | |
| from_agent | No | Which assistant you are (chatgpt, claude, perplexity, gemini, copilot, or mcp/agent). Used only for anonymous counting. Default mcp. | |
| wallLength | No | wall: length, mm |
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| parts | Yes | |
| price | Yes | |
| saved | Yes | |
| design | Yes | Normalized design (dimensions after snapping to the 60 mm grid). |
| assumed | Yes | |
| snapped | No | |
| summary | Yes | |
| scene_id | No | |
| warnings | Yes | |
| save_note | No | |
| design_url | Yes | Open this: the saved design in Studio (or the prefill link when saved=false). |
| prefill_url | Yes | The same design as a stateless prefill link (works without the saved scene). |
| link_version | Yes | |
| no_price_reason | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly=false, destructive=false, openWorld=true), it discloses a lot that the structured fields cannot: unknown values are rejected with no silent fallback, price/parts are computed by Studio and must be quoted as price.total_incl_vat with the country, nothing is paid or ordered, no AI image generation is started, and the design is stored anonymously with first-edit-copies ownership. The creation semantics align with readOnlyHint=false, so there is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loaded: the core action and outputs come first, then usage, then input-filling rules and behavioral caveats, with no obvious filler. It runs several sentences long for an already 45-parameter tool, but each sentence carries distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool this complex, the description is complete: an output schema exists so return values need not be restated, and the description still covers routing to studio_design_options (dimensions/layers) and studio_plant_catalog (plant keys), the pricing/VAT reporting rule, locale/country expectations, and the anonymity/link-sharing model.
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 parameter baseline would be 3, but the description adds cross-cutting semantics the schema does not: how to fill `assumed` honestly ("never invent silently"), that `country` drives market-specific pricing, that the link's query is overridden by explicit fields, and that shape parameters depend on dimensions and layers found via studio_design_options.
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 concrete verb+resource ("Prepare a design in GridGarden Studio") and enumerates the exact outputs (editor link, price WITH VAT, parts list), which differentiates it from price-only and BOM-to-cart siblings in the same family. It also scopes the input domain (Brick Premium raised bed shapes, optional whole garden) so an agent knows precisely what this produces.
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 trigger ("Use it when the user wants to see/try a raised bed layout or a garden plan") and sets boundaries ("Nothing is paid or ordered here, and no AI image generation is started"), implicitly excluding ordering and AI-image tools. It does not name an alternative sibling (e.g. studio_ai_designer_link) directly, so the routing is clear but not fully enumerated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the countries GridGarden delivers Brick Premium raised beds to (ISO codes). Use it before quoting: pass the user's country as country to studio_pricing_quote or studio_create_design. Shipping costs are NOT returned here - they are calculated at checkout from the postcode; do not guess them. Delivery to the USA is not offered.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower. The description still adds real context: shipping costs are not returned here, are computed at checkout from the postcode, and should not be guessed. It stops short of describing pagination or exact return shape, but that is minor for a static list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, all front-loaded with the highest-value information first (what it lists, when to call it, what it does not return). No 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 a parameterless read-only list tool with no output schema, the description covers what is returned (ISO country codes), the boundary condition (no shipping costs, USA not supported), and the intended downstream usage. Nothing needed 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?
The tool takes zero parameters, which is the baseline-4 case. The only parameter-ish detail (passing `country` to other tools) belongs to the downstream tools, not this one, so there is nothing further to add.
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 (List) and resource (countries delivered to), scoped to Brick Premium raised beds, and notes the return format is ISO codes. This is clearly distinguishable from sibling tools like studio_pricing_quote or studio_catalog_bricks.
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 says when to use it (before quoting) and how to chain it (pass the user's country as `country` to studio_pricing_quote or studio_create_design). It also names an exclusion: delivery to the USA is not offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything you can pass to studio_create_design (or put in a Studio link): bed shapes with their dimension keys and ready example sizes, plot shapes and size presets, house/entrance/style/wants values, limits, and the product line (Brick Premium only: 60 mm larch snap-in panels and connector pins). Call it first when unsure what values are allowed. Static, free, no prices (use studio_pricing_quote or studio_create_design for prices).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds meaningful complementary context: 'Static, free, no prices' tells the agent this is a non-mutating, zero-cost lookup and that pricing must be sought elsewhere. It does not describe pagination or response shape, but for a static reference read that is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the scope of the inventory in the first sentence and the routing rule in the second. The mid-sentence enumeration is dense but each item plausibly maps to a value domain the caller needs, so it earns its space; slightly list-heavy but not padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must carry the return-value burden — and it does, enumerating the categories of options returned, including the product line caveat (Brick Premium only, 60 mm larch snap-in panels and connector pins). With zero parameters and annotations covering the safety profile, 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?
The tool takes zero parameters, so the baseline is 4. The description usefully characterizes the content the caller receives (shapes, dimension keys, size presets, enumerated value sets), which is the closest analogue to parameter meaning for a no-arg reference tool.
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 names a concrete inventory (bed shapes with dimension keys and example sizes, plot shapes and size presets, house/entrance/style/wants values, limits, product line) rather than restating the title. It explicitly contrasts itself with studio_pricing_quote and studio_create_design, so the agent can distinguish it without opening any sibling 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?
It states the trigger condition directly: 'Call it first when unsure what values are allowed.' It also carves out the exclusion — this tool carries no prices, and pricing belongs to studio_pricing_quote or studio_create_design — giving both when-to-use and when-not-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the design-knowledge-base rules relevant to one step of designing a garden (brief / koncept / dispozicia / vysadba / materialy) — up to 20 rules, each with its predicate, numeric thresholds, strength (must/should/may), confidence tag, and cited sources. No garden scene is read or required; this is reference knowledge, not a check against a specific design. Deterministic: the same step always returns the same rule set.
| Name | Required | Description | Default |
|---|---|---|---|
| step | Yes | Design process step to fetch rules for: brief, koncept, dispozicia, vysadba, materialy. Call this once per step you are working on — do not assume one step's rules cover another. |
| Name | Required | Description |
|---|---|---|
| step | Yes | |
| rules | Yes | |
| total | Yes | |
| summary | Yes | |
| truncated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint=true and openWorldHint=false, and the description is consistent with both. It adds value beyond annotations by disclosing determinism ('the same step always returns the same rule set'), the reference-only nature ('No garden scene is read or required'), and the output structure (up to 20 rules with predicate, thresholds, strength, confidence, sources). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with no filler. The main purpose is front-loaded, followed by the reference-not-check clarification and the determinism guarantee. Slightly more detail than strictly needed given the schema and annotations, but every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a single-parameter reference tool. The output schema covers the return format, annotations cover the read-only safety profile, and the description adds the determinism guarantee and the no-scene-required clarification. 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% and the enum fully specifies the step values with descriptions, so the schema already does the heavy lifting. The tool description merely restates the step values and adds the 'one step at a time' constraint, which the schema description already conveys. Baseline 3 is appropriate when the schema covers all parameter semantics.
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 names a specific verb ('List') and resource ('design-knowledge-base rules') scoped to a single design step, and enumerates the five valid steps (brief/koncept/dispozicia/vysadba/materialy). This clearly differentiates it from the sibling tools, which deal with BOM, catalog bricks, pricing, and templates — entirely different domains.
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 clarifies this is reference knowledge, not a check against a specific garden scene, and the schema description adds explicit per-step guidance: 'Call this once per step you are working on — do not assume one step's rules cover another.' It gives clear usage context but does not explicitly name exclusions against alternatives; differentiation from siblings is implied via domain rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verified short facts about GridGarden Studio for answering users: what Studio is, that it is free, what the free AI design offer is, the beta credits, the product line, and what an AI assistant can and cannot do here. Use it instead of guessing. Returns plain facts, no prices.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context: the content is 'verified', it is 'short facts' rather than raw data, and it deliberately excludes pricing.
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 core purpose is front-loaded in the first clause, and the topic enumeration in the middle is informative rather than padding since it tells the agent exactly what questions this tool can answer. Slightly long as a single sentence, but every clause carries scoping value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only FAQ tool with no output schema, the description covers what comes back ('plain facts, no prices') and the general subject matter well enough to call correctly. Only marginal detail, such as the format of the returned facts, is left unspecified.
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 there is nothing for the description to disambiguate; per the baseline this lands at 4. It correctly implies a simple parameterless call with no filtering options.
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 (returns verified facts about GridGarden Studio) and enumerates the exact topics covered: what Studio is, the free offer, beta credits, product line, and assistant capabilities. The closing boundary 'no prices' implicitly separates it from studio_pricing_quote, though no sibling is named outright.
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?
'Use it instead of guessing' gives a clear trigger for answering user questions, and 'no prices' signals the one thing it should not be used for. No further exclusions or alternative routing are given, but the context is unambiguous for a zero-parameter lookup tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the GridGarden plant catalog (441 species) and get the keys you can pass as plants to studio_create_design. Filter by text, category, edible, sun, suitability for raised beds. Free, read-only. Returns at most 40 plants per call (see total).
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Search text in Slovak, Czech, English, German or Latin name (e.g. "basil", "rajčina"). | |
| sun | No | Required light. | |
| limit | No | ||
| edible | No | true = only edible plants. | |
| category | No | ||
| raised_bed_ok | No | true = only plants suitable for raised beds. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, and 'Free, read-only' largely restates them. It does add useful behavior beyond annotations: the 40-plant cap per call and the hint to consult 'total', but says nothing about ordering, pagination beyond the cap, or matching semantics for the multi-language search.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, front-loaded with the resource and the payoff, then filters, then the cost/limit note. No 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 a no-required-param search with no output schema, it covers purpose, filters, cost, and the result cap. Minor gap: it doesn't say what a returned 'key' looks like or how results are ordered, which matters since the output feeds another tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
At 67% schema coverage the description usefully names every filter (text, category, edible, sun, raised beds) and ties `limit` to the 40-per-call cap. It doesn't clarify multilanguage matching behavior, but the schema's `q` description already covers languages.
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?
Specific verb (search) plus named resource (GridGarden plant catalog, 441 species) and the concrete output (keys to pass as `plants` to studio_create_design). This clearly separates it from siblings like studio_catalog_bricks or studio_create_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?
Explains the workflow role – get keys here, then pass them to studio_create_design – and lists the filter dimensions. It lacks explicit when-not guidance or named alternatives for overlapping lookups, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the exact bill of materials (panels + connector pins) and total EUR price for a GridGarden modular Brick Premium raised bed (rectangle / L / U) or freestanding wall, from dimensions in millimetres. Quantities come from the same engine as the Studio configurator; prices are read live from the GridGarden product catalog for the delivery market you pass in country. The result carries the price WITH VAT (total_incl_vat, the main price — quote this one to the user, with the VAT rate) and WITHOUT VAT (total_excl_vat; the legacy field total_eur is also WITHOUT VAT). Without country the default market is Slovakia (SK, 23 % VAT) and the result says so.
| Name | Required | Description | Default |
|---|---|---|---|
| shape | Yes | Design type and the dimension fields it needs (all in mm, auto-snapped to the 60mm build grid): rectangle → length + width; lshape → length1 + width1 + length2 + width2; ushape → topLength + topWidth + arm1Length + arm1Width + arm2Length + arm2Width; wall → wallLength. Layers: raised beds 2–13, walls 1–25. Call studio_templates_list for ready example dimensions. | |
| width | No | Rectangle: outer width in mm. | |
| layers | Yes | Number of brick layers. Raised beds 2-13, walls 1-25 (1 = a single 60mm top-cap course). Each layer ≈120mm tall (top layer +60mm). | |
| length | No | Rectangle: outer length in mm. | |
| width1 | No | L-shape: first leg width in mm. | |
| width2 | No | L-shape: second leg width in mm. | |
| country | No | Delivery market as an ISO-3166-1 alpha-2 code (e.g. "DE", "AT", "SK"). Prices differ by market: SK is the base price list; every other market (CZ included) has its own list where structural pieces cost a little more (weight-based delivery surcharge; connector pins stay at base). Ask which country the order ships to; omit only if unknown — that returns SK (base) prices. | |
| length1 | No | L-shape: first leg length in mm. | |
| length2 | No | L-shape: second leg length in mm. | |
| topWidth | No | U-shape: back (top) width in mm. | |
| arm1Width | No | U-shape: arm 1 width in mm. | |
| arm2Width | No | U-shape: arm 2 width in mm. | |
| topLength | No | U-shape: back (top) length in mm. | |
| arm1Length | No | U-shape: arm 1 length in mm. | |
| arm2Length | No | U-shape: arm 2 length in mm. | |
| wallLength | No | Wall: single straight segment length in mm. |
| Name | Required | Description |
|---|---|---|
| bom | Yes | |
| shape | Yes | |
| layers | Yes | |
| country | Yes | |
| snapped | No | |
| summary | Yes | |
| currency | Yes | |
| vat_rate | Yes | |
| total_eur | Yes | |
| bom_source | Yes | |
| editor_url | Yes | |
| price_note | Yes | |
| vat_amount | Yes | |
| vat_status | Yes | |
| price_basis | Yes | |
| vat_country | Yes | |
| price_source | Yes | |
| shopify_items | Yes | |
| total_excl_vat | Yes | |
| total_incl_vat | Yes | |
| vat_rate_percent | Yes | |
| price_source_note | Yes | |
| price_not_optimized | No | |
| vat_market_defaulted | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, it discloses the pricing model in depth: live catalog reads, market-dependent structural pricing with the SK base list, and the VAT semantics of the returned fields (total_incl_vat is the one to quote, total_excl_vat and legacy total_eur are without VAT). It also warns that dimensions are auto-snapped to the 60 mm grid and that omitting country silently falls back to SK and is flagged in the result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with what is computed and how, with the VAT/field guidance placed early where it matters most. There is minor redundancy (the no-country SK default is stated in both the first and last sentences), and the middle sentence packs several facts together, but nothing is wasted.
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 16-parameter, high-complexity computation tool, it covers scope, shape/parameter mapping, grid snapping, layer limits reference, market/VAT semantics and default fallback. An output schema exists, so return values need not be enumerated, yet it still flags which price field to quote — nothing needed 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; the description still adds meaning the schema does not carry, notably the default market behaviour and VAT-rate implication of `country`, the shape→dimension-field mapping, and the 60 mm grid snapping applied to all dimensions. It adds real value but does not re-explain individual dimension fields, which the schema already covers.
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 ('Compute the exact bill of materials ... and total EUR price') plus the exact product scope (modular Brick Premium raised bed rectangle/L/U or freestanding wall). It is clearly distinguishable from pricing/design siblings such as studio_create_design or studio_bom_to_cart, and even names the shared engine ('same engine as the Studio configurator').
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 concrete routing guidance: 'Call studio_templates_list for ready example dimensions' and 'Ask which country the order ships to; omit only if unknown'. It does not explicitly scope itself against all siblings (e.g. when to quote here vs. take a BOM to cart), so it falls short of a full when/when-not statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the design shapes GridGarden Studio supports, with the dimension parameters each one needs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| templates | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description confirms a read operation. It adds that the tool lists shapes and dimension parameters, but no further behavioral details are needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence that conveys the purpose without any extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema present, the description fully covers the tool's functionality. It explains what the tool does and what the response includes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so baseline is 4. The description adds value by explaining what the output will contain (shapes and dimension parameters), though schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists design shapes and their dimension parameters. The sibling tools involve BOM, catalog bricks, and pricing quotes, so this tool is distinctly about template listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving supported shapes, but does not explicitly state when to avoid it or contrast with siblings. However, the context of sibling tools makes the usage clear.
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.
studio_ai_designer_linkstudio_create_designstudio_delivery_countriesstudio_design_optionsstudio_faqstudio_plant_catalogstudio_pricing_quote12 fields changedOutput schema / properties / price_noteAdded value: +{
+ "type": "string"
+}Output schema / properties / price_sourceAdded value: +{
+ "enum": [
+ "catalog",
+ "shopify"
+ ],
+ "type": "string"
+}Output schema / properties / price_source_noteAdded value: +{
+ "type": "string"
+}Output schema / properties / total_excl_vatAdded value: +{
+ "type": "number"
+}Output schema / properties / total_incl_vatAdded value: +{
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / vat_amountAdded value: +{
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / vat_countryAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / vat_market_defaultedAdded value: +{
+ "type": [
+ "boolean",
+ "null"
+ ]
+}Output schema / properties / vat_rateAdded value: +{
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / vat_rate_percentAdded value: +{
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / vat_statusAdded value: +{
+ "enum": [
+ "included",
+ "unavailable"
+ ],
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "shape",
- "layers",
- "bom",
- "shopify_items",
- "total_eur",
- "currency",
- "country",
- "price_basis",
- "bom_source",
- "summary",
- "editor_url"
-]New value: +[
+ "shape",
+ "layers",
+ "bom",
+ "shopify_items",
+ "total_eur",
+ "currency",
+ "country",
+ "price_basis",
+ "total_incl_vat",
+ "total_excl_vat",
+ "vat_amount",
+ "vat_rate",
+ "vat_rate_percent",
+ "vat_country",
+ "vat_market_defaulted",
+ "vat_status",
+ "price_source",
+ "price_source_note",
+ "price_note",
+ "bom_source",
+ "summary",
+ "editor_url"
+]studio_bom_to_cart2 fields changedInput schema / properties / country / descriptionPrevious value: -"Delivery market as an ISO-3166-1 alpha-2 code (e.g. \"DE\", \"AT\", \"SK\"). Prices differ by market: SK and CZ are base, every other EU market adds €1 per structural piece. Ask which country the order ships to; omit only if unknown — that returns base (SK/CZ) prices."New value: +"Delivery market as an ISO-3166-1 alpha-2 code (e.g. \"DE\", \"AT\", \"SK\"). Prices differ by market: SK is the base price list; every other market (CZ included) has its own list where structural pieces cost a little more (weight-based delivery surcharge; connector pins stay at base). Ask which country the order ships to; omit only if unknown — that returns SK (base) prices."Output schema / (root)Previous value: -{
- "$schema": "http://json-schema.org/draft-07/schema#",
- "additionalProperties": false,
- "properties": {
- "cart_id": {
- "type": "string"
- },
- "checkout_url": {
- "type": "string"
- },
- "currency": {
- "const": "EUR",
- "type": "string"
- },
- "editor_url": {
- "type": "string"
- },
- "line_items": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "quantity": {
- "type": "number"
- },
- "variant_id": {
- "type": "string"
- }
- },
- "required": [
- "variant_id",
- "quantity"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "price_basis": {
- "const": "shopify_cart",
- "type": "string"
- },
- "snapped": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "field": {
- "type": "string"
- },
- "requested": {
- "type": "number"
- },
- "used": {
- "type": "number"
- }
- },
- "required": [
- "field",
- "requested",
- "used"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "summary": {
- "type": "string"
- },
- "total_eur": {
- "type": "number"
- },
- "total_quantity": {
- "type": "number"
- }
- },
- "required": [
- "checkout_url",
- "cart_id",
- "total_eur",
- "total_quantity",
- "currency",
- "price_basis",
- "line_items",
- "summary",
- "editor_url"
- ],
- "type": "object"
-}New value: +nullstudio_pricing_quote4 fields changedInput schema / properties / country / descriptionPrevious value: -"Delivery market as an ISO-3166-1 alpha-2 code (e.g. \"DE\", \"AT\", \"SK\"). Prices differ by market: SK and CZ are base, every other EU market adds €1 per structural piece. Ask which country the order ships to; omit only if unknown — that returns base (SK/CZ) prices."New value: +"Delivery market as an ISO-3166-1 alpha-2 code (e.g. \"DE\", \"AT\", \"SK\"). Prices differ by market: SK is the base price list; every other market (CZ included) has its own list where structural pieces cost a little more (weight-based delivery surcharge; connector pins stay at base). Ask which country the order ships to; omit only if unknown — that returns SK (base) prices."Output schema / properties / bom_sourceAdded value: +{
+ "const": "studio_build",
+ "type": "string"
+}Output schema / properties / price_not_optimizedAdded value: +{
+ "type": "boolean"
+}Output schema / requiredPrevious value: -[
- "shape",
- "layers",
- "bom",
- "shopify_items",
- "total_eur",
- "currency",
- "country",
- "price_basis",
- "summary",
- "editor_url"
-]New value: +[
+ "shape",
+ "layers",
+ "bom",
+ "shopify_items",
+ "total_eur",
+ "currency",
+ "country",
+ "price_basis",
+ "bom_source",
+ "summary",
+ "editor_url"
+]studio_design_rulesstudio_bom_to_cart3 fields changedInput schema / properties / countryAdded value: +{
+ "description": "Delivery market as an ISO-3166-1 alpha-2 code (e.g. \"DE\", \"AT\", \"SK\"). Prices differ by market: SK and CZ are base, every other EU market adds €1 per structural piece. Ask which country the order ships to; omit only if unknown — that returns base (SK/CZ) prices.",
+ "maxLength": 2,
+ "minLength": 2,
+ "type": "string"
+}Output schema / properties / price_basisAdded value: +{
+ "const": "shopify_cart",
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "checkout_url",
- "cart_id",
- "total_eur",
- "total_quantity",
- "currency",
- "line_items",
- "summary",
- "editor_url"
-]New value: +[
+ "checkout_url",
+ "cart_id",
+ "total_eur",
+ "total_quantity",
+ "currency",
+ "price_basis",
+ "line_items",
+ "summary",
+ "editor_url"
+]studio_pricing_quote4 fields changedInput schema / properties / countryAdded value: +{
+ "description": "Delivery market as an ISO-3166-1 alpha-2 code (e.g. \"DE\", \"AT\", \"SK\"). Prices differ by market: SK and CZ are base, every other EU market adds €1 per structural piece. Ask which country the order ships to; omit only if unknown — that returns base (SK/CZ) prices.",
+ "maxLength": 2,
+ "minLength": 2,
+ "type": "string"
+}Output schema / properties / countryAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / price_basisAdded value: +{
+ "const": "shopify_live",
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "shape",
- "layers",
- "bom",
- "shopify_items",
- "total_eur",
- "currency",
- "summary",
- "editor_url"
-]New value: +[
+ "shape",
+ "layers",
+ "bom",
+ "shopify_items",
+ "total_eur",
+ "currency",
+ "country",
+ "price_basis",
+ "summary",
+ "editor_url"
+]studio_bom_to_cartstudio_catalog_bricksstudio_pricing_quotestudio_templates_listDesign custom LEGO brick sets with 3D models, instructions, kit prices and customer-paid checkout.
Price CNC and sheet metal parts from STEP models or PDF drawings at your job shop's own rates.
Plan a built-in grill and outdoor kitchen: real MSRP, priced layouts, 3D renders and dealer quotes.
Instant parametric cost estimates for custom manufacturing: CNC, molding, sheet metal, 3DP, PCB.
Add one secure layer between your agents and this server.