kazaplan-mcp

Overview Schema Source Related Servers Discussions Admin

Kz Place

kz_place

Places catalog models in rooms or outdoors with collision checks, wall alignment, centering, under-window or on-top positioning, resizing, rotation, and elevation controls.

Instructions

Pose un modèle du catalogue dans une pièce, avec contrôle de collision (murs, objets, débattement des portes, fenêtres masquées).

Par défaut : dos contre le plus long mur libre qui convient.
against_wall : index d'arête (cf. kz_room_geometry) ; offset : distance en cm entre le début de l'arête et le bord de l'objet (sinon centré dans le plus grand segment libre).
center=True : au centre de la pièce. x, y : centre imposé (coordonnées plan).
under_opening : id d'une fenêtre ; centre l'objet sous elle, dos au mur (radiateurs).
room absent : pose en extérieur, au niveau du terrain ; x, y obligatoires, contrôle des murs traversés.
width / depth / height : redimensionne le modèle (cm), ex. pergola sur mesure.
gap : distance dos du modèle / mur (cm, défaut 1) ; ex. 59 pour poser des portes de dressing devant des caissons de 58 cm. Les modèles NO_COLLISION (portes de dressing…) peuvent chevaucher.
rotation : rotation supplémentaire en degrés (sens trigonométrique) ; avec x, y : angle absolu (la face avant regarde vers rotation + 90°).
force=True : pose même en cas de collision (renvoyée dans warnings).
elevation : hauteur du bas de l'objet au-dessus du sol (cm), au lieu de celle du catalogue (miroir à 120, applique à 170, étagère murale…).
on_top_of : id d'un objet posé ; pose dessus (lampe sur un buffet, vase sur une table), centré sur lui sauf x, y fournis ; avec elevation, pose à cette hauteur (lit : le dessus du matelas, pas la tête de lit).

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": {
      "model_id": "<model_id>"
    },
    "name": "kz_place"
  }
}

Input Schema

Name	Required	Description	Default
`x`	No
`y`	No
`gap`	No
`room`	No
`depth`	No
`force`	No
`width`	No
`center`	No
`height`	No
`offset`	No
`model_id`	Yes
`rotation`	No
`elevation`	No
`on_top_of`	No
`against_wall`	No
`under_opening`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 12, 2026

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 full burden and does so well: it discloses collision checking, that force=True places anyway and reports collisions in warnings, that NO_COLLISION models may overlap, and that outdoor placement checks walls crossed. It does not state whether the placement is persisted or what happens on failure, which is the remaining gap.

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 purpose is front-loaded in one sentence followed by a scannable bullet per parameter or mode. It is long, but for a 16-parameter tool each bullet carries distinct information; a few items (the dressing-door and bed examples) are slightly verbose but still illustrative rather than redundant.

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?

Given 16 undocumented parameters, no annotations and an existing output schema, the description covers placement modes, resizing, collision override, and stacking, so an agent can call it correctly. Only persistence behavior and error handling are left unaddressed.

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 description coverage is 0% across 16 parameters, so the description must compensate entirely, and it does: it explains x/y, gap semantics with a concrete 59 cm example, against_wall as an edge index tied to kz_room_geometry, offset measured from edge start, rotation as absolute angle when x/y given, elevation, and on_top_of stacking with elevation interaction. Nearly every parameter gains meaning not present in the bare schema.

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?

The opening sentence gives a specific verb and resource ('Pose un modèle du catalogue dans une pièce') plus the defining constraint (collision control over walls, objects, door swing, hidden windows). It is clearly distinct from a plain move operation, though it never names a sibling it supersedes, so differentiation is inferred rather than stated.

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?

The bullets effectively encode when each mode applies: default backs against the longest free wall, room absent means outdoor placement requiring x/y, center=True for room center, under_opening for radiators. What is missing is explicit routing against alternatives such as kz_move or kz_check_room, but the conditional branches give strong usage context.

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