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

Annotations already flag destructiveHint=true, but the description adds the crucial qualifier that the private copy survives, so 'destructive' applies only to the community listing — that genuinely refines the safety picture beyond structured fields. It still omits auth/skill requirements and whether the public listing's history or mentions are lost.

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 the key retention guarantee in second position — efficient. The unexplained 'Free:' prefix costs a little clarity without contributing meaning.

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 one-parameter mutation with an output schema available, this covers the essentials of what the call does and what survives. It leaves open whether the removal is reversible, what permissions are needed, and what the response reports — gaps that matter for an irreversible-looking destructive action.

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 coverage is 100% with featureId documented as 'fm_… community feature id', so the description adds nothing new about the single parameter beyond confirming the 'community library' context. Baseline 3 is appropriate when the schema fully documents the input.

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+resource pair: remove a feature from the community library. The clause 'while keeping it in your private memory' distinguishes it from the nearby delete_feature and complements publish_feature_pattern, so an agent can tell what it does. It never names those siblings explicitly, and the leading 'Free:' token is unexplained noise.

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 purpose implies when to use it (you want the item out of the public library but retained locally), and the alternative — full deletion — is hinted at rather than named. There is no explicit 'use X instead when…' routing, no prerequisites, and no statement about whether the action can be undone by republishing.

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