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

Annotations already cover the read-only/idempotent/non-destructive profile, yet the description adds hard-to-guess traits: a rate limit of 32 calls/day, the auth precondition (registered account key, no credits spent), and the critical output caveat that files contain raw EJS markers and are not build-ready. That is exactly the context annotations cannot supply.

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?

Front-loads the core purpose, then cost/limits, then the build-readiness caveat as the emphasized closing point. Slightly long and mildly repetitive (the EJS warning and the 'do not copy' warning say related things), but every element is actionable and nothing is padding.

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 read tool with full schema coverage and sibling alternatives, nothing needed to call it correctly is missing: cost, limits, auth, output nature, and correct follow-up tools are all stated.

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% and the single parameter already includes an id@version example, so the schema does the work. The description adds no syntax or format detail beyond it; 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?

States a specific verb (returns) and resource (exact, unrendered source files for one catalog component) and immediately scopes it against the purchased scaffold equivalent. An agent can distinguish this from get_scaffold, purchase_scaffold, and generate_scaffold 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?

Gives explicit when-to-use ('inspect or compare a component before buying a scaffold') and explicit when-not with named alternatives ('Use purchase_scaffold or generate_scaffold for rendered, build-ready files', 'Do not copy get_component output directly into a project'). The routing decision is fully determined.

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