Garden Design MCP Server

add_objects

Add multiple garden objects in one call, returning an array of results, to avoid repeated single-object requests. Each item can use a product ID or product query with optional width and height.

Instructions

Add multiple garden objects in a single call. Returns array of results. Use this instead of calling add_object multiple times. Each object supports productId OR productQuery, and optional width/height.

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": {
      "objects": "<objects>"
    },
    "name": "add_objects"
  }
}

Input Schema

Name	Required	Description	Default
`objects`	Yes	Array of object specifications

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.9.3Nov 6, 2026

TDQS

A3.8/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 behavioral burden. It discloses that the call is a batch operation returning an array of results, which hints at per-item outcomes, but it never states whether a failure in one object aborts the whole batch, whether mutations require save, or what authorization/permission context applies.

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?

Three short sentences, front-loaded with the batch purpose and followed by return shape and routing. 'Returns array of results' is slightly vague but not wasteful; nothing here feels like padding.

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?

There is no output schema and no annotations, and the input schema is a deeply nested array of object specifications. The description is thin for that complexity—it does not explain result ordering relative to the input array, partial-failure semantics, or unit inheritance beyond what the schema notes.

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% and each nested property is heavily documented. The description only restates the productId OR productQuery exclusivity and the optional width/height, adding nothing beyond what the schema already says. Baseline 3 is appropriate when the schema does the heavy lifting.

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 and resource plus batch scope: 'Add multiple garden objects in a single call.' It also names the sibling it replaces ('instead of calling add_object multiple times'), so an agent can distinguish the batch tool from the single-object tool without opening either schema.

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?

'Use this instead of calling add_object multiple times' gives clear routing guidance against the obvious alternative. It stops short of stating any exclusions or limits—no maximum batch size, no guidance on when a single add_object call is preferable (e.g. one object), and no note on ordering or partial failure.

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

Deploy Server