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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the document is locked exclusively during the operation and that length/width/height must be positive, but it does not cover permissions, error behavior, or whether changes are reversible.

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, front-loaded with the action, followed by the concurrency constraint and parameter constraints. There is no repetition or 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?

The output schema means return values need not be explained, and the nested schema covers individual parameter meanings. The description adds the important locking behavior and numeric constraints; it could be stronger on error cases or permissions, but is largely complete for this local mutation tool.

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 nested schema already documents each property with descriptions and defaults, though the top-level 'params' object lacks a schema description. The tool description adds meaningful constraints — positivity and millimetres — for length, width, and height, but says nothing about document_id, object_name, or workspace.

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: 'Add a Part::Box to an existing document.' The resource name 'Part::Box' clearly differentiates it from sibling tools such as create_cylinder and create_document.

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 phrase 'existing document' implies a prerequisite, but there is no explicit guidance on when to use this tool versus create_cylinder or create_document, nor any exclusions or alternative-selection advice.

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 and usefully discloses the exclusive document lock and positive-value constraints. However, it does not explain failure behavior, permissions, or side effects such as object-name collisions, so transparency is only adequate.

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 two tight sentences with the operation and key preconditions front-loaded. Every sentence contributes useful information without 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 create tool with a rich input schema and an output schema, the description supplies the essential context: existing document requirement, exclusive lock, and positive radius/height. Remaining gaps around permissions and error conditions are minor but 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 schema already documents document_id, workspace, object_name, units, and defaults; the description adds the important positivity constraint for radius and height. It still omits behavioral meaning for workspace and object_name, so it adds some value but does not fully compensate for the remaining gaps.

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: adding a Part::Cylinder to an existing document. This clearly distinguishes it from sibling tools such as create_document, create_box, and other shape/object tools.

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 phrase 'to an existing document' establishes the key precondition and implicitly routes new-document scenarios to create_document. It does not explicitly discuss alternatives among shape-creation tools, but the resource-specific name makes the distinction clear.

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 well: it discloses atomic persistence, filename validation rules, the exact storage path, and that the metadata revision is initialized to 1. It omits write-conflict semantics — whether an existing document_id is overwritten or rejected — which is the main remaining behavioral gap for a mutation 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?

Three tight sentences, front-loaded with the core action, followed by the validation/path contract and the sibling hand-off. Nothing is redundant or buried.

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?

An output schema exists, so return-value explanation is correctly omitted, and the description supplies the write semantics an agent needs before invoking. The missing piece is collision/overwrite behavior for an already-existing document_id, which matters for a creation tool.

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 reported as low, so the description usefully compensates: document_id must be safe-filename characters (letters, digits, '.', '_', '-') capped at 64 chars, and its effect on the storage path is spelled out. The optional workspace parameter is left to the schema, keeping this just short of full 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?

States a specific verb and resource ('Create a new empty FreeCAD document') along with scope (atomic save to the controlled workspace). The word 'empty' plus the pointer to create_box/create_cylinder makes it unmistakably distinct from the geometry-creating 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 closing sentence routes the agent: use create_box or create_cylinder to add geometry, implying this tool is the prerequisite container-creating step. It gives clear context but never states an explicit exclusion (e.g., what to do if the document already exists).

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 and does disclose useful behavior: default selection is all Part objects, the default path is <workspace>/<document_id>.step, and custom paths are constrained to the controlled workspace. It does not state whether an existing file at step_path is overwritten, what permissions are needed, or whether the source document must be saved first.

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 compact sentences, front-loaded with the core action and immediately followed by the selection rule and the path rule. Some content restates the schema defaults, but nothing is wasted or buried.

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?

Return values are covered by the output schema and the path/selection behavior is spelled out, so the essentials are present. For an unannotated mutation-style tool, the description should also address overwrite semantics and failure conditions, which it omits.

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 prose explains each parameter's role (object_names narrowing the export set, step_path vs the default, workspace as the containment boundary) and adds the constraint that custom paths must remain within the controlled workspace, which the schema does not state. This compensates for the reported low schema coverage and adds semantics beyond the raw field definitions.

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?

