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

With no annotations, the description carries the full behavioral burden and does so well: it discloses non-custodial operation, the embedded fee, the Guard safety check, the unsigned return value, and that the agent performs signing/sending. It stops short of explaining failure modes or guard rejection behavior, so it is not perfect.

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 description is two tight sentences, front-loads the most important distinction (non-custodial, unsigned), and every clause adds unique value: fee, guard, custody, and signing responsibility. There is no filler.

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?

Despite the absence of an output schema, the description tells the agent what the tool returns (unsigned transaction) and who signs. It also conveys the fee and guard behavior. It is reasonably complete, though it could clarify what happens if the Guard check fails or how fees are deducted from the swap.

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 50%: amount and user_pubkey are documented, but input_mint and output_mint are bare strings. The description does not compensate by explaining mint address format or how the Guard check affects the output_mint parameter. Parameters are mostly left to inference.

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 states a specific verb ('Build'), a precise resource ('NON-CUSTODIAL Solana swap transaction via Jupiter'), and distinguishing details (embedded 0.20% fee, Guard safety check, unsigned transaction). This clearly separates it from the sibling check/verify/guard tools.

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 implies when to use the tool by emphasizing that the agent signs and sends with its own wallet and that keys/funds are never held. However, it does not explicitly mention when not to use it or directly compare it with any alternative tool.

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