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

With only readOnlyHint=false and destructiveHint=false from annotations, the description carries real weight and delivers: payments are final with no refunds, cancellation is by email to admin@rokha.ai, USDC orders expire in 48 hours unpaid and self-confirm, SOL quotes hold only 60 seconds, and an exact amount must be sent. Minor gap: it never says what happens if the wrong amount is sent or whether a failed/unpaid order leaves any lingering state.

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?

Every clause carries information, but it is a single dense run-on paragraph stitched with semicolons and parentheses, and it opens on the auth prerequisite rather than the tool's purpose. The pricing/rail/timing facts are hard to scan for an agent deciding between rails.

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 payment-initiating tool the description covers auth, price, per-rail mechanics, expiry windows, finality, cancellation path, and cheaper alternatives; return values are covered by the existing output schema, so nothing essential is left dangling.

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 already 100%, yet the description adds per-rail behavior the schema cannot: 'usdc' + payer_wallet returns exact pay instructions that self-confirm within 48 hours, 'sol' + payer_wallet quotes in exact base units valid 60 seconds, 'card' returns a Stripe Checkout link. Slight gap: the 'rokha' enum value is never described in the text, only in 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 action and resource: 'Starts the Lab month — $29.99 a month, full access to everything: the runtime, the Lab, 300 runs a day.' It also scopes it ('for YOURSELF; it never names another account'), which separates it from account-level siblings like page_me or subscription_status.

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?

Explicitly routes the agent: use this to start a paid month, check subscription_status afterwards, and if cost is a concern use the free tier or a run pack via product_checkout instead. Prerequisite auth path (JWT or rk_ key via auth_wallet_challenge → auth_wallet_verify) is spelled out.

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