Names a specific verb (export) and resource (document objects) plus the target format (STEP), which clearly separates it from siblings like save_document or validate_document. It stops short of explicitly naming the nearest sibling as the alternative.

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 conditional guidance for the object_names parameter (only those objects vs all Part objects) and for the output path, which implies when to use each mode. It offers no explicit guidance on when to choose this tool over save_document or other export-related workflows, leaving tool selection to inference.

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?

No annotations are provided, so the description carries the full burden. It does add real value: it declares the call non-mutating and safe at any time, discloses the failure path (available=false plus guidance), and sketches the success payload. It doesn't mention cost, latency, or whether repeated calls re-probe the installation, but for a trivial read-only check the disclosure is adequate rather than rich.

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 sentences, front-loaded with the core purpose, then the return shape, then the failure mode and safety note. Every sentence adds distinct information with no repetition of the title.

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?

The tool takes no parameters, is a simple read-only probe, and has an output schema for the returned fields. The description covers the one thing the schema cannot: what happens when FreeCAD is absent, and that calling it is always safe.

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?

Zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies a no-argument invocation.

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?

Uses a specific verb ('Report') against a specific resource (a usable FreeCAD installation) and enumerates what is returned: version, embedded Python version, Part workbench availability. It implicitly separates itself from sibling tools like server_info and the create_* tools by being purely a reachability check, though it never names that sibling to sharpen the distinction.

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?

'Safe to call at any time' clearly signals it is a non-destructive preflight/health check, and 'Returns available=false with guidance when FreeCAD is missing or fails to start' tells the agent what to expect on failure. It stops short of explicitly routing the agent here before calling create_document or other FreeCAD-dependent siblings.

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 implies a read-only lookup but says nothing about failure behavior when the object name is unknown, whether the document must be loaded, or how workspace scoping affects the lookup. The only real disclosure is the field list, which is arguably return-value territory already covered by the output schema.

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 front-loaded sentence with no filler. It loses a point because most of its payload enumerates return fields (type, shape, volume, dimensions) that the output schema already defines.

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 annotations and an output schema that already documents returns, the description should spend its words on inputs and failure modes; instead it duplicates the return surface and leaves parameters and error conditions unaddressed.

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 description mentions only 'by name', giving no meaning for document_id or the optional workspace parameter, so it does not compensate for the reported 0% schema description coverage. An agent learns which inputs matter purely from 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 verb and resource ('Return detailed information about a single object by name'), which clearly separates it from the enumeration sibling list_objects. It stops short of naming any sibling explicitly, so it lands just below the top band.

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 'by name' phrasing implies it operates on one already-known object, but there is no explicit when-to-use, no prerequisite about the document being open, and no pointer to list_objects for discovery or to create_* tools for other purposes.

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?

No annotations are provided, so the description carries the full behavioral burden. It communicates that objects are listed and describes returned fields, but it does not state read-only behavior, permission requirements, error behavior, or whether listing has any side effects.

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 front-loaded sentence with no filler. It communicates the core action and the return information 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?

The output schema already covers return values, so the description needn't explain them in detail. For a simple read-style listing tool this is minimally adequate, but missing parameter guidance and behavioral details leaves clear gaps given the absence of annotations.

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 description does not mention the required `document_id` parameter or the optional `workspace` parameter and its default. With the provided context signaling 0% schema description coverage, the description should compensate but does not.

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 ("List all objects in a document") and specifies the returned fields, so the operation is understandable without the schema. It does not explicitly distinguish itself from the sibling `inspect_object`, which is the main clarity gap.

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 phrase "List all objects in a document" implies when to use the tool: when an inventory of all objects is needed. However, it does not state when not to use it or direct the agent to alternatives such as `inspect_object` for a single object.

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 usefully discloses that the document is locked during the operation. However, it does not cover permissions, whether the recompute is reversible, error behavior, or other operational constraints.

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 sentences, front-loaded with the core action and followed by the relevant usage trigger and locking behavior. No wasted wording.

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?

