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

Goes well beyond the annotations by disclosing the exact cost ($0.005/call), the payment rail (USDC on Solana via x402), and the concrete MCP flow — call unpaid, read the PaymentRequired challenge, retry with payment at _meta["x402/payment"] — plus the HTTP fallback endpoint. This is the context an agent needs to avoid a failed first call, and nothing contradicts the annotations (readOnlyHint=false is consistent with a metered, side-effecting payment call).

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?

Dense but front-loaded: source first, then price, then the mechanical payment recipe, then the HTTP equivalent. Every clause is actionable; the raw HTTP URL is the one element of marginal value for an MCP-only agent.

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 2-optional-param retrieval tool with no output schema, the operational side is thoroughly covered, but the description never says what a result looks like, how many bills are returned by default, or what fields each record carries. An agent knows how to pay but not what it will receive.

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 100%, so 'limit' and 'congress' are already documented in the schema. The description adds no meaning about expected values (e.g., congress number range, default limit) beyond what the schema provides, so the baseline 3 applies.

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 resource is stated precisely — 'Congress bills' from Congress.gov — and the sibling prefix (macro_cpi, macro_payrolls, macro_fed_rate) makes the domain unambiguous. It never states the operation, though: an agent cannot tell from the text whether this lists, searches, or fetches a single bill by ID.

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?

There is no guidance on when to choose this over sibling macro_* tools or news/courts tools, and no note on prerequisites beyond payment. The x402 retry instructions describe how to pay, not when the tool is the right selection.

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