Api metrology metric instances destroy

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds no behavioral context whatsoever — not what cascades on deletion (e.g. associated metric samples), whether the deletion is soft or hard, or what permissions are required — so it neither contradicts nor enriches the annotations.

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 text is minimal in length but not concise in any useful sense — it is under-specification rather than economy of words, since a single repeated identifier sentence conveys no information an agent does not already have.

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 destructive, non-read-only operation with one undocumented parameter and no output schema, the description should cover target identification and deletion consequences. It covers none of these, leaving the definition essentially empty of guidance.

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 single required parameter 'id' has 0% schema description coverage, and the description does not clarify whether it expects a metric instance ID or the parent metric definition ID. With the description silent, an agent could easily pass the wrong identifier type.

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 is the tool's snake_case name verbatim, so it only restates the identifier rather than explaining what it does. An agent can infer 'destroy a metrology metric instance' from the name alone, but the description contributes nothing beyond it and does not distinguish it from sibling destroy 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?

There is no when-to-use guidance, no preconditions, and no pointer to alternatives such as metric_instances_object_retrieve (to verify the target) or partial_update. The agent must infer all usage context from the name suffix.

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