Skip to main content
Glama

KeyVex

get_fec_independent_expenditures

Read-only

Returns FEC Schedule E independent expenditures — money spent BY a super PAC (or IE-only PAC) uncoordinatedly FOR or AGAINST a federal candidate. Hallmark vehicle for political ad spending since Citizens United (2010). Critical signal: support_oppose_indicator — 'S' = support, 'O' = oppose. A single candidate often has dozens of S and O entries across many super PACs in one cycle. Filter by support_oppose='O' to find attack ads; 'S' to find positive ads. Source: api.open.fec.gov/v1/schedules/schedule_e/. F24 filings (24-hour notices within 20 days of an election) and F5 (quarterly IE reports) both flow through this endpoint. Filers FEC classes as "a person or a group" (Form 5 filers, committee types I and E) are served when the filer is a group; a filer whose name is, or may be, a natural person's is withheld per record, as is any filer KeyVex holds no committee record for (FEC sale-or-use rule, 11 CFR 104.15). Killer query patterns: - Attack ads on Senator X: candidate_id='S6PA00091' + support_oppose='O' - Recent spend across a cycle: support_oppose='O' + since='2025-01-01' - Top political ad vendors: payee_name='AXIOM' (substring) - Negative spend in a race: candidate_office_state='PA' + support_oppose='O' Filter combinations note: server-side indexes support one equality filter (candidate_id / committee_id / support_oppose / candidate_office_state) + a date / amount sort. Other filters (payee_name, description, exclude_memos) are applied client-side. NOTE on cycle: the FEC leaves two_year_transaction_period null on many rows, so the cycle filter is INCOMPLETE (it undercounts) and is not currently indexed — scope a cycle by DATE instead, e.g. since='2025-01-01' for the 2026 cycle.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cycleNoElection cycle (2-year transaction period), e.g. 2026/2024/2022. INCOMPLETE — the FEC leaves this field (two_year_transaction_period) null on many rows, so filtering by cycle undercounts, and the cycle index is not provisioned (a cycle query currently returns INDEX_MISSING). For complete cycle coverage, scope by DATE instead: since='<cycle start>' (e.g. since='2025-01-01' for the 2026 cycle).
limitNoMax records. Default 50, max 500.
sinceNoInclusive lower bound on expenditure_date (YYYY-MM-DD).
untilNoInclusive upper bound on expenditure_date (YYYY-MM-DD).
sub_idNoFEC sub_id (globally unique row ID). Direct doc lookup.
sort_byNoSort key. Default: expenditure_date.
max_amountNoInclusive upper bound on expenditure_amount.
min_amountNoInclusive lower bound on expenditure_amount in dollars.
payee_nameNoCase-insensitive substring on the payee_name (ad agency, media buyer, vendor). Client-side filter.
sort_orderNoDefault: desc.
descriptionNoCase-insensitive substring on disbursement_description (free-text purpose of the spend, e.g., 'tv ad', 'mailer', 'digital advertising'). Client-side filter.
candidate_idNoTarget candidate being supported or opposed.
committee_idNoFEC committee that spent the money (typically a super PAC). A filer who is, or may be, a natural person returns no rows — see the description.
exclude_memosNoWhen true (DEFAULT), filters out rows flagged memoed_subtotal=true — FEC's aggregate / receipt-account duplicates that double-count the same dollars across multiple rows. Top-spender queries are misleading without this filter. Pass exclude_memos=false to include the raw memo rows.
support_opposeNo'S' = filter to ads supporting the target; 'O' = filter to ads opposing. Omit for both.
candidate_officeNoOffice of the target candidate: H/S/P.
candidate_office_stateNo2-letter state code of the target candidate (e.g., 'PA', 'TX').

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare a safe read-only profile, but the description adds rich behavior beyond them: privacy withholding for natural-person filers, memo-row double-counting, F24/F5 filing sources, incomplete cycle filtering, and the split between server-side and client-side filters. This is exactly the context an agent needs to avoid misusing the tool.

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?

The description is front-loaded with purpose and the critical support_oppose signal, then organized into source, filter behavior, and query patterns. It is dense and long with FEC legal/background detail, but most of it earns its place for a 17-parameter domain tool; some background could be trimmed without losing meaning.

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?

Given 17 optional parameters, no output schema, and read-only annotations, the description covers source, key behavioral caveats, filter combinations, and practical query recipes. It does not describe return format or pagination, but with no output schema and safety annotations present, that omission is minor.

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; the description still adds meaning by explaining server-side indexing limits for equality filters and that other filters are applied client-side. Many simple parameters (limit, sort_by, sort_order, amount bounds) are left entirely to the schema, keeping this from a 5.

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?

States a specific verb and resource (returns FEC Schedule E independent expenditures) and precisely defines the domain: money spent by super PACs uncoordinatedly for or against candidates. This distinguishes it from sibling FEC tools like contributions and disbursements without requiring schema inspection.

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

Usage Guidelines4/5

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

Provides extensive usage context through 'killer query patterns' and filter-combination notes, including when to use support_oppose='O' for attack ads and how to scope cycles by date. However, it does not name alternative sibling tools as explicit substitutes or state clear exclusions, so it stops short of the highest bar.

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