kazaplan-mcp

Overview Schema Source Related Servers Discussions Admin

Kz Move

kz_move

Moves a placed object by dx, dy cm along with items resting on it, blocking collisions, door swings, or hidden windows unless force is enabled.

Instructions

Décale un objet posé de dx, dy cm (coordonnées du plan), avec les objets posés dessus. Refusé en cas de collision, de débattement de porte ou de fenêtre masquée, sauf force=True (tapis, retouches).

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": {
      "object_id": "<object_id>"
    },
    "name": "kz_move"
  }
}

Input Schema

Name	Required	Description	Default
`dx`	No
`dy`	No
`force`	No
`object_id`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 12, 2026

TDQS

A3.8/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 well: it discloses units (cm), the coordinate frame (plan coordinates), the cascading effect on supported objects, and three concrete failure modes plus the override. It omits whether the move is reversible/undoable and what a refusal looks like at the API level.

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?

Two dense sentences with the core action and units front-loaded, then the failure/override conditions. Nothing is redundant, though the mid-sentence line break and the parenthetical example list make it slightly harder to parse than necessary.

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?

An output schema exists, so return values need no explanation, and the description covers movement semantics, units, side effects, and failure/override behavior. The remaining gap is procedural: no statement of what the agent should do after a refusal other than setting force.

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 description coverage is 0%, so the description must compensate, and it largely does: dx/dy get units and a coordinate frame, and force gets semantics plus two example use cases (rugs, retouches). Only object_id is left undefined, though its meaning is evident from context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb ('Décale') and resource ('un objet posé'), and adds a distinguishing scope detail that no sibling shares: objects placed on top move along with it. It does not name a sibling to contrast with (e.g. kz_place, kz_remove), so the differentiation is inferential rather than explicit.

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

Usage Guidelines3/5

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

The refusal conditions (collision, door swing, masked window) and the force=True exception for rugs/touch-ups give real when-not and when-override guidance. However, it never routes the agent to an alternative tool for the refused cases, nor states prerequisites such as the object existing or being placed.

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