studio

GridGarden raised-bed / wall price quote

studio_pricing_quote

Read-only

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.

Input Schema

Name	Required	Description
`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.

Output Schema

Name	Required	Description	Default
`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

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedOct 14, 2026

addedOutput schema / properties / price_note
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / price_source

Added value: +{
+  "enum": [
+    "catalog",
+    "shopify"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / price_source_note
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / total_excl_vat
```
Added value: +{
+  "type": "number"
+}
```

addedOutput schema / properties / total_incl_vat

Added value: +{
+  "type": [
+    "number",
+    "null"
+  ]
+}

addedOutput schema / properties / vat_amount

Added value: +{
+  "type": [
+    "number",
+    "null"
+  ]
+}

addedOutput schema / properties / vat_country

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / vat_market_defaulted

Added value: +{
+  "type": [
+    "boolean",
+    "null"
+  ]
+}

addedOutput schema / properties / vat_rate

Added value: +{
+  "type": [
+    "number",
+    "null"
+  ]
+}

addedOutput schema / properties / vat_rate_percent

Added value: +{
+  "type": [
+    "number",
+    "null"
+  ]
+}

addedOutput schema / properties / vat_status

Added value: +{
+  "enum": [
+    "included",
+    "unavailable"
+  ],
+  "type": "string"
+}

changedOutput schema / required

Previous 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"
+]

Changed4 schema fields changedOct 13, 2026

changedInput schema / properties / country / description

Previous 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."

addedOutput schema / properties / bom_source

Added value: +{
+  "const": "studio_build",
+  "type": "string"
+}

addedOutput schema / properties / price_not_optimized
```
Added value: +{
+  "type": "boolean"
+}
```

changedOutput schema / required

Previous 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"
+]

Changed4 schema fields changedAug 17, 2026

addedInput schema / properties / country

Added 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"
+}

addedOutput schema / properties / country

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / price_basis

Added value: +{
+  "const": "shopify_live",
+  "type": "string"
+}

changedOutput schema / required

Previous 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"
+]

First observedJun 30, 2026

TDQS

A4.6/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All studio tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?