Skip to main content
Glama
Sign In
Garden Design MCP Server

Garden Design MCP Server

by zaprojektuj-ogrod
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

add_object

Add plants, buildings, or ground shapes to a garden plan; specify type, placement, size, and product by ID or name search, with path outlines computed automatically.

Instructions

Add a garden object (plant, building, or ground shape). Type determines rendering: 'plant' for plants, 'building' for architecture, 'rectangle'/'ellipse'/'polygon'/'path' for ground shapes. For type='path', provide pathWaypoints (centerline) and pathWidth; the outline polygon is computed automatically. Supply productId OR productQuery (name search resolved server-side). Width/height are optional — if omitted, defaults from the product catalog are used.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "type": "<type>"
    },
    "name": "add_object"
  }
}

Input Schema

NameRequiredDescriptionDefault
xNoCenter X — units determined by set_units (default 'm', meters)
yNoCenter Y — units determined by set_units (default 'm', meters)
pathNoSurface corridor as an ABSOLUTE centreline in metres plus width (for type=path), exactly as add_zones takes it. Preferred over pathWaypoints/pathWidth.
typeYesObject type
labelNoCustom label
widthNoFootprint size east–west — units determined by set_units (default 'm'); optional, defaults to product catalog value. Ignored for plants: they are drawn at their mature catalog size and cannot be resized.
heightNoFootprint size north–south (plan depth, not how tall it is) — units determined by set_units (default 'm'); optional, defaults to product catalog value. Ignored for plants (mature catalog size).
pointsNoPolygon vertices (for type=polygon), RELATIVE to the object's centre x/y — use `polygon` (absolute) instead unless you have centre-relative points
zoneIdNoOptional zone ID — if provided, validates that the object center falls within the zone boundary. Returns warning if outside. Placement always succeeds.
polygonNoSurface outline as ABSOLUTE vertices in metres (for type=polygon), exactly as add_zones takes it — e.g. a zone's outline from get_zones. Preferred over points; x/y/width/height are then computed.
rotationNoRotation in degrees (default 0)
elevationNoGround surfaces only: how high the surface is raised, in metres (a deck, a raised strip of soil). Architecture — raised beds, planters, furniture — always stands at its catalog height, as its model is drawn, and plants in it stand on that; a value given for it is ignored (choose a taller product instead). Not the footprint: that is width × height.
pathWidthNoPath corridor width — units determined by set_units (default 'm'); for type=path, default 1m
productIdNoProduct ID from the catalog (use this OR productQuery)
productQueryNoProduct name search query — resolved server-side. If ambiguous, returns error with top candidates. Use this OR productId.
pathWaypointsNoCenterline waypoints (for type=path), RELATIVE to the object's centre x/y — use `path` (absolute) instead. At least 2 points required.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.9.3

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It does disclose genuinely useful behavior — outline polygons are auto-computed for paths, product queries are resolved server-side, and omitted width/height fall back to catalog defaults — but says nothing about permissions, reversibility, coordinate requirements, or what a successful call returns (no output schema exists).

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?

Five tight sentences, front-loaded with the core action and type taxonomy before secondary details about paths and product resolution. Minor redundancy in pairing each type keyword with its plain-English label ("'plant' for plants"), but nothing extraneous.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 16-parameter creation tool with no annotations and no output schema, the description covers geometry and product selection well but omits the return value (e.g. any created object ID), the bulk sibling, and error conditions beyond ambiguous product queries. The rich schema compensates for much of this, so the gap is moderate rather than severe.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline is 3. The description adds real meaning for the type enum (schema only says "Object type") and states the productId/productQuery exclusivity, but it recommends pathWaypoints/pathWidth for paths while the schema explicitly marks `path` as preferred — a conflict that could push an agent onto the less-preferred parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb+resource ("Add a garden object") with the accepted object types enumerated and tied to rendering behavior. It does not, however, distinguish itself from the sibling add_objects (bulk insert), so an agent cannot tell from the description alone whether to call this or the plural variant.

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 conditional guidance: which type maps to which rendered geometry, that type='path' needs waypoints and width with the outline computed, and that productId and productQuery are mutually exclusive alternatives. It stops short of any when-not guidance and never mentions the batch alternative add_objects.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools