Server Quality Checklist

Tool Scores

• validate_projectA
  3.5/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 that the tool is non-modifying ('does not modify the archive or rewrite canonical order') and states important domain conventions (centimetres, degrees, inverted y-axis). This materially helps an agent predict side effects 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: the core purpose appears first, followed by high-value constraints and an example. Each sentence contributes useful information, and the example is a practical usage hint rather than padding.

  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?

  Since an output schema exists, return-value documentation is not the description's responsibility. The description covers invocation, unit conventions, and side-effect guarantees. The remaining gap is that it does not specify what 'validate' checks or what invalid inputs yield, but this is reasonable for a one-parameter tool with an output schema.

  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?

  The schema provides only a string name and no description, so the example 'project_path='house.sh3d'' adds some meaning by showing the expected form (a local file path). However, the description does not explain path resolution, existence requirements, or accepted file variants beyond the .sh3d extension.

  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 description states a specific verb ('Validate') and resource ('an existing .sh3d project'), clearly distinguishing it from sibling creation/add/list tools such as create_project and add_wall. The example further reinforces what the tool is for, though it leaves 'validate' somewhat open-ended.

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

  Usage Guidelines2/5

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

  No explicit when-to-use or when-not-to-use guidance is provided. The word 'existing' implies it applies to already-created projects, but it does not compare against alternatives like open_reference or explain when validation should be preferred or avoided.

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

• add_wallA
  3.7/5.0
  Behavior4/5

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

  With no annotations, the description carries full behavioral burden and does well: it discloses units (centimetres), coordinate system orientation (y increasing downward), and limitations (does not create rooms, only pairwise multi-wall joins). It does not mention side effects or file mutation, but the output schema covers return structure.

  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 description is compact and front-loaded with the core purpose, followed by essential units/coordinate context and a concrete example. No waste. The caveat about the join model is slightly jargon-heavy but still earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 10 parameters and no annotations, the description covers units, coordinate system, and a key limitation, and the output schema exists. But the optional parameters remain unexplained, and the 'documented pairwise join model' reference assumes external knowledge. It is minimally adequate but leaves meaningful gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0% for 10 parameters, and the description only explains the coordinate/unit meaning of x/y and lengths. It adds no meaning for join, height, thickness, height_at_end, allow_crossing, or project_path. This is insufficient for a 10-parameter tool with no schema descriptions.

  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?

  The description states a specific verb and resource: 'Add a wall to a .sh3d project.' It distinguishes itself from sibling tools like add_room by explicitly noting 'This tool does not create rooms,' avoiding ambiguity.

  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?

  Usage is implied: use this to add walls to .sh3d projects, and it explicitly says it does not create rooms. However, it does not name alternative tools or provide explicit when-to-use versus when-not-to-use guidance beyond the room exclusion.

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

• export_projectA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the disclosure burden. It usefully adds units, coordinate system, and format constraints, but it does not disclose side effects such as overwriting behavior, what happens when destination_path is null, or whether the original file is modified.

  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 description is compact and front-loaded with the core purpose. The units/coordinate sentence may be partially tangential but is brief. The format exclusion and example earn their place, keeping the definition tight.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter tool with an output schema, the description covers the essential purpose and format. However, it omits side effects, optional destination behavior, and any relationship to sibling tools like validate_project, leaving an agent to infer important execution details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/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. The example shows both parameters being used, but it does not explain the meaning of project_path and destination_path beyond their names, nor the default/null behavior of destination_path.

  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 and resource: 'Finalize and rewrite a .sh3d project.' It also scopes the tool by explicitly excluding OBJ, PNG, SVG, and any other format, making its purpose distinct and unambiguous.

  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?

  Provides clear context for use: it is for finalizing/rewriting .sh3d projects, and explicitly says when not to use it (for non-.sh3d exports). However, it does not name alternative sibling tools such as create_project or validate_project, missing the full 5-level guidance.

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

• open_referenceA
  3.8/5.0
  Behavior4/5

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

  With no annotations, the description takes on the burden of behavioral disclosure. It explicitly states a non-modification guarantee, reports length and rotation units, and documents the coordinate system orientation, which are meaningful operational details beyond simply 'inspect'.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured: main purpose first, then units, coordinate system, non-modification assurance, and a concrete example. Every sentence adds useful information with no filler or unnecessary repetition.

  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?

  For a single-parameter tool with an output schema, this is nearly complete. It covers the operation, relevant units, coordinate conventions, non-modification behavior, and an example call. The main missing piece is guidance on when to use it relative to sibling tools, but that is a usage guidance gap rather than a core invocation gap.

  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?

  The schema provides no description for sample_sh3d_path, and the description only partially compensates by referring to a reference .sh3d file and showing an example value. The parameter name is self-explanatory, but path format, source location, and expected file semantics are not fully 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?

  The description clearly identifices the coerce as inspecting a reference .sh3d file and populating the furniture catalogue cache. It uses a specific verb ('inspect') and resource ('reference .sh3d file'), and the non-modification statement helps distinguish it from mutating siblings like create_project and delete_element.

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

  Usage Guidelines2/5

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

  The description gives no guidance on when to use this tool versus alternatives such as validate_project or when it should be called before add_furniture. It includes an example invocation, but no conditions, prerequisites, or exclusion criteria are stated.

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

• delete_elementA
  3.9/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral disclosure burden. It adds meaningful caveats: deletion only clears inbound wall join references and does not repair geometry. It also documents domain conventions (centimetres, degrees, y downward), which helps an agent understand the project model even though those are not direct parameters.

  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 description is compact and front-loaded with the core purpose, followed by caveats and an example. The coordinate-system sentence is mildly tangential to deletion, but it is brief and contextual. Overall, every sentence adds useful context without excessive length.

  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?

  For a simple two-parameter deletion tool, the description provides the purpose, a concrete example, and important behavioral limits. It does not explain what happens when the element does not exist or whether deletion is permanent, but the output schema likely covers return behavior, so this is a minor gap.

  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. It does clarify that element_id is the identifier and project_path is the .sh3d file path, reinforced by the example call. Still, it does not describe ID formats, path handling, or element types beyond 'editable element,' so compensation is only partial.

  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?

  The description states a specific verb and resource: 'Delete an editable element from a .sh3d project by id.' This clearly separates it from sibling tools like list_elements, add_wall, and validate_project, which perform different actions. The example further anchors the intended use.

  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 usage context is implied: use this when you need to delete an element by ID. It also gives a when-not by stating it 'does not delete unsupported tags or repai geometry.' However, it does not name alternative tools or explicitly state when a different tool should be used instead.

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

• add_roomA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the behavioral burden. It discloses important non-obvious details: centimetre units, degree rotations, y-axis orientation, and the tool's refusal to infer walls, repeat the closing point, or auto-split overlapping rooms. This is strong transparency, though it stops short of describing side effects or error behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Each sentence adds value: the action, units/coordinate system, explicit non-behaviors, and a concrete example. It is front-loaded with the essential purpose and contains no fluff or repetition.

  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?

  With an output schema present, the description does not need to explain return values. It provides enough context for typical usage: required parameters, units, coordinate orientation, and key limitations. It is slightly incomplete on optional parameter semantics, but overall it gives a usable picture for a moderately complex tool.

  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. It provides context for project_path and points via the example and units/coordinate system, and shows name usage, but area_visible and allow_overlap are never explained. It helps for the core parameters but leaves gaps for others.

  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?

  Description starts with a specific verb and resource: 'Add a room polygon to a .sh3d project.' It is clearly differentiated from sibling tools like add_wall, add_furniture, and add_dimension, so an agent can immediately identify its role.

  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 description implies use by describing the room-polygon operation and even mentions non-behaviors ('does not infer walls'), but it never explicitly states when to prefer this tool over alternatives like add_wall or when not to use it. Usage context is clear but exclusions are absent.

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

• create_projectA
  4.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 behavioral burden. It discloses units (centimetres, degrees), the coordinate system (y increasing downward), and the tool's limitations. It does not explicitly state overwrite behavior or error handling, but the provided constraints are substantial and non-obvious.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Four concise, purposeful sentences with no fluff. The most important information is front-loaded, and the example invocation makes the primary calling pattern immediately clear.

  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?

  The description covers project creation, units, coordinate conventions, scope limitations, and a concrete example. Given the output schema exists and sibling tools cover additional elements, this is nearly complete; the main missing piece is explicit overwrite behavior when the target file already exists.

  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%, and the description partially compensates by specifying units and giving an example that uses project_path, name, width, and height. However, it does not explain overwrite, wall_height, or wall_thickness beyond the general unit statement, leaving some parameter semantics to inference.

  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?

  The description states a specific action and resource: 'Create a .sh3d project.' It also clarifies scope by noting it does not create multi-level homes or add furniture, which clearly distinguishes it from siblings like add_furniture and add_wall.

  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 description gives clear context: this is for creating a new project shell, optionally with a basic 4-wall rectangle footprint. It also tells the agent what not to expect, which implicitly routes furniture and multi-level work to other tools, though it does not name those alternatives explicitly.

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

