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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds context beyond annotations by disclosing the result contents and the two query modes (by candidate or by spender committee). It does not mention pagination behavior or what happens when neither ID is supplied, but these are minor for a read-only list tool with a limit parameter in the schema.

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 tight sentences with zero filler: purpose first, then return contents, then the critical input requirement. Every sentence earns its place, and the most important operational instruction is kept to a short imperative. Efficiently sized for a 4-parameter read-only tool.

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 list tool with read-only annotations and no output schema, the description covers the essentials: what is listed, what fields are shown, and which identifiers are needed. The main gap is not specifying behavior when neither candidate_id nor committee_id is provided (both are optional in the schema), plus no mention of the cycle dimension's effect on results. Otherwise nothing critical is missing.

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 the baseline is 3 — the schema already documents all four parameters. The description's 'Provide candidate_id or committee_id' reinforces the mutual-exclusivity relationship already stated in the schema property descriptions, adding emphasis but no genuinely new semantic information beyond what the structured data provides.

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 uses a specific verb ('List') with a precise resource ('independent expenditures (FEC Schedule E)') and enumerates the returned fields (spender committee, amount, date, support/oppose, description). It clearly distinguishes this tool from sibling FEC tools like fec_candidate_financials or fec_committee_search by focusing on expenditures rather than profiles or totals.

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?

The description provides a clear precondition — 'Provide candidate_id or committee_id' — which tells the agent the tool requires a known identifier. However, it gives no explicit when-to-use versus when-not-to-use guidance relative to sibling FEC tools (e.g., when to prefer fec_candidate_financials instead), and no exclusion criteria. The usage context is implied rather than explicitly contrasted with alternatives.

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