plasticity_list_curve_endpoints

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

Annotations already establish read-only, non-destructive, closed-world behavior, so the safety profile is covered. The description adds that results are 'revision-bound' and limited to 'open native Wire bodies', which is meaningful extra context, but it doesn't say whether it acts on the current selection or the whole document, nor what an endpoint record contains.

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 tight sentence with the scoping qualifier front-loaded and no filler. It is arguably too terse for a tool with ambiguous selection semantics, but nothing is wasted.

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 no-arg read-only lister with no output schema this is minimally adequate, but it leaves open whether endpoints are returned for the current selection or all open wire bodies, and gives no sense of the returned shape or ordering. A short clause on scope would have closed the gap.

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 tool takes zero parameters and the schema is trivially complete, so the baseline is 4. The description reasonably implies an unfiltered list but has no parameters to clarify.

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 clear verb (List) and a specific resource (exact revision-bound endpoints of open native Wire bodies), which distinguishes it from near-siblings like list_curve_vertices and list_curve_control_points. It does not name an alternative explicitly, but the scope phrase 'open native Wire bodies' is specific enough for an agent to route correctly.

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 or when-not-to-use guidance, no mention of prerequisites, and no reference to the many sibling list_curve_* tools an agent might confuse it with. The agent must infer selection context (current selection vs. all wires) on its own.

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