Garden Design MCP Server

set_boundary

Defines or replaces a garden plot boundary from polygon vertices in metres, for plots outside Poland, registry errors, or designer measurements. Changes stay unsaved until saved.

Instructions

Set the plot's boundary from a polygon — for a plot outside Poland, one the land registry gets wrong, or the designer's measurements ("18 by 25 m"). Absolute vertices in metres, in the garden coordinates zones use (the garden's place is at 0,0; x east, y south when north is up), e.g. traced from the OpenStreetMap background in capture_preview. Replaces any boundary; the change is unsaved until save. A placed plot becomes located and the map refits around it. Returns {area (m²), plot: 'located' | 'unlocated'}.

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": {
      "polygon": "<polygon>"
    },
    "name": "set_boundary"
  }
}

Input Schema

Name	Required	Description	Default
`polygon`	Yes	The boundary's corners in order, at least 3, absolute metres

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.9.3Nov 6, 2026

TDQS

A4.7/5.0

Behavior5/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 it well: it discloses that any existing boundary is destroyed ("Replaces any boundary"), that the mutation is not persisted until save, that a placed plot transitions to 'located', and that the map refits as a side effect. It even states the return shape.

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 action, then use cases, coordinate frame, side effects, and return value in a single dense paragraph with no filler sentences. It is information-dense to the point of being slightly run-on, with several parentheticals stacked in one sentence.

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 single-parameter mutation with no annotations and no output schema, the description covers preconditions, coordinate semantics, destructive behavior, the save requirement, and the return value. Nothing an agent needs to call it correctly and interpret the result is missing.

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

Parameters5/5

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

Schema coverage is already 100%, yet the description adds substantial meaning the schema lacks: the coordinate frame (absolute metres, origin at the garden's place, x east / y south when north is up) and the expected trace source. This is exactly the origin-and-orientation information an agent needs to avoid producing a mirrored or offset polygon.

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?

Opens with a specific verb+resource ("Set the plot's boundary from a polygon") and immediately scopes it to three concrete situations that distinguish it from parcel-import siblings like import_parcel or map_to_garden. An agent can identify the operation from the first clause.

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 explicit when-to-use conditions (plot outside Poland, land registry data wrong, designer-supplied measurements such as "18 by 25 m") and points at capture_preview for tracing from OpenStreetMap. It never states when NOT to use it or names an alternative tool to call instead for in-Poland registry-correct plots, so it falls short of a 5.

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

Deploy Server