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 discloses the human-gated write mechanics, elicitation requirement, Stripe best-effort minting with checkout backfill, the 6-month expiry cap, 90%+ invite_only pinning, tier restrictions, code uppercasing/uniqueness, and the free-only-app prohibition — excellent transparency. However, it does not state permissions/auth requirements or error conditions beyond refusal, and the return/response shape is left unspecified; against zero annotation coverage these remain meaningful gaps, warranting a 3.

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?

Purpose and the WRITE/human-gated flag are front-loaded, and nearly every sentence adds a distinct rule or precondition rather than filler. It is nonetheless a dense wall of clauses, which slightly hurts scanability for a 10-parameter tool.

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 complex 10-parameter mutation with no annotations and no output schema, the description covers behavior, failure modes, the three enforced house rules, dry-run semantics, and next-step tooling. An agent has everything needed to call it correctly or avoid it.

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?

With 0% schema coverage, the description must compensate, and it does for most inputs: code (uppercased, unique per app), discount_percent (90%+ rules), expires_at (omitting means the 6-month default), dry_run, listed/tier scope mentioned as form fields, and applies_to_tiers defaulting to every paid tier. It omits max_uses, description, and confirm_high_discount, so it is strong but not complete.

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?

Opens with a specific verb+resource+scope: 'Create a percentage discount coupon for an app.' It is immediately distinguishable from bulk_create_coupon, update-style siblings, and the read-only list_coupons without opening any schema.

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?

Explicitly states when the tool works (elicitation-capable client), when it is refused (non-elicitation clients), that dry_run works anywhere, to run dry_run first to preview, that the form values override arguments, and names follow-up tools (list_coupons, list_plans, invite_to_coupon). Routing and preconditions are fully specified.

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