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

Annotations are sparse in the ways that matter (readOnlyHint=false, idempotentHint=false, destructiveHint=false), and the description carries the rest: side effects on upstream state (creates the account, adds the trustline, claims USDC, delivers XLM), retry/supersede semantics across calls, the 5-minute expiry, and the security posture ('This server never sees your key', 'do not echo fundingId into logs'). It never contradicts the declared 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 opening sentence is well front-loaded, but the remainder is a single dense paragraph of roughly 300 words mixing operation allowlists, fee arithmetic, cryptographic verification steps, and logging policy. Nearly all of it is relevant, yet the absence of structure makes the critical 'allowed operations / refuse otherwise' rule hard to extract on a fast read.

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?

No output schema exists, and the description compensates fully by enumerating the returned fields (signingRequestId, unsigned XDR, networkPassphrase, operations list, expiresAt) and pointing to Horizon for claimable-balance amounts. Failure modes and the follow-up call are covered, so an agent has everything needed to call it correctly.

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% for both parameters (fundingId, walletAddress), so the schema already documents them. The description only lightly touches fundingId in a logging instruction and never expands on the walletAddress format beyond the schema's 'G...' note. Baseline 3 applies when the schema does the heavy lifting.

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?

Specific verb+resource ('build the one transaction the receiving address must sign') plus the exact trigger condition ('When an order shows sign_stellar_onboarding') and the full operation set the transaction contains. It names its downstream sibling (stellar_wallet_submit_signed) and the data source (funding_capabilities rozoAccounts), so an agent can distinguish it from stellar_wallet_create_order or stellar_wallet_order_status 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?

Explicit when-to-use ('when an order shows sign_stellar_onboarding'), explicit sequence (check operations, decode XDR, then call stellar_wallet_submit_signed), explicit refusal criteria ('Any other operation type or source: refuse'), and explicit recovery behavior ('Expired, or submit failed: just call this tool again'). No alternatives or exclusions are left to inference.

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