Garden Design MCP Server

import_parcel

Import a parcel as your garden's site context, setting the boundary, geo-anchor, and map background so previews show real roads, neighbors, and vegetation.

Instructions

Import a parcel as the garden's site context: sets the scheme outline, geo-anchor, and (by default) auto-loads the KIEG WMS cadastral/satellite map background so capture_preview shows real site context (neighbors, road, vegetation) under the boundary. Default alignment is north_up so cardinal reasoning ("south wall", "west fence") works naturally; pass side_aligned if you'd rather draw on an axis-aligned canvas. WMS failure is non-fatal — boundary + geo-anchor still land and the response carries mapBackground: { loaded: false, reason } so you can decide whether to retry or continue without the background. Pass loadMapBackground: false to skip the WMS fetch entirely (faster; useful for headless evals). Poland only: refused for a garden placed outside Poland — draw the boundary with set_boundary instead.

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": {
      "parcelId": "<parcelId>"
    },
    "name": "import_parcel"
  }
}

Input Schema

Name	Required	Description
`parcelId`	Yes	Parcel ID to import (use get_parcel_by_* first to find it)
`alignment`	No	Boundary orientation. `north_up` (default) keeps north pointing up; `side_aligned` rotates so the longest edge runs horizontally. The alignment modal that the editor would normally show for skewed parcels is bypassed when called via MCP.
`loadMapBackground`	No	Auto-load the KIEG WMS cadastral/satellite map background after import. Default `true`. Set `false` to skip the WMS fetch (faster; `capture_preview` will then show the parcel on a blank background and `get_garden_info().hasScheme` stays `false`).

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.9.3Nov 6, 2026

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does most of it well: non-fatal WMS failure with a mapBackground.loaded/reason signal, the Poland-only refusal, and the effect on get_garden_info().hasScheme. What it omits is overwrite semantics — whether an existing boundary/geo-anchor/scheme is replaced, and whether the import is reversible — which matters for a tool that writes three pieces of state at once.

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?

Front-loaded with the primary effect, then defaults, then failure handling, then the geographic restriction — a sensible order. It is a dense single paragraph, and the alignment rationale is repeated in both the description and the schema, which is slight redundancy but not padding.

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

Completeness4/5

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

No output schema exists, so the description must convey return behavior, and it does for the notable case (mapBackground: { loaded: false, reason }) plus downstream state (hasScheme). It does not describe the success-shape response at all — an agent cannot tell what fields a successful import returns, e.g. whether the parsed boundary geometry comes back.

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 earns an extra point by adding rationale the schema lacks — north_up exists so cardinal phrasing like 'south wall' works, and the editor's alignment modal is bypassed under MCP. It otherwise largely restates the enum and boolean defaults already documented in the schema.

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 concrete verb and resource (import a parcel as the garden's site context) plus the three side effects: scheme outline, geo-anchor, and default map background. It implicitly separates itself from set_boundary, set_geo_anchor, and set_map_background by describing them as consequences of this one call, and explicitly names set_boundary as the fallback.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use (establish real site context so capture_preview shows neighbors/road/vegetation), an explicit when-not (outside Poland — refused, use set_boundary instead), and a performance escape hatch (loadMapBackground: false for headless evals). Alternatives are named with the condition that selects them.

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

Deploy Server