Roomproof

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses non-mutating behavior ('Does not place, move or spend a wish'), the key requirement for projects, and the expected success condition. It does not explicitly say 'read-only' but implies it through the negation, which is sufficient. Minor gap: no mention of side effects like caching or pricing beyond the key note.

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 zero redundancy: it front-loads the purpose, then usage, then key requirement. Every sentence earns its place, and the structure is logical (what it does, when to use, condition for success, auth note).

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 validation tool with no output schema, the description adequately covers what it checks, when to call it, the condition for success, and the key requirement. It also differentiates from siblings, so an agent has all information needed to select and 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% with detailed descriptions for each parameter, including the key's format and applicability. The description restates the key requirement but adds no new meaning beyond the schema. Thus it meets the baseline for high schema coverage without adding extra value.

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 verb and resource: 'Re-checks the saved layout only' and enumerates specific checks (pieces sticking out, overlaps, blocked areas, 0.9 m path). It also distinguishes itself from siblings by explicitly noting 'Does not place, move or spend a wish,' so an agent can tell it apart from move_furniture and place_furniture.

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 explicit guidance on when to use: 'Call it after move_furniture or when issues are unclear.' It also defines the condition for a sibling tool: 'ok true with an empty issues list is the condition for open_plan,' and clarifies what it does not do, which prevents misuse.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden, and it delivers: it discloses the no-key/free nature, scale, return payload, the requirement to send openings in the same call, the checker behavior when openings are omitted, dimension ranges, and the coordinate system. This goes well beyond a minimal mutation description and gives the agent accurate expectations of side effects and outputs.

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 compact and dense, front-loading the most important facts (free, no key, creates plan, returns IDs), then covering alternatives, the openings requirement, constraints, and coordinates. Every sentence carries actionable information with 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 create tool with no output schema and no annotations, the description covers the essential context an agent needs: what it returns, how to choose between shape representations, mandatory openings behavior, numeric bounds, and coordinate orientation. Nothing critical is missing for 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?

