fec-mcp-server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct FEC data type or search entity: committee finances vs. compliance flags vs. specific schedules (disbursements, receipts, independent expenditures) vs. searches (candidates, donors, spending). No ambiguity.
Naming Consistency5/5
All tools follow a consistent 'verb_noun' pattern with lowercase underscore separation: get_*, search_*. No mixing of conventions.
Tool Count5/5
8 tools is a well-scoped count for campaign finance research. Covers committee summary, key schedules, and targeted searches without being overwhelming or too thin.
Completeness4/5
Covers core CRUD-like operations (retrieve summaries, itemized receipts/disbursements, independent expenditures, compliance flags) and search. Minor gap: no dedicated tool for committee details beyond finances, but searches provide identifiers. Solid for the domain.
Average 3.8/5 across 8 of 8 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on March 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only implies a read operation via the word 'search' and notes that it operates 'across all committees'. It does not disclose potential rate limits, pagination, data freshness, or whether it requires authentication. This is minimal for a tool with no other behavioral hints.
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?
The description is extremely concise: two sentences and a line, front-loading the core purpose and specific search examples. Every sentence adds value, and there is no redundant or vague language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 6 parameters and no output schema, the description does not mention the return format or structure (e.g., list of disbursements). It also lacks information on default behavior, such as ordering or result limit details beyond what the 'limit' parameter specifies. This leaves the agent uncertain about what to expect from the response.
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?
The input schema covers all 6 parameters with descriptions (100% coverage). The description adds value by providing concrete examples for the 'description' parameter (e.g., 'dinner', 'travel', 'Disney') but does not add meaning beyond the schema for other parameters. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches campaign spending by description or recipient across all committees, with specific examples like 'steak dinner' and 'Disney'. However, it does not explicitly differentiate from the sibling tool 'get_disbursements', which also searches disbursements, missing an opportunity to clarify distinct use cases.
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 provides clear usage context by listing example searches (e.g., 'event tickets', 'golf') and states its purpose for identifying spending patterns. However, it does not mention when to use this tool versus alternatives like 'get_disbursements' or 'get_committee_finances', nor does it specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only describes the search scope ('across all FEC filings') but does not disclose behavioral traits such as pagination, rate limits, authentication needs, or what happens with no results. The behavioral context is minimal.
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?
The description is three sentences: first states the action, second lists use cases, third provides examples. It is front-loaded and concise, with no superfluous information. Every sentence contributes to understanding.
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?
Given the tool has 7 optional parameters and no output schema or annotations, the description adequately explains what the tool does and gives examples. However, it lacks discussion of result format, error handling, or how parameters combine, leaving some gaps for an agent.
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 each parameter is already documented. The description adds marginal value with examples (employer: 'Goldman Sachs', occupation: 'Lobbyist'), which clarifies usage but does not significantly deepen understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search for individual donors' and specifies the resource as 'all FEC filings' with search dimensions name, employer, or occupation. It distinguishes from sibling tools by focusing on donors, but does not explicitly differentiate from other search tools like search_candidates.
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 provides use cases like 'tracking donor patterns' and examples of searching by employer or occupation, implying when to use. However, it lacks explicit when-not-to-use guidance or references to alternative tools for other purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It correctly portrays the tool as read-only ('Retrieve'), but omits any mention of authentication, rate limits, or whether any state changes occur. While 'Retrieve' is suggestive, an explicit safety statement would improve transparency.
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?
The description consists of two short sentences, each serving a clear purpose: first to state the action and resource, second to explain utility. It is front-loaded and free of unnecessary words.
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?
With 9 parameters and no output schema, the description provides a high-level overview but does not detail the response structure or pagination. An agent might need to infer the output format. The description is adequate but not fully comprehensive.
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 coverage is 100%, fulfilling the baseline. The description adds only generic value ('filtering by amount') beyond what the schema's parameter descriptions already convey. No additional parameter-specific context is provided.
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 uses a specific verb ('Retrieve') and resource ('itemized expenditures (Schedule B)'), clearly distinguishing from sibling tools like get_receipts or get_independent_expenditures. It also lists the key data fields (recipients, amounts, purposes), leaving no ambiguity about the tool's function.
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 mentions 'researching significant spending patterns and campaign finance transparency' as a use case, but does not provide explicit guidance on when to avoid this tool or compare it with alternatives like get_committee_finances or get_independent_expenditures. The usage context is implied, not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It notes the auto-classification of PAC contributions and filtering, but does not state that it is read-only, describe pagination, or mention any rate limits. Adequate but lacks full transparency.
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?
Three sentences, each adding value. The most important information (action and resource) comes first. No extraneous content, though structure could be slightly improved with bullet points.
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?
The description mentions output includes donors, amounts, and details, but lacks specifics on return structure or pagination. Given 9 parameters and no output schema, more detail on the response format would enhance completeness.
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 baseline is 3. The description adds value by explaining auto-classification of PAC types (related to contributor_type) and the 'notable analysis block' (include_notable), providing context beyond parameter descriptions.
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?
Clearly states it retrieves itemized contributions (Schedule A) for a campaign committee, distinguishing it from sibling tools like get_disbursements or get_independent_expenditures. The verb 'Retrieve' and the specific reference to contributions make the purpose unambiguous.
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 the tool is for contributions received, but does not explicitly state when to use it versus alternatives. Given sibling tools exist, explicit guidance on when to use this tool (e.g., for receipts, not disbursements) would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explains the nature of the data (outside money, no coordination) but does not disclose behavioral traits like read-only nature, rate limits, pagination, or response format. Some transparency is gained through the context, but it is incomplete.
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 sentences, each earning its place: first defines purpose, second adds importance, third lists key filters. No wasted words, front-loaded with the action.
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 tool with 6 parameters (all documented), no output schema, and no annotations, the description adequately explains the use case and filters. However, it omits any description of the output format (e.g., what fields are returned), which is a gap given the absence of an output schema.
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 coverage is 100%, so baseline is 3. The description mentions 'candidate targeted' (candidate_id), 'committee spending' (committee_id), and 'support/oppose indicator' (support_oppose), adding minimal context beyond the schema. It does not cover min_amount or cycle, but these are well-documented 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 clearly states the verb 'retrieve' and the resource 'independent expenditures (Schedule E)', explaining that they are money spent by PACs and Super PACs to support or oppose candidates. This distinguishes it from sibling tools like 'get_committee_finances' or 'get_receipts'.
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?
The description says 'Critical for understanding outside money influence in elections' and lists filters like candidate targeted and support/oppose indicator, implying when to use the tool. However, it does not explicitly state when not to use it or compare it to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description indicates a read-only check for specific flag types, but does not detail side effects, auth requirements, or rate limits. Adequate but not exhaustive.
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?
Two concise sentences, front-loaded with action and purpose, no superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with two parameters and no output schema; description covers purpose, output type, and rationale. Lacks mention of return format or pagination, but sufficient for a straightforward check.
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?
Input schema has 100% coverage with clear descriptions for both parameters. Description adds no semantic value beyond what schema provides, meeting baseline.
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?
Description explicitly states it checks a campaign committee for compliance red flags (RFAIs, amended filings). Clearly distinguishes from sibling tools that focus on financial data.
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?
States it is essential for identifying compliance issues meriting closer review, implying use when investigating compliance. While it doesn't explicitly exclude scenarios, the context is clear given sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It correctly implies a read-only operation via 'search' and 'returns,' but does not explicitly state that no data is modified or mention rate limits, authentication needs, or any side effects.
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 short, front-loaded sentences convey the purpose, output, and use case with no redundancy or unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's actions and output (identifiers and committee IDs) and provides a use case. It lacks information about pagination, result limits, or error handling, but the schema and multiple parameters make it fairly complete for a search tool.
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?
With 100% schema coverage, each parameter already has a clear description (e.g., q as candidate name, election_year with range). The tool description adds no additional parameter-level detail beyond the schema, meeting the baseline expectation.
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 action 'Search FEC records for candidates by name' and explains what it returns (candidate identifiers and committee IDs). It distinguishes from sibling tools like get_committee_finances or search_donors by focusing on candidates.
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?
The description notes that the returned IDs are 'required for retrieving detailed financial information,' implying this tool should be used before committee finance lookups. However, it does not explicitly state when to avoid using it or provide direct comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details the returned metrics (receipts, disbursements, cash, debts, loans, burn rate) and mentions Schedule C/D inclusion. Does not disclose potential limitations like data freshness or rate limits, but is thorough for a read tool.
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 sentences with no waste. The main action is first, followed by contents, then use case. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description explains return values clearly. Covers the main aspects of the financial summary, but missing details on error handling or pagination, which may be acceptable for this tool.
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 covers 100% of parameters with descriptions. The description adds no extra meaning beyond the schema; it restates the default for cycle which is already 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?
Clearly states it retrieves a comprehensive financial summary for a campaign committee from official FEC filings. Specific verb, resource, and scope distinguish it from more specific sibling tools like get_disbursements and get_receipts.
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?
States it is essential for understanding campaign financial health and transparency research, implying the appropriate use case. However, it does not explicitly exclude when to use sibling tools for detailed breakdowns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![fec-mcp-server MCP server](https://glama.ai/mcp/servers/sh-patterson/fec-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/sh-patterson/fec-mcp-server)

Score Badge

Copy to your README.md:

[![fec-mcp-server MCP server](https://glama.ai/mcp/servers/sh-patterson/fec-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/sh-patterson/fec-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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