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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the agent knows this mutates state and is not reproducible. The description adds only that it targets a 'built-in' sample and yields a mesh_id; it does not explain what registration creates, whether re-registering duplicates state, or any permission requirements.

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 sentence, front-loaded with the action, that carries no filler. The return value note is appended efficiently rather than 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 the mesh_id return detail is somewhat redundant but harmless. For a non-idempotent mutation with two undocumented, strictly-patterned parameters, the description omits prerequisite and repeat-call behavior, leaving meaningful gaps.

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% for two required parameters (name, workspace_id), both with strict regex patterns that the description never mentions. The word 'sample' loosely hints at the name argument, but the description adds no format, constraint, or meaning for either parameter, leaving the agent without guidance where the schema is silent.

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: 'Register a built-in sample'. It also discloses the return artifact ('return a mesh_id'), which cleanly separates it from the read-only sibling list_samples. It stops short of naming any sibling explicitly, so it does not reach 5.

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?

'for draping' implies the downstream use case, giving the agent a rough sense of when this tool matters. However, there is no statement of prerequisites, no exclusion of alternatives, and no guidance on when to prefer this over list_samples or import_part.

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