kazaplan-mcp

Overview Schema Source Related Servers Discussions Admin

Kz Set Room

kz_set_room

Rename an existing room or change its type in a virtual home plan; use it after the room is detected and saved—it does not create rooms.

Instructions

Renomme et/ou change le type d'une pièce existante (nom, type ou id). Ne crée jamais de pièce : après kz_add_walls, ouvrir le plan dans le planner et l'enregistrer pour qu'il détecte la pièce (type « room », sans nom), puis kz_open et kz_set_room. Types : bedroom, livingdiningRoom, kitchen, bathRoom, wc, livingRoom, diningRoom, entrance, cupboard, dressing, laundry, storage, bearing, corridor, office, showerRoom, playRoom, otherHabitable, balcony, terraceannex, garage, basement, cellar, attic, loggia, veranda, technicalArea, otherAnnex, garden, terraceext, driveway, carport, parking.

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": {
      "room": "<room>"
    },
    "name": "kz_set_room"
  }
}

Input Schema

Name	Required	Description	Default
`name`	No
`room`	Yes
`type`	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.3/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 disclose the key behavioral fact that the tool only mutates an already-detected room and cannot create one, plus the required upstream save step. It does not cover failure behavior when 'room' matches nothing, nor whether an omitted name/type leaves that field untouched, so it stops short of full disclosure.

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?

Front-loaded with the action then the negative constraint then the workflow, which is the right order. The long type list is bulky but earns its place because the schema has no enum; the only friction is the mixed French/English phrasing, which is a minor readability cost rather than wasted content.

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 not be described, and the description covers purpose, preconditions, and the type vocabulary. What remains missing is a statement of how partial updates behave (name-only, type-only) and what happens when the room reference is invalid — meaningful gaps for a mutation tool with no annotations.

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 0%, so the description must compensate, and it does so for 'type' by enumerating all 28 accepted values that the schema leaves as an untyped string — that is genuinely valuable. However, it never explains what the required 'room' parameter accepts (id? name?) nor clarifies that 'name' and 'type' are optional and independently applicable, leaving the most important identifier under-specified.

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 pair and resource: rename and/or change the type of an existing room (name, type or id). It also draws a hard boundary against the obvious confusion, declaring 'Ne crée jamais de pièce', which separates it from creation siblings like kz_add_walls.

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?

Gives an explicit prerequisite sequence: after kz_add_walls, open the plan in the planner and save so the room is detected, then kz_open and kz_set_room. It names the two relevant siblings and states when this tool will fail to apply (no room exists yet).

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