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

Annotations already carry idempotentHint=true, destructiveHint=true, and readOnlyHint=false, yet the description contributes far beyond them: sender pays ATA rent (~2039280 lamports), the 890880-lamport rent-exempt minimum, ~5000-lamport fees per tx, CreateIdempotent for new ATAs, the 20 SOL/10 SPL pack limits, and 201-vs-202 semantics with same-idempotencyKey retry. It even decrypts a common error (400 on SPL = missing SOL, not missing USDC). No contradiction with annotations; the behavior described matches the idempotent/destructive hints.

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?

The most load-bearing content is front-loaded in the first sentence, and the description remains dense rather than padded — the chain split, fee tables, and error interpretations are genuinely needed for safe invocation. It is long, but for a two-chain payment tool with ATA mechanics, the length is justified. A few small repetitions ('below that the tx fails', the zero-address warning already in the schema, re-stating decimal rules) keep it from a 5.

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?

Given the tool's high complexity (EVM + Solana, native + ERC-20 + SPL, ATA rent, social lookups, idempotency), the description is nearly complete and covers prerequisites, per-chain behavior, fee schedules, failure diagnostics, and response codes. The only conceivable gap is the response body shape, but 201/202 illustrated and no output schema exists to document it, so the description carries the needed outcome semantics.

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 83% schema description coverage the schema already carries decimal rules, smallest-unit expectations, the zero-address prohibition, and the recipients/social-detail. The description's incremental value appears in the per-parameter par score: the 20 SOL / 10 SPL recipients-per-tx cap is absent from the schema's recipients description, the native-token null behavior is emphasized, and amountInWei rules tie amountInWei — there is no schema description for idempotencyKey, and the description connects it to retry semantics. It adds value, but part of it duplicates the schema, so 4 rather than 5.

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 opening sentence, "Execute a Smart Send from the API key owner Connect embedded wallet," states a specific verb, resource, and actor that clearly identifies this as the disbursement/transfer tool. The chain and token-type scoping further distinguishes it from siblings like connect_drop_balance and connect_lookup. An agent can tell exactly what this tool does without inspecting 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?

The description explicitly instructs "Always call connect_drop_balance first," directly routing the agent to the prerequisite sibling tool. It then gives concrete decision rules: native vs tokenContract guidance on when to omit/use the contract, social recipients always pay solWalletAddress, and specific failure meanings (400 on SPL often means missing SOL for rent). This is explicit when/when-not guidance rather than implied context.

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