• list_elementsA
  4.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 behavioral disclosure burden. It transparently states that the tool does not modify the archive, does not canonicalize element order, and reports units in centimetres and degrees plus the coordinate system. This goes well beyond a basic 'list elements' statement.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Every sentence earns its place: purpose, units, coordinate system, side-effect guarantees, and a concrete example. The most important information is front-loaded and there is no redundant filler.

  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?

  For a simple listing tool with two parameters and an output schema present, the description is nearly complete: it covers side effects, units, coordinate semantics, and usage via example. The main missing piece is the set of valid kind values, but the agent can infer a reasonable call from the example.

  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 for the sparse schema. The example clarifies that project_path is a file path and kinds is a filter list such as ['walls','rooms'], but it does not enumerate the possible kinds values or explain what happens when kinds is omitted. It adds partial meaning but leaves gaps.

  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?

  The description states a specific verb ('List') and resource ('editable elements in a .sh3d project'), making the purpose immediately clear. It is easily distinguished from sibling mutation/validation tools, and the example reinforces the exact action.

  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 description provides clear context: this is the read-only inspection tool for a project's elements, explicitly noting it does not modify the archive. It does not explicitly discuss when not to use it or name alternatives, but sibling tools are all sufficiently different in action that the usage context is clear.

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

• add_dimensionA
  4.4/5.0
  Behavior4/5

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

  With no annotations to carry safety or behavior information, the description discloses important behavioral details: units are centimetres, rotations are degrees, the y-axis increases downward, and the tool does not snap or infer offsets. This adds real behavioral context beyond the schema, though it could mention side effects on the project file or validation behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: the core action appears first, followed by essential measurement conventions, a behavioral caveat, and a concrete example. Every sentence adds useful information without redundancy.

  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?

  For an 8-parameter tool with no annotations, the description covers the most crucial contextual aspects: units, coordinate orientation, non-snapping behavior, and a usage example. It does not explain all parameter semantics explicitly or mention potential errors, but the output schema exists and the description is sufficient for a well-named tool.

  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 for missing parameter documentation. It explains the coordinate system, units, rotation measurement, and provides a concrete example mapping parameters to values. Some parameter meanings remain implicit, but the names and example largely make them understandable.

  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?

  The description states a specific verb ('Add') and resource ('a dimension line to a .sh3d project'), clearly distinguishing it from sibling tools like add_wall, add_room, and add_furniture. The scope is unambiguous.

  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 description provides clear context for use: it is for adding dimension lines with explicit coordinates, and it explicitly notes that snapping and offset inference are not performed. It does not explicitly name alternative tools or state when not to use it, but the purpose and constraints make the appropriate use clear.

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

• add_furnitureA
  4.4/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses units (centimetres), rotation units (degrees), the y-down coordinate system, and important limitations (no door/window binding, cannot invent missing 3D models or unsupported catalogue entries). This goes well beyond a minimal action statement.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded: the purpose appears first, followed by two compact high-value notes on units/coordinate system and limitations, then a concrete example. Every sentence earns its place without filler.

  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?

  For a 12-parameter mutation tool with no annotations, the description provides strong core context: units, coordinate system, limitations, and an example. The presence of an output schema means return values need not be explained. Still, with 0% schema coverage, the semantics of optional parameters and any preconditions like a valid existing project are left implicit rather than explicit.

  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?

  Description adds essential meaning for core parameters: x/y are interpreted in the y-down coordinate system, rotation is in degrees, and lengths are in centimetres. The example also demonstrates project_path and catalog_id usage. However, with 0% schema_description_coverage, optional parameters like depth, width, height, elevation, room_name, and allow_overlap rely only on their names for semantics.

  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?

  The description opens with 'Add furniture to a .sh3d project', using a specific verb and resource. It clearly differentiates from sibling tools like add_wall, add_room, and add_dimension by targeting furniture, and explicitly states it does not bind doors or windows to walls.

  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 tool's purpose implies it should be used when furniture needs to be added, and the example shows a typical invocation. However, there is no explicit comparison to sibling tools or guidance on when not to use it; the limitation notes are exclusions rather than routing to alternatives.

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