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

Annotations already indicate read-only and idempotent behavior, and the description adds valuable non-obvious details: the paid feature/subscription gate and the email privacy rule ('Emails appear ONLY for creators you have revealed'). These are behaviorally significant and not inferable from the annotations. No contradiction exists.

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?

Three sentences, each carrying distinct information: output format and filter equivalence, subscription gating, and email redaction. It is front-loaded with the core purpose and avoids filler.

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 an export tool with no required parameters and a high-coverage schema, the description covers the important non-schema aspects: subscription requirement and data visibility restrictions. The main gap is that it does not describe how the CSV is delivered (e.g., file download vs URL), and there is no output schema to fill that in, but this is not critical for selecting and invoking the tool.

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 86%, so individual parameters are already documented. The description's main added semantic is 'same filters as list_creators', which helps conceptually but does not explain any individual parameter. It clarifies that 'has_contact' values are hidden until revealed, but that is behavioral rather than semantic detail. Baseline 3 is appropriate.

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 states the deliverable clearly: 'CSV of your creator list', which distinguishes it from list_creators by output format. It also references the sibling list_creators to clarify that the same filtering applies caeteris. The operation is slightly implicit, relying on the title for the 'Export' verb, but the purpose 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?

The description says 'same filters as list_creators', connecting it to a known sibling and making the output format the key differentiating factor. It also provides important selection context: 'requires an active subscription, same gate as the dashboard export'. It lacks an explicit 'when not to use' statement, but the context is clear enough.

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