Skip to main content
Glama

KeyVex

get_fec_contributions

Read-only

Returns FEC Schedule A contribution data — money flowing INTO federal committees — in AGGREGATED form. Individual donors are never exposed as searchable per-record rows: the FEC sale-or-use rule (11 CFR 104.15) permits aggregated presentation only, so this tool serves group totals and a bounded ORGANISATION leaderboard (the same posture as Quiver Quantitative's public pages). Source: api.open.fec.gov (official FEC API), queried live per request with a cached-rollup fallback (responses carry source: live | cache). THREE MODES (pick one): 1. Aggregate totals — pass group_by: - group_by='employer' + recipient_committee_id + cycle → total + count per employer for that committee (FEC-computed, all itemized rows). E.g. which employers' workforces fund committee X. - group_by='state' + recipient_committee_id + cycle → geographic fundraising pattern for a committee. ⚠ On employer and state rows, contribution_count is the number of CONTRIBUTIONS, not contributors — the FEC publishes no contributor count for these aggregates. A cell can carry a dozen contributions from ONE person (measured: an employer cell with 14 contributions and a single contributor). Do not read it as a crowd, and do not use it to judge whether a cell describes a population or an individual. - group_by='candidate' + cycle (optionally candidate_id) → per- candidate cycle receipts, itemized-individual share, disbursements, cash on hand. Sorted by receipts DESC — 'who raised the most'. - group_by='committee' + recipient_committee_id (cycle optional) → that committee's cycle totals. Top-committee LISTS come from the rollup cache and may lag a day. - group_by='cycle' + candidate_id or recipient_committee_id → per-cycle rows across cycles (fundraising trajectory). 2. Donor leaderboard — pass leaderboard=true + cycle + EXACTLY ONE scope: recipient_committee_id | candidate_id | contributor_state | contributor_employer. Returns top ORGANISATION donors (PAC / party / committee / company) as name + summed total + contribution count, PLUS the individual side as STATISTICS ONLY: individual_donor_count and individual_total. NO median and NO maximum are served — each is one person's number (a median over an odd count IS one contributor's gift) and re-identifies against the FEC's own site. ⚠ SMALL-CELL FLOOR: when fewer than 5 distinct individuals contributed in the scope, the whole individual block is WITHHELD — count and total both null, suppressed=true, and the envelope carries suppressed_small_cells. Three donors plus a total is three people's gifts nearly reconstructed, and the scope is public. The organisation board is never floored; entities are not natural persons. NO NATURAL PERSON IS NAMED BY THIS TOOL, IN ANY MODE. A paid service ranking named individuals by their contribution history is a prohibited commercial use of contributor lists (11 CFR 104.15; 52 U.S.C. 30111(a)(4)). An empty organisation list means no organisation gave in that scope above the floor — it is never a reason to look for people. No addresses, no city/ZIP, no per-record rows. The response's leaderboard.complete flag is true when every itemized row at or above the fixed $1,000 floor (min_amount is not accepted in this mode) for the scope was aggregated — totals are then exact; otherwise the pull hit its page cap and ranks are amount-weighted approximations. 3. Per-record (NON-INDIVIDUAL only) — pass entity_type (COM, CCM, PAC, PTY, ORG) with optional recipient_committee_id / candidate_id / contributor_state / cycle / amount / date filters, or sub_id for a direct lookup. Individual (IND) rows are never returned per-record; memo subtotals are excluded by default (exclude_memos=false to include). Useful for PAC-to-PAC transfer analysis. There is NO contributor_name search and no individual street/city/ZIP anywhere in this tool's output — by design, permanently. Killer query patterns: - Who raised the most this cycle? group_by='candidate' + cycle=2026. - Who funds Senator X? get_fec_candidate_profile → principal committee → leaderboard=true + recipient_committee_id + cycle. - Which employers' staff fund committee Y? group_by='employer' + recipient_committee_id + cycle. - Where does committee Y's money come from? group_by='state' + recipient_committee_id + cycle. - PAC-to-PAC flows into committee Z? entity_type='PAC' + recipient_committee_id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cycleNoElection cycle year (2-year transaction period, e.g. 2026). Required for leaderboard and group_by='employer'/'state'; defaults to the current cycle for group_by='candidate'.
limitNoMax rows (aggregate/per-record) or max ORGANISATIONS (leaderboard, default 100). Default 50, max 500.
sinceNoPer-record mode: inclusive lower bound on contribution_receipt_date (YYYY-MM-DD).
untilNoPer-record mode: inclusive upper bound on contribution_receipt_date (YYYY-MM-DD).
sub_idNoPer-record mode: direct doc lookup by FEC sub_id. Returns the row only when it is a non-individual contribution.
sort_byNoPer-record mode sort key. Default: contribution_receipt_date.
group_byNoAggregate mode: group totals by this axis. employer/state require recipient_committee_id + cycle (the FEC computes those per committee). cycle requires candidate_id or recipient_committee_id.
max_amountNoPer-record mode: inclusive upper bound on amount.
min_amountNoLeaderboard: itemization floor for aggregated rows (default 1000; 200 = FEC itemization floor). Per-record: inclusive lower bound on amount.
sort_orderNoPer-record mode: default desc.
entity_typeNoPer-record mode selector — NON-INDIVIDUAL types only: COM (committee), CCM (candidate committee), PAC, PTY (party), ORG (organization). IND, UNK and CAN are not accepted: a CAN row is the FEC's code for a CANDIDATE, who is a natural person, so candidate contributions are served aggregated only alongside every other individual.
leaderboardNoLeaderboard mode: top ORGANISATION donors (PAC / party / committee / company) by name + summed total + count for ONE bounded scope, PLUS the individual side as statistics only (count and total — NO median and NO maximum; each is one person's number and re-identifies against the FEC's own site). Those statistics are WITHHELD ENTIRELY when fewer than 5 distinct individuals contributed in the scope. NO NATURAL PERSON IS NAMED — ranking named individuals by their giving is a prohibited commercial use of contributor lists (11 CFR 104.15). Requires cycle + exactly one of recipient_committee_id | candidate_id | contributor_state | contributor_employer.
candidate_idNoFEC candidate ID (e.g. 'S8GA00180'). Scope for group_by='candidate'/'cycle', leaderboard scope, or per-record filter.
exclude_memosNoPer-record mode: when true (DEFAULT) filters out memoed_subtotal rows (FEC duplicates that double-count dollars). Leaderboards always exclude them.
contributor_stateNo2-letter state code. Leaderboard scope (top donors from a state) or per-record filter (non-individual rows).
contributor_employerNoEmployer name (FEC substring match). LEADERBOARD SCOPE ONLY — top donors reporting this employer. Not available as a per-record filter.
recipient_committee_idNoFEC committee ID (e.g. 'C00401224'). Scope for group_by='employer'/'state'/'committee'/'cycle', leaderboard scope, or per-record filter. Use get_fec_candidate_profile to find a candidate's principal committee.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Far exceeds the annotation baseline (readOnly/openWorld only). It discloses a cached-rollup fallback with a source: live|cache flag, day-lag on rollup lists, the complete flag vs page-cap approximation, the small-cell withholding floor (<5 individuals → suppressed_small_cells), memo-subtotal exclusion defaults, and the $1,000 itemization floor. Consent-vs-cost warnings (contribution_count is contributions, not contributors) go well beyond structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose before any details, and the numbered mode structure with ⚠ callouts and example queries is easy to scan. It is long, and the 'NO NATURAL PERSON IS NAMED' prohibition is restated at least three times across the text, which is padding even for a compliance-sensitive tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 17-parameter, three-mode, no-output-schema tool, the description is complete: it explains mode selection, required combinations, response envelope flags (source, complete, suppressed_small_cells), and what is structurally absent from output (no addresses, no per-record individual rows). An agent needs nothing further to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so the baseline is 3, but the description adds real meaning the schema cannot: which parameters combine into each of the three modes, that contributor_employer is leaderboard-scope-only, and that min_amount is ignored in leaderboard mode. It does not restate every field, which is appropriate when the schema already carries it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb, resource and scope: 'Returns FEC Schedule A contribution data — money flowing INTO federal committees — in AGGREGATED form.' It immediately distinguishes itself from siblings (get_fec_disbursements covers money out, get_fec_candidate_profile is a lookup) and the three-mode structure makes the output shape unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly enumerates three modes with the exact parameters each requires, states what is not accepted (min_amount in leaderboard mode, contributor_employer as a per-record filter), and closes with five 'killer query patterns' that route the agent to the right mode. Alternatives and prerequisites are named, not inferred.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources