plasticity_delete_measurement

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

Annotations already flag destructiveHint=true and readOnlyHint=false, so the mutation risk is covered structurally. The description adds genuinely new context not present in annotations: deletion is routed through document Undo/Redo history (i.e., reversible), and only 'current native' measurements qualify. It does not describe failure modes or 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 front-loaded sentence with no filler; the verb and target come first and the Undo/Redo caveat follows. Mildly dense ('current native ... stable measurement ID') but appropriately sized.

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?

This is a destructive mutation with no output schema and 0% schema coverage, and the required 'revision' parameter is never explained anywhere the agent can see. For a delete operation that is explicitly history-tracked, the definition should at least say what revision is and what happens if it is stale.

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 carry the burden. It clarifies that the integer id is a 'stable measurement ID', which is useful, but it says nothing about the required 'revision' parameter (likely a concurrency/version token) or the optional 'intent' string. Two of three parameters remain semantically opaque.

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 (Delete), resource (Plasticity measurement), and scope qualifier (one current native measurement), which distinguishes it from plasticity_list_measurements and the create_*_measurement siblings. It could be sharper about what 'native' means, but the action is unambiguous.

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?

No when-to-use guidance and no mention of alternatives such as plasticity_list_measurements (to find the ID) or plasticity_undo (as an alternative to deletion). The only implicit signal is that only 'current native' measurements can be deleted, which is a scope limit rather than routing advice.

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