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

Annotations already establish read-only, closed-world behavior, and the description adds genuinely useful context beyond them: free assets need no auth, Pro assets need a token on a Pro-enabled account, and entitlement is validated server-side on every call. It does not say what an entitlement failure looks like or whether the returned payload is a single file or a bundle.

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 short sentences with no filler, front-loaded with what the tool returns and followed by the path and auth conditions. The install-path detail sits mid-sentence rather than in its own clause, but nothing is wasted.

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 annotations covering safety and no output schema, the definition covers the essentials: what comes back, where it installs, and what auth is required. The remaining gap is the shape of the returned files, which the absent output schema leaves undisclosed.

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 description coverage is 0% for the single required parameter, so the description must carry the burden. It only implies that slug identifies an "asset" and says nothing about format, allowed characters, or whether the slug comes from search_components results, leaving the schema's maxLength 120 as the only constraint.

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 and resource ("Returns the source files for an asset") and adds a concrete destination ("written under components/sundae/"), so the agent knows this is the source-fetching tool rather than the metadata one. It never names sibling tools like get_component or get_install_instructions, so the differentiation is inferred rather than stated.

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?

Usage is implied by the destination path and the entitlement rules, giving the agent enough to know this is the install-source step. However, there is no explicit guidance on when to choose this over get_component or get_install_instructions, and no stated preconditions failure mode beyond the entitlement gate.

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