An output schema exists, so return values need not be described. But with no annotations and weak parameter coverage, the description should do more to explain document selection, workspace handling, and operational side effects.

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 description refers only to the 'active document' and never explains the document_id parameter or workspace parameter. Given the reported 0% schema description coverage, the description does not compensate for the missing parameter guidance.

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: recomputing the active document geometry. It is clear what the tool does, though it does not explicitly differentiate itself from validation or save 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?

It gives a clear usage trigger: useful after modifying parameters to update the model. It does not name alternatives or exclusions, so it falls short of full when/when-not 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 the behavioral burden and does well by disclosing atomicity, equivalence to auto-save, and that a successful save increments the document metadata revision. It omits failure behavior, permission requirements, and whether it overwrites unsaved changes, leaving some mutation semantics unclear.

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 sentences, front-loaded with the core action and followed by useful behavioral context. There is no wasted text and the key equivalence to auto-save is easy to extract.

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?

The output schema is present, so return values need not be described. The description covers the important save behavior and revision increment, though it could say more about error cases and the workspace parameter for a mutation tool with no annotations.

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

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

The description refers only to the 'current document' and does not explain the document_id or workspace parameters. With the context signal indicating low schema description coverage, the description should compensate but does not add meaningful parameter semantics.

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 gives a specific verb and resource: explicitly saving the current document atomically. It also distinguishes this from the automatic saves triggered by create_box/create_cylinder/set_parameter, so an agent can tell it apart from sibling mutation tools.

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 clearly explains that this is equivalent to auto-save but can be called independently, giving a usable context for when to invoke it. It does not explicitly say when not to call it or name an alternative explicit-save path, so it falls short of 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 behavior burden well: it discloses that no FreeCAD connection is made and that the call is always safe, plus the exact information returned. It doesn't mention side effects beyond that (e.g., whether environment reporting is expensive), but the safety profile is clear.

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 tight sentences, each earning its place: what is returned, the parameter's effect, and the safety/no-FreeCAD constraint. The key scoping claim is front-loaded.

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?

An output schema exists, so return-value explanation isn't required, yet the description still summarizes the payload and covers the safety constraint and the parameter. Nothing an agent needs in order to call this correctly 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?

Schema description coverage is 0%, so the description must explain the single parameter — and it does: include_environment=true additionally reports the host Python environment. The default-false behavior is only implied ('also'), not stated outright, keeping it from a 5.

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 ('Return diagnostic information about this freecad-mcp server') and enumerates exactly what is reported: name, version, MCP SDK version, and FreeCAD bridge status. It also implicitly distinguishes itself from freecad_status by declaring it does not contact FreeCAD.

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?

Provides clear call context ('safe to call at any time', 'does not contact FreeCAD') and a conditional usage rule for include_environment=true. It never explicitly names a sibling alternative to use instead, so it falls just short of the top mark.

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 well: it discloses that only whitelisted properties are allowed, values must be positive millimetres, and the document is exclusively locked during the operation. It still omits permission requirements and error behavior, but the mutation and locking behavior are clearly surfaced.

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 front-loaded, appropriately short, and structured around the core operation, whitelist, value constraint, and locking behavior. Every sentence contributes useful invocation context.

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 mutation tool with no annotations, it covers the critical preconditions: existing document/object, whitelisted property, positive millimetre value, and exclusive locking. An output schema exists, so return values need not be explained, and the main remaining gap is the optional workspace parameter.

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 description adds useful meaning for property_name via the Box/Cylinder whitelist and for value via the positive-millimetres constraint. However, with reported schema coverage at 0%, it does not compensate for all parameters because the optional workspace parameter is not explained in the 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?

