Skip to main content
Glama

KeyVex

get_lobbying_filings

Read-only

Returns Lobbying Disclosure Act (LDA) filings — quarterly LD-2 reports filed by registered lobbyist firms with the Senate Office of Public Records. Each record covers one (registrant, client, quarter) tuple, listing income paid, issues lobbied on, and government entities contacted. Use this when the user asks about: who's paying lobbyists, what issues a company is lobbying on, which senators or agencies a firm is contacting, lobbying spend by industry or sector, or to cross lobbying activity against congressional trades or federal contracts for political-influence analysis. Each filing has a lobbying_activities array (one entry per issue area worked on) plus three flattened summary arrays at top level: - general_issue_codes: 3-char codes (DEF, HEA, TRA, ENV, FIN, ...) - government_entities: agencies/branches contacted - lobbyist_names: lobbyists who worked the issue Top-level arrays support indexed queries; the nested array carries issue-level descriptions and lobbyist position info. general_issue_codes filter is OR-semantic — pass an array, match any filing containing AT LEAST ONE of those codes (max 30, per Firestore array-contains-any). Examples: ['DEF'] for defense, ['HEA','MMM'] for health + Medicare/Medicaid, ['TAX','FIN'] for tax + financial services. Income vs expenses (IMPORTANT for ranking by spend): the LDA mandates a hard split. Third-party lobbying firms report income (what the client paid them); in-house corporate lobbying departments report expenses (what they spent). The two fields are mutually exclusive — any given filing has one or the other, not both. In practice ~30% of filings have income, ~70% have expenses, with a small population reporting neither (administrative registrations). So sort_by=income ranks the third-party-firm subset; for an actual top-spenders leaderboard, agents should fetch both populations and sum income + expenses per filing client-side. v1.1 polish will add a derived total_lobbying_spend field that does this sum server-side for indexed queries. client_is_government is true when the client is a government body (US states often hire lobbyists). Activity descriptions are truncated at 5000 chars during ingestion to stay under Firestore's per-doc cap; agents can fetch the full filing via filing_document_url for the unbounded prose.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum records to return. Default 50, max 500.
sinceNoISO date (YYYY-MM-DD). Only records on or after this date, using sort_by as the date field.
untilNoISO date (YYYY-MM-DD). Only records on or before this date.
sort_byNoField used for ordering and for since/until filters. Default: dt_posted (when the filing was submitted).
min_incomeNoFilter to filings with income >= this amount (USD). Use to focus on big-dollar lobbying spend.
sort_orderNoDefault: desc (most recent / largest first).
client_nameNoSubstring match against the paying client's name (case-insensitive). E.g., 'Pfizer', 'Lockheed Martin', 'STATE OF CALIFORNIA'.
filing_yearNoCalendar year of the reporting period (NOT the filing date).
filing_periodNoReporting period within filing_year. Quarters for LD-2; mid_year/year_end for LD-203 contributions windows.
registrant_nameNoSubstring match against the lobbying firm's name (case-insensitive). E.g., 'Akin Gump', 'Brownstein'.
government_entityNoSubstring match against any government entity contacted. E.g., 'SENATE', 'Treasury', 'FDA', 'Defense, Dept of'.
general_issue_codesNoArray of 3-char issue codes (OR semantics). E.g., ['DEF'] for defense, ['HEA','MMM'] for health+Medicare. Max 30 codes per query.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

With annotations covering readOnly, openWorld, and destructive=false, the description adds substantial behavioral context: the income vs expenses split, the ~30%/70% population skew, client_is_government semantics, and the 5000-character truncation with filing_document_url for full prose. It also notes a future derived field, giving agents a clear picture of current limitations and expected data shape.

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 the core purpose and record structure, then moves to use cases and caveats in a logical order. It is long but mostly earns its length given the complex 12-parameter tool with no output schema, though the v1.1 roadmap note and some repetition could be trimmed.

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?

There is no output schema, so the description carries the burden of explaining return values, which it does thoroughly: it describes the lobbying_activities array, three flattened summary arrays, income vs expenses fields, truncation, and the full-document fallback. Combined with the schema and annotations, an agent has enough information to invoke and interpret the tool correctly.

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

Parameters3/5

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 description adds some meaning for general_issue_codes OR semantics and sort_by=income, but those details are largely already present in the schema, and most other parameters are documented only in the schema.

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 description states a specific verb and resource — returns Lobbying Disclosure Act (LDA) filings — and defines the record grain as one (registrant, client, quarter) tuple with income, issues, and entities. It clearly differentiates from related sibling tools like get_lobbyist_contributions by focusing on quarterly LD-2 filings rather than campaign contributions.

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?

It gives explicit usage scenarios: who's paying lobbyists, issues a company is lobbying on, senators/agencies contacted, lobbying spend by industry, and cross-referencing against congressional trades or federal contracts. It does not name alternative tools or state when not to use this tool, so it falls short of the top score.

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