Although schema coverage is 100%, the description adds crucial cross-parameter meaning not available in the schema: the mutual exclusivity of width_m/depth_m versus rectangles, the requirement to include openings, and the coordinate origin convention ('x to the right, y down, origin at the room's top-left corner'). This transforms bare parameter definitions into callable instructions.

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 specific action and resource: 'Creates a new plan at scale 1:50' and states what it returns ('project id plus purchase_url'). This clearly distinguishes it from sibling tools like check_plan, move_furniture, and show_plan, which perform different actions on existing plans. The purpose is immediately obvious.

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 clear operational guidance: use either width_m/depth_m or rectangles, 'never both', and always send openings in the same call. It also explains the consequence of omitting openings. It does not explicitly name sibling alternatives or state when not to use this tool, but the guidance for correct invocation is strong and excludes ambiguity.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of behavioral disclosure. It explains that the result is saved even when issues exist, mentions the key requirement, notes that beispiel-wohnzimmer is not saved, and says the response is a re-checked plan image. This is strong context, though it does not discuss reversibility or failure modes.

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 with no filler: the first states the action and result, the second covers parameter usage, and the third covers authentication and persistence. Key information is front-loaded and every sentence earns its place.

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 9 parameters, no output schema, and no annotations, the description is remarkably complete: it explains the return value, side effects, authentication, and the main operation modes. The schema covers individual parameter details, and the description supplies the coordination rules needed 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?

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining operational constraints: x and y must be sent together, coordinates are in meters, and remove true means x/y/rot are ignored. This helps agents invoke the parameters correctly.

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 specific operations ('Moves, rotates or removes one piece in the saved layout') and the result ('returns the re-checked plan as an image with issues'). This clearly differentiates it from siblings like place_furniture, which adds new furniture, and check_plan, which only checks the 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?

The description gives concrete invocation guidance: send x and y together, use rot for rotation, or remove true; it also clarifies the key requirement for own projects vs free usage on beispiel-wohnzimmer. It does not explicitly name alternative sibling tools, but the usage context is clear enough.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses the key requirement, the read-only nature of view_url, and the owner-only edit_url, plus the availability constraint. However, it does not mention the side effect of the 'new' parameter invalidating previous share links (though that is covered in the schema) or any error behaviors when called prematurely. The description adds some value but lacks deeper behavioral 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?

The description is a single, tightly written sentence with no filler. It front-loads the critical precondition and then lists outputs and constraints efficiently. Every clause earns its place.

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?

There is no output schema, so the description must explain returns, which it does clearly. It covers prerequisites (key), availability, and the intended use case. It does not mention the 'new' parameter's effect, but that is fully described in the input schema. For a tool with three parameters and a clear precondition, the description is sufficiently complete for an agent 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%, so all parameters are documented. The description adds context by clarifying that the key is required on created projects and not on beispiel-wohnzimmer, and that the project is the plan id from create_room. This enriches the schema descriptions and helps the agent correctly map parameters to the tool's domain.

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: it returns view_url and edit_url for a plan, and includes a precondition referencing check_plan. It clearly identifies the resource (plan) and the outcome (sharing/editing links). However, it does not explicitly differentiate from sibling show_plan, leaving some ambiguity about when to choose one over the other.

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 states when to call it ('only after the last check_plan returned no issues') and provides a clear exclusion ('not available on beispiel-wohnzimmer'). It also mentions the key requirement. It does not explicitly name alternatives like show_plan, but the precondition and availability constraint give strong contextual guidance.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full disclosure: it covers validation checks (floor area, overlaps, blocked areas, 0.9 m path), coordinate units and origin, the 5 cm grid snapping for spots, the fact that placement pieces are never nudged and are rejected if they stick out or overlap, and persistence behavior (nothing saved on beispiel-wohnzimmer). This is far beyond a bare 'places furniture' statement and gives the agent an accurate 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?

A single dense paragraph front-loads the action and output, then the three-mode decision, then the universal constraints and coordinate conventions. Every sentence adds decision-relevant information, with no filler or repetition of the schema.

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 9-parameter tool with no output schema and no annotations, the description covers the essential decision framework (which mode to send), key output shape, geometric constraints, units/origin, and the authentication caveat. Nothing critical is missing for an agent to select and 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%, so the baseline is 3, but the description adds critical cross-parameter semantics: the three mutually exclusive modes, their precedence ('Prefer spots'), and the guardrail never to invent x, y, rot. It also clarifies the measurement conventions for x/y as meters to the piece center from the room's top-left corner, which is unambiguous and supplements the per-parameter schema text.

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 verb and resource ('places furniture') and enumerates the return payload (image plus placed, rejected, issues, image_prompt), which distinguishes it from siblings like move_furniture and check_plan. The first sentence already conveys the tool's core action and output.

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 instructs to send exactly one of spots, placement, or wish and gives preference rules with conditional triggers ('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 notes the key requirement vs. the free beispiel-wohnzimmer project, covering both when and when-not scenarios.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden, and it delivers: it discloses free/no-key access, accepted input types, the output contract, the blocked-state behavior, and the missing-dimension convention. It even warns against guessing dimensions. This gives the agent a reliable mental model of the tool's behavior.

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?

Every sentence contributes necessary information: access model, inputs, outputs, invocation timing, success/failure flow, and a safety rule. The description is compact and well-organized, with the core action stated early and 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 one-parameter tool with no output schema and no annotations, the description is unusually complete. It covers what to pass in, what to expect back, how to recognize a blocked result, how to retry, and what to do with successful output. Nothing essential is missing.

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 schema already describes the single `input` parameter at 100% coverage, so the baseline is 3. The description adds value by specifying supported link types (IKEA, any furniture shop), the paste-text fallback, and the retry semantics, which go beyond the schema's one-line parameter 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 uses a specific verb and resource: it turns a product link or pasted product page text into concrete dimension fields (name, width_mm, depth_mm, height_mm, price, link). This clearly distinguishes the tool from siblings like place_furniture, move_furniture, or show_catalog.

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 tells the agent when to call the tool ('as soon as the user gives a furniture link'), how to handle failure (if blocked, ask for pasted text and retry), and how the result should be used downstream ('pass ... into a custom piece in place_furniture'). The 'never guess millimeters' rule prevents a common incorrect behavior.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description takes full responsibility for behavioral disclosure. It reveals the destructive full-replacement behavior, that an empty list removes all openings, that windows have no hinge, that door-swing clearance is only checked once openings exist, and that saved layouts may gain new issues. This is exemplary for a mutating tool.

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?

Every sentence earns its place: replacement semantics, empty-list behavior, hinge constraint, downstream side effects, and access prerequisites. The most important behavior is front-loaded, and the description is compact with 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?

Given full schema coverage, no output schema, and no annotations, the description covers everything an agent needs: what the tool replaces, side effects on layout validation, post-invocation guidance, and access constraints. No critical behavioral gap remains.

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%, so the schema already documents key, project, and openings in detail. The description adds useful context about the list being a full replacement and that an empty list clears all openings, but it does not add substantial per-parameter semantics beyond what the schema provides, warranting the baseline 3.

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 first sentence states a specific verb and resource: 'Replaces the full openings list of a project you created.' This goes beyond the title by clarifying that the tool operates on the entire openings list, not individual doors or windows, and distinguishes it from furniture placement or plan-checking siblings.

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 clear context: it applies to projects you created, requires a key, is unavailable on beispiel-wohnzimmer, and advises running check_plan afterward. It does not explicitly name alternatives or say when not to use it beyond the beispiel restriction, which keeps it from a 5.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden itself. It discloses no key/auth requirement, warns that the catalog id is an ASCII slug to copy exactly, and lists the returned fields so the output shape is predictable. It does not mention pagination or ordering, but for a read-only catalog listing this is a minor 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?

The description is compact: it front-loads the key facts ('Free, no key', 'Lists every piece') and follows with exactness warning and usage guidance. Every sentence earns its place with 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?

Since there is no output schema, the description supplies the essential return fields (catalog id, display name, width_mm, depth_mm, group) and explains the optional group filter. An agent has everything it needs to make a correct first call and interpret the response.

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 covers 100% of the group parameter and describes it well, so the baseline is 3. The description adds 'Call it with no group first' as practical usage context, which is meaningful but not extensive extra semantic detail.

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 and resource: 'Lists every piece Roomproof knows' and enumerates the exact fields returned. It also distinguishes standard catalog items from custom pieces read via read_product, so an agent can tell it apart from sibling tools like show_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 instructs the agent to 'Call it with no group first' and notes that custom pieces 'do not need the catalog', giving clear when-to-use and when-not-to-use guidance. The 'Free, no key' statement also removes any auth prerequisite ambiguity.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden. It discloses the return payload, the scale rendering, the photo limitation ('Roomproof does not render photos'), and the key requirement. It does not explicitly claim the operation is side-effect-free, but 'Returns' plus the absence of mutation language is meaningful.

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 with no filler. The main return value is front-loaded, and the following sentence supplies the most important usage caveats: photo handling, the key requirement, and the free example project.

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 one required parameter naturally derived from the schemacing flow und no output schema, the description covers the return artifact, the intended use of image_prompt, and the authentication prerequisite. An agent has enough to decide when to call it and what to pass.

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?

All three parameters are already documented in the schema, giving 100% schema coverage, so the baseline is 3. The description reinforces the key exception for beispiel-wohnzimmer but adds no new parameter semantics beyond what the schema already states for project and variant.

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 first sentence names a concrete action and resource: it returns 'the saved plan as an image drawn to scale, plus image_prompt and image_positions.' This clearly distinguishes the tool from siblings like open_plan and check_plan by describing its specific output artifact, though it never explicitly contrasts itself with those siblings.

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 practical context about when a key is needed and how to use the image_prompt for photos, which implies usage. However, it does not explicitly say when to prefer show_plan over open_plan or check_plan, and it lacks any when-not-to-use guidance.

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