plasticity_download_and_import_parasolid

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

Annotations already mark this as a destructive, open-world write, but the description adds real behavioral detail: DNS pinned to public IPv4, redirect/size/content-header/revision/hash checks, and the returned payload (compact document state plus changed body IDs/count). It stops short of stating failure modes or auth requirements beyond the hostname restriction.

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?

Dense but well front-loaded: the core action leads, then requirements, then the return note and validation summary. Three long sentences carry a lot of load with little filler, though the trailing validation clause reads as a run-on.

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 4-param nested-object tool with no output schema, the description covers source selection, representation choice, and what is returned. Gaps are minor: no guidance on the confidence/sourceKind enums and no statement of what happens on a failed validation check.

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?

With 0% schema description coverage the description must compensate, and it does: it explains source.sourceUrl as the direct file/archive URL, source.sourcePageUrl as the product page, the license prerequisite, and the .xmt_txt/.xmt_bin text-vs-binary distinction. The confidence enum values and sourceKind enum remain unexplained.

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 pair (download and import) plus the exact resource (HTTPS Parasolid file or ZIP with one compatible member) and the resulting geometry type (exact native B-Rep). The 'explicitly selected ... from a public hostname' framing clearly separates it from the local-file sibling plasticity_import_parasolid.

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 concrete preconditions ('Select the source page and license first') and routes follow-up work to plasticity_body_info for exact B-Rep detail. It does not explicitly contrast itself with plasticity_import_parasolid/plasticity_import_step for already-local files, so the alternative-selection guidance is implied rather than stated.

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