Skip to main content
Glama

Create a GridGarden Studio design for the user

studio_create_design

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bedsNoHow many identical beds (1–20). Needs shape. Price and parts are for all of them.
linkNoOptional: 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.
plotNoPlot shape: rect | narrow | l | other (other = rectangle for now).
entryNoWhere the gate/entrance is: left | middle | right (on the street side unless entrySide).
houseNoWhere the house stands (street at the bottom): street | middle | back | corner | none.
northNoNorth direction in degrees 0–360 (accepted, not used yet)
plotDNoPlot depth away from the street, mm (3000–200000)
plotWNoPlot width at the street, mm (3000–200000; 12 m = 12000)
shapeNoRaised bed / wall type: rectangle | lshape | ushape | wall. Needs its dimensions and layers (see studio_design_options).
styleNoGarden style: modern-minimal | cottage | scandinavian | naturalistic | family-productive | mediterranean-gravel | japanese | formal | open (let the design decide).
wantsNoWhat the user wants: veg, seating, kids, pets, lowcare, nolawn.
widthNorectangle: outer width, mm
entryXNoEntrance position along the boundary, mm
houseDNoHouse depth, mm
houseWNoHouse width, mm
houseXNoHouse x, mm from the lower-left plot corner at the street (with houseY)
houseYNoHouse y, mm from the street (with houseX)
layersNoBrick layers (raised beds 2–13, walls 1–25; each ≈120 mm tall).
lengthNorectangle: outer length, mm
localeNoLanguage 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.
plantsNoPlant 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.
width1Nolshape: first leg width, mm
width2Nolshape: second leg width, mm
assumedNoFields the user did NOT say and you guessed (they are shown as "estimated" in Studio). Always list them honestly.
countryNoDelivery 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).
length1Nolshape: first leg length, mm
length2Nolshape: whole second leg length incl. the corner, mm
plotCutNoplot=l: which corner is missing (default ne = back right; the street is at the bottom).
terraceNoExisting terrace as a grid cell "1"–"9" (or "none").
plotAreaNoPlot area in m2 if the user knows only that (9–40000); the plot becomes a rectangle estimate
plotCutDNoplot=l: depth of the missing corner, mm
plotCutWNoplot=l: width of the missing corner, mm
terraceXNoTerrace x, mm (with terraceY)
terraceYNoTerrace y, mm (with terraceX)
topWidthNoushape: back width, mm
arm1WidthNoushape: arm 1 width, mm
arm2WidthNoushape: arm 2 width, mm
entrySideNoBoundary of the entrance: street (default) | left | right | back.
houseCellNoHouse position as a 3x3 grid cell 1–9, keypad layout 7 8 9 / 4 5 6 / 1 2 3 (street below 1 2 3).
houseSideNohouse=corner: which side.
topLengthNoushape: back length, mm
arm1LengthNoushape: arm 1 length, mm
arm2LengthNoushape: arm 2 length, mm
from_agentNoWhich assistant you are (chatgpt, claude, perplexity, gemini, copilot, or mcp/agent). Used only for anonymous counting. Default mcp.
wallLengthNowall: length, mm

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeYes
partsYes
priceYes
savedYes
designYesNormalized design (dimensions after snapping to the 60 mm grid).
assumedYes
snappedNo
summaryYes
scene_idNo
warningsYes
save_noteNo
design_urlYesOpen this: the saved design in Studio (or the prefill link when saved=false).
prefill_urlYesThe same design as a stateless prefill link (works without the saved scene).
link_versionYes
no_price_reasonNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources