Design & price modular raised garden beds and walls: exact bill of materials, EUR price + checkout.
Scored across 11 tools
Several pairs overlap: studio_templates_list and studio_design_options both describe supported shapes and dimension parameters, while studio_create_design and studio_pricing_quote both compute prices and parts. Descriptions help distinguish them, but an agent could easily misselect, especially when a user asks for pricing alone or for a design overview.
All tools use the same studio_ snake_case prefix, which makes the set predictable. The only minor inconsistency is that most names are noun phrases (design_options, plant_catalog) while one is verb_noun (create_design), but the convention is otherwise stable.
Eleven tools is well-scoped for a garden design assistant: it covers design creation, pricing, catalogs, reference material, FAQ, and delivery checks without excessive duplication. Each tool has a plausible role, though studio_bom_to_cart is disabled and could be pruned.
The surface covers the core design workflow: understanding options, choosing plants, creating a design link, quoting prices, and checking delivery. Minor gaps exist around shipping estimates and order tracking, but purchasing is explicitly unavailable, and the disabled studio_bom_to_cart is a deliberate dead end rather than a missing capability.
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. |
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 (346 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 and openWorldHint=false, so the safety profile is covered; the description adds genuinely new behavior: 'Free', a hard result cap of 40 plants per call, and a total count to check (implying a truncated result set the caller must handle). Return shape details beyond that are absent, keeping it at 4.
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 tight sentences, front-loaded with search scope and outcome, then filters, then cost/behavior, then the result cap. Nothing is redundant and every clause carries 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 output schema, the description carries the return burden and does so partially: it discloses the 40-item cap, references a total, and identifies the key field for the downstream tool. It does not describe the per-item shape (name, keys, attributes), which an agent building a `plants` payload would benefit from.
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 67% and the description enumerates the filter dimensions (text, category, edible, sun, raised beds), which mirrors the schema names rather than adding format, default, or combination semantics. `limit` is never mentioned in the description, and no guidance is given on how the filters compose. Baseline 3 is appropriate.
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 (Search) and resource (GridGarden plant catalog), quantifies the corpus (346 species), and states the concrete outcome: the keys to pass as `plants` to studio_create_design. That downstream link lets an agent place it precisely against siblings like studio_create_design and 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?
Makes the when-to-use clear by tying it to studio_create_design's `plants` argument, and notes it is free and read-only so the agent knows it is safe to call speculatively. It offers no explicit when-not-to-use or named alternative catalog, so it stops short of 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 |
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_listPlan 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.
Turn designs into shipped parts: quote 3D printing, CNC, and decals, then check out.
Manufacturing cost of CNC and sheet-metal parts from STEP or DXF: process plan, times, 10 lot sizes.
Add one secure layer between your agents and this server.
