Room planning to scale from your AI: it places furniture, Roomproof checks walkways and door swings.
Scored across 9 tools
Each tool has a fairly distinct role: create_room sets up the space, place_furniture adds pieces, move_furniture alters or removes existing ones, check_plan re-validates, show_plan renders, and open_plan shares. The closest pair is place_furniture's exact 'placement' mode versus move_furniture, but their descriptions clarify that one is for new placements and the other for modifying saved layout positions.
All nine tool names follow the same lowercase snake_case verb_noun pattern: create_room, move_furniture, show_catalog, set_door, etc. The verbs are specific and consistent, making the tool surface predictable for an agent.
Nine tools is well-scoped for the room-planning domain: room creation, door configuration, catalog browsing, product reading, furniture placement and moving, plan checking, viewing, and sharing. There are no redundant utilities or an overwhelming number of endpoints.
The core lifecycle is covered: create a room, configure openings, choose furniture, place and move it, validate the plan, render it, and share it. Minor gaps such as no explicit tool to update room dimensions or delete a project prevent a perfect score, but agents can still complete the main workflow without dead ends.
Re-checks the saved layout only: pieces sticking out, overlaps, blocked areas including door swings, and a 0.9 m path to every piece. Does not place, move or spend a wish. Call it after move_furniture or when issues are unclear; ok true with an empty issues list is the condition for open_plan. Needs key on your own project, free on beispiel-wohnzimmer.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Purchase token rp_ plus 20 characters, from the purchase confirmation. Required on projects you created, not on beispiel-wohnzimmer. Not the project id. | |
| project | Yes | Plan id from create_room, or beispiel-wohnzimmer. | |
| variant | No | Variant id from a previous response; default the newest. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds the 'does not spend a wish' clarification, reinforcing the non-destructive nature, and notes the pricing nuance ('free on beispiel-wohnzimmer'). It also implies the response shape via the 'ok true with empty issues list' condition. No contradiction; minor gaps like error handling exist but are not critical for a read-only check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each purposeful: the first lists what the tool checks, the second states exclusions and usage timing, the third covers prerequisites and cost. The critical information is front-loaded, and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only check with fully documented parameters and no output schema, the description covers the checks performed, the non-mutating behavior, usage context, and even hints at the response structure via the 'ok true' condition. It could mention error scenarios or the exact return format, but the core information an agent needs to call it correctly is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains each parameter in detail (key token format, project id source, variant default). The description only restates the key requirement and free condition, adding no new parameter-level semantics. Baseline 3 is appropriate given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('re-checks') and resource ('the saved layout'), enumerates the exact checks performed (pieces sticking out, overlaps, blocked areas including door swings, 0.9 m path), and explicitly excludes actions (does not place, move or spend a wish). This clearly differentiates it from siblings like move_furniture, place_furniture, and open_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to call it ('after move_furniture or when issues are unclear') and gives a conditional for another tool ('ok true with an empty issues list is the condition for open_plan'). It also mentions the key requirement context. This provides clear routing guidance relative to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free, no key. Creates a new plan at scale 1:50 and returns its project id plus purchase_url. Send name, plus either width_m and depth_m (rectangle) or rectangles (L-shape, alcove, bay), never both. Always send openings in this same call; without openings the checker treats the room as having no doors and skips the door-swing check. Each side 0.3 to 200 m. Coordinates: x to the right, y down, origin at the room's top-left corner.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Purchase token rp_ plus 20 characters, from the purchase confirmation. Required on projects you created, not on beispiel-wohnzimmer. Not the project id. | |
| name | No | Name of the plan, e.g. Living room. Default My room. | |
| depth_m | No | Depth in meters (top to bottom), 0.3 to 200. | |
| width_m | No | Width in meters (left to right), 0.3 to 200. | |
| openings | No | All doors and windows of the room. The swing area of every door becomes a blocked area that furniture must keep clear. | |
| rectangles | No | Instead of width_m and depth_m: 1 to 12 partial areas in meters. kind add joins the area, kind cut removes it. x, y is the rectangle's top-left corner, w, h its size. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses free/no-key access, the 1:50 scale, the returned project id and purchase_url, the checker's behavior when openings are omitted, and the coordinate system. These are material behavioral facts that an agent needs to invoke the tool correctly and interpret results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficiently structured: it front-loads cost, purpose, and return values, then covers the two parameter modes and key constraints in a few short sentences. No sentence is filler; even the coordinate note earns its place because it directly affects how rectangles and opening centers are interpreted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with six parameters and no output schema, the description covers the required call shape, parameter alternatives, coordinate semantics, measurement bounds, return values, and checker side effects. There is no critical missing context an agent would need to make a correct first call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds crucial meaning not inferable from property names alone: the never-both rule for the two room-shape modes, the x-right/y-down coordinate origin at the top-left corner, the global side range of 0.3–200 m, and the requirement to send openings in this same call. This goes well beyond the schema's per-property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Creates a new plan at scale 1:50') and explicitly names the return values (project id and purchase_url). This clearly distinguishes it from sibling tools like check_plan or show_plan, which operate on existing plans rather than creating one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives strong operational guidance: use either width_m/depth_m or rectangles, never both, and always include openings in the same call or the door-swing check is skipped. It does not explicitly name alternative tools or give a when-not-to-use comparison, so it misses the strongest form of usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Moves, rotates or removes one piece in the saved layout and returns the re-checked plan as an image with issues. Send x and y together (piece center, meters), rot, or remove true. The result is saved even with issues, so read them and move again if needed. Needs key on your own project, free on beispiel-wohnzimmer (not saved).
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | New piece center, horizontal, in meters. Send with y. | |
| y | No | New piece center, vertical, in meters. Send with x. | |
| key | No | Purchase token rp_ plus 20 characters, from the purchase confirmation. Required on projects you created, not on beispiel-wohnzimmer. Not the project id. | |
| rot | No | New rotation in degrees clockwise. | |
| index | No | If several pieces share the name: which one, counted from 1 in list order. Default 1. | |
| piece | Yes | Display name from placed, furniture or issues in the last place_furniture, show_plan or check_plan response, e.g. 3-seat sofa. Not the catalog id. | |
| remove | No | true removes the piece; x, y and rot are then ignored. | |
| project | Yes | Plan id from create_room, or beispiel-wohnzimmer. | |
| variant | No | Variant id from a previous response; default the newest. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation (readOnlyHint=false) and idempotence (idempotentHint=true). The description adds important behavior beyond that: 'The result is saved even with issues' and 'free on beispiel-wohnzimmer (not saved)' disclose persistence semantics and a key edge case that annotations do not capture. It also clarifies that the returned artifact is an image with issues, which is useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly written sentences front-load the core action and return value, then pack usage constraints, persistence, and authentication caveats into minimal words. Every clause adds operational value; there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex mutation tool with 9 parameters and no output schema, the description covers the critical aspects: main actions, parameter grouping, return type (image with issues), save behavior, key requirement, and the non-save exception for beispiel-wohnzimmer. It does not mention index/variant handling in prose, but those are fully covered in the schema, so the description is sufficiently complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with detailed descriptions for all 9 parameters, so the baseline is 3. The description's parameter guidance ('Send x and y together (piece center, meters), rot, or remove true') reinforces the schema but does not add new semantic information beyond what is already in the parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Moves, rotates or removes one piece in the saved layout', which is a specific verb+resource combination that clearly differentiates this tool from siblings like place_furniture (adding new pieces) and check_plan (checking without moving). It also states the return value ('returns the re-checked plan as an image with issues'), making the tool's function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives operational instructions ('Send x and y together ... rot, or remove true') and implies iterative use ('read them and move again if needed'), but it never explicitly says when to use this tool versus alternatives like place_furniture or set_door. No exclusions or alternative routing is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call only after the last check_plan returned no issues. Returns view_url (read-only, to share) and edit_url (for the owner, with the scaled PDF download). Needs key; not available on beispiel-wohnzimmer.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Purchase token rp_ plus 20 characters, from the purchase confirmation. Required on projects you created, not on beispiel-wohnzimmer. Not the project id. | |
| new | No | true creates a new view_url and invalidates the previous share link. Only if the user wants that. | |
| project | Yes | Plan id from create_room. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint false and destructiveHint false. The description adds the key requirement and availability constraint, but omits the side effect of the 'new' parameter (invalidates previous share link) which is a potentially destructive behavior. Since annotations don't cover this, the description should have disclosed it. No contradiction, but a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the critical precondition, followed by the returns and key constraint. No fluff, efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-param tool with no output schema, the description covers the main flow (returns URLs, key requirement) but omits the 'new' parameter's effect on share links. It also doesn't state what happens if called prematurely, though the precondition implies it. The missing invalidation behavior is a notable gap for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mentions 'Needs key' which echoes the schema's key description, adding no new meaning. It doesn't explain 'project' or 'new' beyond schema. So it adds no value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns view_url and edit_url for a plan, with a clear precondition (after check_plan passes). It distinguishes from check_plan by being a follow-up, but it doesn't explicitly say 'opens a plan' or differentiate from show_plan. The purpose is clear enough for an agent to infer the action from the name and returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call ('only after the last check_plan returned no issues') and gives a constraint ('Needs key; not available on beispiel-wohnzimmer'). It doesn't name alternatives or say when not to use, but the precondition is strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Places furniture and returns the checked plan as an image plus placed, rejected, issues and image_prompt. Send exactly one of spots, placement, or wish. Prefer spots: you name each piece and a rough position (at), the server finds the exact spot, snaps to a 5 cm grid and avoids walls, doors and other pieces. Use placement only when the user gives exact positions; never invent x, y or rot. Use wish only when the user describes the room without naming pieces; it calls Roomproof's own model, is slower and less predictable. Every way is checked against the floor area, overlaps, blocked areas and a 0.9 m path; what does not fit comes back in rejected with a reason. Dimensions in millimeters; x and y in meters to the CENTER of the piece, from the room's top-left corner. Needs key on your own project, free on beispiel-wohnzimmer (nothing is saved there).
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Purchase token rp_ plus 20 characters, from the purchase confirmation. Required on projects you created, not on beispiel-wohnzimmer. Not the project id. | |
| keep | No | Default false: the new pieces replace everything in the plan. true adds them to the pieces already there. | |
| name | No | Name of the saved variant, default Draft. | |
| wish | No | One sentence describing the room, e.g. a living room for four with a reading corner. Only without spots and placement. | |
| spots | No | Preferred. 1 to 40 pieces, each with catalog or with name plus width_mm and depth_mm, plus at. Larger pieces are placed first. | |
| blocked | No | Rectangles that must stay free (radiator, wall cupboard, walkway): x, y, w, h in meters from the room's top-left corner, not piece centers. Door swings are added automatically. | |
| outdoor | No | With wish only: limit the model to outdoor furniture, for terraces and balconies. | |
| project | Yes | Plan id from create_room, or beispiel-wohnzimmer. | |
| placement | No | Exact positions from the user, 1 to 60 pieces. Each with catalog or with name plus width_mm and depth_mm, plus x, y (meters to the piece center) and rot. Nothing is nudged: a piece that sticks out or overlaps is rejected. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate non-readonly, non-destructive, non-idempotent, non-open-world, but the description adds substantial behavioral detail: checks against floor area, overlaps, blocked areas, 0.9m path, rejected pieces with reasons, no nudging for placement, and that nothing is saved on beispiel-wohnzimmer. This goes well beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured and front-loaded with the core purpose and the 'exactly one of' rule. Every sentence adds value; however, the density is high and could be slightly tightened. It is still efficient given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully explains the return payload (image plus placed, rejected, issues, image_prompt). It covers all three modes, the validation logic, the key requirement, and the difference between spot-based and placement-based invocation. Nothing essential is missing for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds crucial semantics: coordinate system (x,y in meters to CENTER from top-left), units (millimeters for dimensions), and clarifies the 'at' parameter values. It also explains the difference between blocked rectangles and piece centers, which is not obvious from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: placing furniture and returning a checked plan image with detailed outputs (placed, rejected, issues, image_prompt). It also distinguishes the three modes (spots, placement, wish) and differentiates from siblings like move_furniture by focusing on placement of new pieces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use each mode: 'Prefer spots...', 'Use placement only when the user gives exact positions; never invent x, y or rot.', 'Use wish only when the user describes the room without naming pieces.' It also mentions the key requirement (own project vs beispiel-wohnzimmer) and the default behavior of replacing vs keeping pieces.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free, no key. Turns a product link (IKEA, any furniture shop) or the pasted text of a product page into real dimensions: name, width_mm, depth_mm, height_mm, price, link. Call it as soon as the user gives a furniture link. On success pass name, width_mm, depth_mm, height_mm, price and link unchanged into a custom piece in place_furniture. If blocked is true, ask the user to paste the product page text and call read_product again with that text as input. Never guess millimeters; a missing dimension is listed in missing.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | A product URL, or the pasted text of the product page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds meaningful behavior beyond those fields: it is free and needs no key, it can block and require a retry with pasted text, it will not guess missing millimeter dimensions, and it reports missing fields. This gives the agent a clear behavioral model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: product scope, cost/auth, call timing, output fields, downstream handoff, error handling, and a guardrail against guessing. It is front-loaded with the most important facts and has no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining return values and does so thoroughly: name, width_mm, depth_mm, height_mm, price, link, blocked, and missing. It also covers input variants and failure recovery. An agent has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes input as a URL or pasted text. The description enriches this by naming example sources (IKEA, any furniture shop), spelling out the parsed output fields, and clarifying the blocked-and-retry path. It goes beyond the schema without being redundant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete action ('Turns a product link ... or pasted text ... into real dimensions') and lists the exact output fields. It is clearly distinct from all siblings, which handle rooms, furniture placement, and plans. No ambiguity about what this tool extracts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to call it: 'as soon as the user gives a furniture link.' It also gives a fallback condition ('If blocked is true, ask the user to paste the product page text and call read_product again') and a downstream instruction to pass results into place_furniture. This is strong, actionable usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replaces the full openings list of a project you created (an empty list removes all). Windows have no hinge. Until openings exist, door-swing clearance is not checked. Saved layouts may get new issues afterwards; run check_plan. Needs key; not available on beispiel-wohnzimmer.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Purchase token rp_ plus 20 characters, from the purchase confirmation. Required on projects you created, not on beispiel-wohnzimmer. Not the project id. | |
| project | Yes | Plan id from create_room. | |
| openings | Yes | All doors and windows of the room, 0 to 20. Replaces the existing list completely. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, idempotentHint=true), the description discloses key behavioral traits: complete replacement of the openings list, windows having no hinge, door-swing clearance not being checked until openings exist, and potential new issues in saved layouts. It also notes the key requirement and exclusion of beispiel-wohnzimmer, adding significant value beyond structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loading the core behavior and then adding critical conditions and side effects. No filler; every sentence earns its place, covering scope, constraints, and post-conditions efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, nested openings array) and absence of an output schema, the description covers everything an agent needs: prerequisites (key), scope (full replacement), special cases (windows, clearance), side effects (new issues, run check_plan), and availability restrictions (beispiel-wohnzimmer). It is complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for each parameter, including the 'openings' array's replacement semantics and the hinge parameter's door-only constraint. The description mostly repeats these details (e.g., 'Windows have no hinge') rather than adding new meaning, so it aligns with the baseline 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Replaces') and resource ('full openings list of a project you created'), and distinguishes itself from siblings by focusing solely on doors and windows. It also clarifies the scope (full replacement, empty list removes all), which is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage conditions: it requires a key, is not available on beispiel-wohnzimmer, and only applies to projects the user created. It also implies when to use it (when setting doors/windows) and directs the agent to run check_plan afterwards, though it does not explicitly contrast it with alternatives like place_furniture.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free, no key. Lists every piece Roomproof knows: catalog id (ASCII slug, copy it exactly), display name, width_mm, depth_mm, group. Call it with no group first. Custom pieces (name plus width_mm and depth_mm, e.g. from read_product) do not need the catalog.
| Name | Required | Description | Default |
|---|---|---|---|
| group | No | Optional filter. Must be one of the strings in groups from a previous show_catalog response, e.g. Living or Outdoor. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive behavior. The description adds useful context beyond that: no key required, the exactness of catalog IDs, and the expectation that an unfiltered call comes first. It does not contradict any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, front-loaded sentences with no filler. The essential facts—what is listed, how to copy IDs, and the initial call pattern—are packed efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only catalog tool with one optional parameter and no output schema, the description fully covers what the agent needs: returned fields, ID handling, grouping, and the recommendation to start unfiltered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the existing parameter description already explains that group must come from a previous show_catalog response. The description adds only the 'call with no group first' hint, so it does not meaningfully expand on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action and resource: 'Lists every piece Roomproof knows' with an exact set of returned fields. It also differentiates from related tools by noting that custom pieces from read_product do not need the catalog, so an agent can tell when this tool is relevant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit operational guidance: call with no group first, and copy catalog IDs exactly. It also states an exclusion ('Custom pieces ... do not need the catalog'), though it does not name a direct alternative tool or fully explain when to prefer siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the saved plan as an image drawn to scale, plus image_prompt and image_positions. For a photo of the room copy image_prompt verbatim into your own image generator; Roomproof does not render photos. Needs key on your own project, free on beispiel-wohnzimmer.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Purchase token rp_ plus 20 characters, from the purchase confirmation. Required on projects you created, not on beispiel-wohnzimmer. Not the project id. | |
| project | Yes | Plan id from create_room, or beispiel-wohnzimmer. | |
| variant | No | Variant id from a previous response; default the newest. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark the operation as read-only, idempotent, and non-destructive; the description adds valuable behavioral context beyond that by clarifying that Roomproof does not render photos and that the key is required only on user-created projects. This extra context helps the agent set correct expectations and avoid failed calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler, front-loading the primary purpose, then immediately covering the photo-rendering limitation and the authentication requirement. Every sentence contributes distinct information needed for correct invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description adequately summarizes the return values and the key condition. It could further explain what image_positions contains or what 'drawn to scale' means for the output, but the core information needed to select and call the tool is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage for all three parameters. The description adds meaningful semantic context for the key parameter by explaining when it is required and that it differs from the project id, which goes beyond the schema's raw description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a saved plan as a scaled image plus image_prompt and image_positions, using a specific verb and resource. It does not explicitly differentiate from sibling tools like open_plan, but the output-focused phrasing makes the core purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a saved plan image and gives actionable guidance about copying image_prompt for photo generationributed. It also notes the key requirement for user-created projects. However, it does not explicitly state when to prefer this tool over alternatives such as open_plan or check_plan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_plancreate_roommove_furnitureopen_planplace_furnitureread_productset_doorshow_catalogshow_planYour AI builds, checks and compares 2D/3D floor plans and spaces, and simulates queues and robots.
Design homes with your AI: floor plans, furniture, joinery, lighting and photos, live.
AI virtual staging for real estate — stage rooms, beautify floor plans, classify images.
AI virtual staging and architectural rendering: stage rooms, render interiors, exteriors, sketches.
Add one secure layer between your agents and this server.
