delete_feature_by_name

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that the tool returns an ERROR when zero or multiple features match, which is important for a name-based delete. However, it does not mention the destructive/permanent nature of deletion, potential impact on dependent features, or any permission requirements, leaving notable behavioral gaps.

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 description is two sentences with no filler. The primary purpose is front-loaded, followed by a concrete example, and the important error-disambiguation behavior is stated efficiently. Every sentence earns its place.

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 simple deletion tool with four standard identifier parameters and no output schema, the description covers the main invocation concerns: target resource, selection by name, and failure behavior on ambiguous or missing matches. It does not describe success return values or irreversibility, but the core call behavior is sufficiently specified for an agent to use it correctly.

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 input schema already documents all four parameters with 100% coverage, including that 'name' is exact and case-sensitive. The description adds helpful examples and clarifies that 'name' refers to the display name rather than the feature ID, but it does not substantially extend the parameter-level meaning beyond the schema.

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 uses a specific verb ('Delete') with a specific resource ('Part Studio feature') and a precise selection mechanism ('by its display name'). It clearly distinguishes this tool from the sibling delete_feature, which presumably operates by feature ID, by explicitly calling out that no ID lookup is needed.

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?

The description gives clear context for when to use the tool: when the caller has a feature's display name rather than its ID. It implies the alternative (look up the feature ID and use delete_feature) but does not explicitly name it or state exclusions, so it stops short of a 5.

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