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

With no annotations, the description carries the full burden, and it delivers: it returns a one-time access token, the token is required by create_campaign, expires after 1 hour, and is single-use (consumed by create_campaign). It also discloses a refusal path for free sessions. It stops short of describing what happens on an invalid or replayed txSignature, but the core behavioral profile is unusually well covered.

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?

Four tight sentences, each doing distinct work: legacy warning first, then the gating condition, then the return value, then the token's lifetime and single-use rule. No repetition or 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?

No output schema exists, so the description must explain the return, and it does — access token, required by create_campaign, 1-hour expiry, single-use consumption. Combined with the explicit precondition and refusal case, an agent has everything needed to call this 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% and both parameters are already documented inline, so the baseline is 3. The description adds context (the sessionId originates from initialize_session; txSignature is an on-chain USDC payment to the treasury) but no format, constraint, or edge-case detail beyond the schema.

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?

States a specific verb and resource — verifies an on-chain USDC payment to the treasury — and names the artifact produced (a one-time access token). It also positions itself against both the legacy/new paths and the free-session case, so an agent can distinguish it from siblings like verify_campaign_funding or verify_login_signature.

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 precondition: only call when initialize_session returned paymentRequired true, and it refuses free sessions. It also names alternatives for new integrations (create_account + launch_campaign, API key + prepaid balance) and marks this tool as legacy. Nothing about when to use or not use it is left to inference.

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