States a specific verb and resource: changing a whitelisted parameter on an existing object. It clearly distinguishes modification from sibling creation tools by specifying an existing object, though it does not explicitly name alternatives.

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?

Implies when to use it by saying it changes whitelisted parameters on existing objects and lists the eligible Box/Cylinder properties. However, it gives no explicit when-not guidance or direct routing versus siblings like inspect_object, validate_document, or create_box.

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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that the document is locked exclusively during the operation and that dimensions must be positive, but it does not state what happens if the document is missing, already locked, or how failures are surfaced.

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 short sentences with the action and target front-loaded, followed by the positivity constraint and the locking behavior. There is no redundant or filler text.

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?

An output schema exists, so the description need not explain return values. For a mutation tool with no annotations, however, it should ideally mention permission requirements or failure behavior around the exclusive document lock; it currently only states that the lock occurs.

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 description reinforces that length, width, and height are positive millimetre values, which is useful. The nested schema already describes all six parameters, including document_id, workspace, and object_name, so the description adds only marginal meaning beyond 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?

The description states a specific verb and resource: add a rectangular Part::Box (tank) to an existing document. It is clear enough to distinguish this from document creation, but it does not explicitly differentiate itself from the sibling create_box or create_cylinder tools.

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 phrase 'to an existing document' implies the tool is for adding geometry after a document exists, rather than creating one. However, it gives no explicit guidance on when to use this versus create_box, create_cylinder, or other creation tools.

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, and it does disclose a genuinely non-obvious behavioral trait: 'The document is locked exclusively during the operation', which tells the agent about concurrency/blocking. It also states validity constraints (positive millimetre values). What's missing is failure behavior (does the document remain locked on error?) and whether the result needs saving/recomputing.

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 tight sentences: the action and target lead, followed by constraints and the locking caveat. There is no filler, and the most important behavioral note is placed last as a warning.

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?

An output schema exists, so return values need not be explained, and the nested schema fully documents each field. The description supplies the prerequisite (existing document) and the exclusive-lock behavior, leaving only error/recovery and post-creation steps (save, recompute) unstated.

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 description names the four geometric parameters (coil_radius, tube_radius, num_turns, pitch) and repeats their positive-number/millimetre semantics, which the nested schema already documents in detail, while saying nothing about document_id, object_name, or workspace. Since the reported top-level schema coverage is 0% (the 'params' wrapper is undescribed), the description partially compensates but adds no syntax or format detail beyond 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 verb ('Add') and a precise resource ('a tubular helix coil to an existing document'), plus the implementation approach (Part::Helix and pipe). This is clearly distinguishable from siblings like create_box, create_cylinder, or tank, which produce different geometry in presumably new objects.

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 phrase 'to an existing document' implies the prerequisite that a document must already exist, which usefully narrows the call context. However, it never names an alternative (e.g., create_document first, or a plain helix tool if one exists) or states when not to use it, leaving usage to inference.

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?

No annotations are provided, so the description carries the full burden. It discloses the result shape (per-object results plus an all_valid flag) but says nothing about whether the call mutates the document, cost on large documents, or what happens when geometry is invalid (throw vs. report).

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 tight sentences: purpose and validation semantics first, usage timing second. Zero 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?

The output schema means the return values needn't be explained, and the description adds them anyway. But with no annotations and unclear mutation/safety semantics, an agent still lacks enough behavioral context to call this confidently in a destructive-adjacent workflow.

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?

One required parameter (document_id) with low schema description coverage; the description implies document scoping only through 'in a document' and never addresses the workspace default, which is documented only in 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 verb (validate) and resource (document geometry), and defines what 'valid' means: a Solid with positive volume. Scope ('all objects') separates it from per-object siblings like inspect_object and from recompute.

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 timing guidance ('after modifying parameters or before exporting STEP') and implicitly routes the agent relative to export_step. No explicit exclusion or statement about when not to call it, and no mention of recompute as a prerequisite alternative.

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