Skip to main content
Glama
sh-patterson

fec-mcp-server

get_committee_finances

Retrieve campaign committee financial summaries from FEC filings, including receipts, disbursements, cash on hand, debts, loans, and burn rate calculations for transparency research.

Instructions

Retrieve comprehensive financial summary for a campaign committee from official FEC filings. Returns total receipts, disbursements, cash on hand, debts, loans (including candidate loans), and calculates burn rate (spending/income ratio). Includes Schedule C loans and Schedule D debts for complete financial picture. Essential for understanding campaign financial health and transparency research.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
committee_idYesFEC committee ID (e.g., "C00401224")
cycleNoTwo-year election cycle (e.g., 2024). Defaults to most recent.

Implementation Reference

  • The core handler function that executes the financial summary logic for a committee.
    export async function executeGetCommitteeFinances(
      client: FECClient,
      params: {
        committee_id: string;
        cycle?: number;
      }
    ): Promise<GetCommitteeFinancesResult> {
      try {
        // Fetch reports, loans, and debts in parallel
        const [reportsResponse, loansResponse, debtsResponse] = await Promise.all([
          client.getCommitteeReports(params.committee_id, {
            cycle: params.cycle,
          }),
          client.getScheduleC({
            committee_id: params.committee_id,
            two_year_transaction_period: params.cycle,
            limit: 20,
          }),
          client.getScheduleD({
            committee_id: params.committee_id,
            two_year_transaction_period: params.cycle,
            limit: 20,
          }),
        ]);
    
        if (reportsResponse.results.length === 0) {
          throw new NotFoundError('Committee reports', params.committee_id);
        }
    
        // Get the most recent report
        const report = reportsResponse.results[0];
        const baseSummary = transformCommitteeReport(report);
    
        // Transform loans and debts
        const loans = transformLoans(loansResponse.results);
        const debts = transformDebts(debtsResponse.results);
    
        // Calculate loan totals
        const totalLoans = loans.reduce((sum, loan) => sum + loan.amount, 0);
        const candidateLoans = loans
          .filter(loan => loan.is_candidate_loan)
          .reduce((sum, loan) => sum + loan.amount, 0);
    
        // Build enhanced summary
        const enhancedSummary: EnhancedFinancialSummary = {
          ...baseSummary,
          total_loans: totalLoans,
          candidate_loans: candidateLoans,
          loans,
          debts,
        };
    
        const formattedText = formatEnhancedFinancialSummaryText(enhancedSummary);
    
        return {
          content: [{ type: 'text', text: formattedText }],
        };
      } catch (error) {
        return {
          content: [{ type: 'text', text: formatErrorForToolResponse(error) }],
          isError: true,
        };
      }
    }
  • Tool metadata definition and registration object.
    export const GET_COMMITTEE_FINANCES_TOOL = {
      name: 'get_committee_finances',
      description: `Retrieve comprehensive financial summary for a campaign committee from official FEC filings. Returns total receipts, disbursements, cash on hand, debts, loans (including candidate loans), and calculates burn rate (spending/income ratio). Includes Schedule C loans and Schedule D debts for complete financial picture. Essential for understanding campaign financial health and transparency research.`,
      inputSchema: getCommitteeFinancesInputSchema,
    };
  • Input schema and type definition for the get_committee_finances tool.
    export const getCommitteeFinancesInputSchema = {
      committee_id: z
        .string()
        .regex(committeeIdPattern, 'Committee ID must be in format C00000000 (C followed by 8 digits)')
        .describe('FEC committee ID (e.g., "C00401224")'),
    
      cycle: z
        .number()
        .int()
        .min(1980, 'Cycle must be 1980 or later')
        .max(2030, 'Cycle must be 2030 or earlier')
        .optional()
        .describe('Two-year election cycle (e.g., 2024). Defaults to most recent.'),
    };
    
    export type GetCommitteeFinancesInput = {
      committee_id: string;
      cycle?: number;
Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses the tool's scope (includes Schedule C loans and Schedule D debts) and calculations (burn rate), but doesn't mention rate limits, authentication requirements, error conditions, or what happens with invalid inputs. It adequately describes what the tool returns but lacks operational details.

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

Conciseness5/5

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

Three dense, efficient sentences with zero waste. Every phrase adds value: first states purpose and return values, second specifies included data types, third provides usage context. Perfectly front-loaded with the core functionality.

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

Completeness3/5

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

For a read-only tool with no annotations and no output schema, the description adequately covers what data is returned and the tool's purpose. However, it doesn't describe the return format structure, pagination, error responses, or data freshness—gaps that become more significant without structured output documentation.

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 schema already fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema (like explaining why committee_id format matters or cycle selection implications), meeting the baseline for high schema coverage.

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 clearly states the specific action ('retrieve comprehensive financial summary') and resource ('campaign committee from official FEC filings'), distinguishing it from siblings like get_receipts or get_disbursements which focus on specific transaction types rather than the complete financial picture.

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

Usage Guidelines3/5

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

The description implies usage context ('essential for understanding campaign financial health and transparency research') but doesn't explicitly state when to use this tool versus alternatives like get_receipts or get_disbursements. No explicit exclusions or prerequisites are mentioned.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sh-patterson/fec-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server