doc_inspect

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

With no annotations, the description carries the full behavioral burden and does well: it discloses the 100-object cap with `objects_total`, that units are always mm, the accepted file formats, and that `checks.watertight` is the FDM-printability decision. It never explicitly states this is a non-mutating read, which is the one gap given zero annotation coverage.

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: purpose first, then accepted inputs, then return contract, then the downstream consumer of the object names. Dense but 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?

An output schema exists, so return values need not be documented — yet the description still maps the key return fields (`mesh`, `objects_total`, `checks.watertight`) and their significance, making it more than sufficient for correct invocation.

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

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

Schema coverage is 0% and the single `path` param is undocumented in the schema, but the description compensates by enumerating accepted formats (.FCStd, .step/.stp, .iges/.igs, .brep, .stl/.obj/.3mf/.ply) and stating that units are mm — directly useful semantics for supplying a valid path.

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+resource (opens a model and returns dimensions, volume, validity, watertightness) and clearly distinguishes itself from the export siblings by noting that its name/label output feeds doc_export and doc_export_2d's `objects` parameter. An agent immediately knows this is the inspection step vs. the export step.

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?

Cross-references the alternatives explicitly: the returned `name`/`label` values are usable in doc_export and doc_export_2d, which implies inspect-first workflow. It does not spell out an explicit 'do not use this to modify' exclusion, so it falls just 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.