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

Annotations only declare readOnlyHint/openWorldHint, so the description carries most of the behavioral load and does so well: it discloses chain/encoding per platform (Solana v0 messages, Base EIP-1559), required environment secrets, the fee split (60/15/25, 5% referrer) and the treasuryBps 2000–3000 constraint. It does not say what the returned unsigned transaction looks like or that it must be signed and submitted via a sibling, which is the main remaining behavioral gap.

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-loaded with the verb and the word that matters most (UNSIGNED), then telegraphed platform facts, crew guidance, and the fee map — dense but every clause carries information. No filler or restatement of the title. Slightly list-like, which is appropriate for a 19-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 high-complexity, multi-chain, 19-parameter mutating-shape tool with no output schema and 21% schema coverage, the description covers the highest-risk areas (venue requirements, crew sourcing, fee economics) but leaves many parameters and the transaction-consumption workflow unexplained. It is adequate to attempt a call, not complete enough to prevent parameter misuse.

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 only 21% across 19 parameters, so the description must compensate, and it only partially does: it explains platform defaults, optInOnly's default, treasuryBps's effective range, and the crew[] source preference. Roughly a dozen parameters (mode, seats, initialBuySol, mintPubkey, description, imageBase64, social fields) get no semantic clarification beyond their names and constraints.

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 first sentence gives a specific verb+resource ('Create UNSIGNED launch transactions'), and 'UNSIGNED' cleanly separates it from the signed/submitting siblings (crew_submit_signed, crew_launch). It also names siblings it interacts with (crew_list_kols, Autohire) rather than leaving the crew-selection path implicit. It stops short of explicitly stating the build-then-sign-then-submit workflow, so a 5 isn't earned.

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?

Strong conditional guidance: platform-specific prerequisites (BAGS_API_KEY for bags, ZORA_ENABLED for zora), default venue (pumpfun), and an explicit preference order ('Prefer explicit crew[] from crew_list_kols; Autohire is fallback'). What is missing is any guidance on when to call this instead of the sibling crew_launch or crew_launch_dry_run. Nothing is misleading, but the when-not case is absent.

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