Skip to main content
Glama
Sign In
Garden Design MCP Server

Garden Design MCP Server

by zaprojektuj-ogrod
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

set_map_background

Show or hide OpenStreetMap, satellite, or survey backgrounds under a garden plan so you can check site features and context.

Instructions

Switch a map background under the garden on or off. 'osm' is the live OpenStreetMap map, about 100 m around the plot, turning with the garden; 'satellite' is the aerial photo of the same area (Poland only: the national orthophoto; elsewhere it answers that there is no photo) — fences, hedges, trees and paths show there, not on the street map. Both need the garden's place (set_geo_anchor or import_parcel), are loaded live and start off each time the garden opens. 'survey' is the survey map laid with set_survey_map (false hides it, true shows it again). They show in capture_preview and hide with the 'map' layer.

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": {
      "kind": "<kind>",
      "visible": "<visible>"
    },
    "name": "set_map_background"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindYesWhich background
visibleYestrue to show it, false to remove it

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.9.3

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations supplied, the description carries the full behavioral burden and does so well: it discloses the Poland-only limitation of the satellite layer (and that elsewhere it reports no photo), that layers are loaded live and reset to off on each garden open, and that they appear in capture_preview. These are non-obvious, actionable traits an agent could not infer from the schema.

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 core action is front-loaded and each sentence adds a distinct fact (layer definitions, region limit, prerequisites, persistence, visibility side effects). The dense em-dash construction makes it slightly harder to scan than a short bulleted structure would be, but there is no filler.

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 mutation tool with no annotations and no output schema, the definition covers prerequisites, persistence semantics, region constraints, and interaction with set_survey_map and capture_preview. Only the failure mode when no geo anchor is set is left implicit rather than stated outright.

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 goes beyond it by giving operational meaning to each enum value of 'kind'. It adds little about 'visible' beyond what the schema already says ('true to show it, false to remove it'), but the most consequential parameter is well explained.

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 specific verb+resource ('Switch a map background') and then defines all three enum values with concrete meaning: 'osm' is live OSM ~100 m around the plot, 'satellite' is the Polish national orthophoto, 'survey' is the map laid by set_survey_map. This is clearly distinguishable from the neighboring set_layer_visible, and the closing clause explains how the two interact ('hide with the map layer').

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 real preconditions: both osm and satellite require the garden's place to be set via set_geo_anchor or import_parcel, and 'survey' only makes sense after set_survey_map. It does not explicitly say to prefer this tool over set_layer_visible for hiding the map, though the pointer to the 'map' layer partially covers that routing.

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