Skip to main content
Glama
Garden Design MCP Server

Garden Design MCP Server

set_survey_map

Lay a scaled survey map or site plan under the garden as a map background. Align it to scale by matching map points to garden coordinates or setting a known real distance.

Instructions

Lay a map of the land drawn to scale (survey map, site plan, sketch with its lengths) that the designer attached in the chat under the garden, as a map background. Either matches: two or more points on the map matched to the same points in the garden (garden metres, e.g. boundary corners from get_garden_info) — scale, turn and position are fitted; from three matches you get how far each lands from its garden point. Or measure (a plot with no place or boundary): two points on the map and the real distance between them — the map lies to scale, as drawn, from at at. Pick points far apart, zoom_image to place them exactly, then check with capture_preview. Laying again replaces the map. The next save keeps it with the garden, in the place of a kept cadastral map (which can still be downloaded and shown).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "set_survey_map"
  }
}

Input Schema

NameRequiredDescriptionDefault
matchesNoTwo or more points matched on the map and in the garden
measureNoTwo points on the map and the real distance between them

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.9.3

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does most of it well: it discloses that re-laying replaces the existing map background, how the fit behaves (scale/turn/position fitted; residuals available from three or more matches), and the persistence semantics on the next save, including that a kept cadastral map is displaced but remains downloadable. It does not say whether the change is immediate, undoable, or what errors occur on bad matches, leaving some gaps for a mutation tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence front-loads the purpose well, but the rest is a dense run-on with stacked parentheticals (e.g. the `measure` clause 'the map lies to scale, as drawn, `from` at `at`') that takes effort to parse. Bullet-style separation of the two modes would serve better; nothing is truly wasted, but the packaging is heavy.

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?

For a two-mode, nested-object mutation tool with no output schema, the description covers selection criteria, workflow, replacement semantics, and even a hint of the resulting fit quality. Only the immediate effect, reversibility, and failure behavior are left unstated.

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 description coverage is 100%, so the baseline is 3. The description does add interpretive value — that `matches` needs at least two pairs and yields residual distances at three or more, and that `measure.at` defaults to (0,0) with the map laid as drawn — but the point/view coordinate mechanics are explained by the schema itself.

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 opens with a concrete verb and resource: laying a scaled survey map/site plan/sketch attached in chat as the garden's map background. It clearly distinguishes this from other map/geometry tools (set_map_background, map_to_garden) by framing it as fitting a user-supplied image under the garden using either matched points or a single measured distance.

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?

It explicitly splits the two calling modes: `matches` for a map with two or more correspondences to garden metres (ideally boundary corners from get_garden_info), and `measure` for a plot with no known place or boundary. It also gives operational guidance — pick points far apart, use zoom_image to place them, verify with capture_preview — which tells the agent both when to choose each mode and how to execute it.

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