get_candidate_money

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

Annotations already cover readOnlyHint=true and destructiveHint=false, and the description adds genuinely new behavioral disclosures: the $0.01 cost ('PAID ($0.01)'), the WALLET_PRIVATE_KEY authentication requirement, and fuzzy name matching that aligns with openWorldHint. There is no contradiction with the annotations.

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?

Three sentences, each earning its place: cost plus return fields, input strategy, and auth requirement. The core purpose is front-loaded before calling details, with zero filler text.

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?

With no output schema present, the description enumerates the returned data fields (receipts, spending, cash on hand, debts, individual vs PAC split) and covers cost, auth, and input modes. It is slightly vague on what 'per recent cycle' concretely means (which cycles, how many) and does not describe output structure, but this is adequate for a simple 3-parameter read tool.

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 67% and the office parameter has no schema description, but the description compensates by explaining the input strategy: fuzzy name vs exact candidate_id as alternatives, and office as an optional preference. The fuzzy-matching semantics and the optionality/preference framing of office go beyond what the schema states.

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 resource — campaign finance totals for a US federal candidate — and enumerates the exact data returned (receipts, spending, cash on hand, debts, individual vs PAC split, per recent cycle). The campaign-money domain clearly distinguishes it from siblings like get_trade_filings, get_congress_trades, and lookup_bill without needing to inspect their schemas.

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?

It provides calling context ('Pass a name (fuzzy) or exact candidate_id; optional office preference') and a hard prerequisite (Requires WALLET_PRIVATE_KEY), so an agent knows how to invoke it and that it is paid. However, it names no sibling alternatives and gives no explicit when-to-use or when-not-to-use guidance relative to tools like find_candidate.

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