MCP OpenFEC Server
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific FEC data types like candidates, committees, contributions, expenditures, filings, and downloads. There is no overlap in functionality—tools like get_candidate, get_committee, and get_filings serve separate resources, and even related tools like get_candidate_contributions and get_candidate_financials focus on different aspects of candidate data.
Naming Consistency5/5All tool names follow a consistent verb_noun pattern using snake_case, starting with 'get_' or 'search_' followed by a specific noun phrase (e.g., get_candidate, search_candidates, get_audit_cases). This uniformity makes the tool set predictable and easy to navigate, with no deviations in naming style.
Tool Count5/5With 12 tools, the server is well-scoped for accessing U.S. Federal Election Commission data, covering key areas like candidates, committees, financials, expenditures, and filings. Each tool serves a distinct data retrieval function, avoiding bloat while providing comprehensive coverage for the domain.
Completeness4/5The tool set offers strong coverage for retrieving FEC data, including candidates, committees, financials, expenditures, filings, and bulk downloads. A minor gap exists in update or management operations (e.g., no create or modify tools), but this is reasonable for a read-only data access server focused on public records, and agents can work effectively with the provided retrieval functions.
Average 2.8/5 across 12 of 12 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under BSD 3-Clause.
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.jsonto 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
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states 'Get' which implies a read operation, but offers no details on permissions, rate limits, pagination, error handling, or what the return data looks like. For a tool with 7 parameters and no output schema, this leaves critical behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just three words, this is under-specification rather than effective brevity. The description fails to provide necessary context and doesn't earn its place as a helpful tool description. It's too minimal to be considered well-structured for agent understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'party coordinated expenditures' are, how results are returned, or any behavioral aspects. The agent would struggle to use this tool effectively without significant additional context or trial-and-error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the input schema with clear descriptions. The description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get party coordinated expenditures' is essentially a tautology that restates the tool name. It provides the basic verb ('Get') and resource ('party coordinated expenditures') but lacks specificity about what exactly is being retrieved or any distinguishing features from sibling tools like get_independent_expenditures or get_communication_costs. No additional context about scope or format is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or comparisons to sibling tools like get_independent_expenditures or get_communication_costs, which appear related to expenditure tracking. The agent receives no help in selecting between these options.
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 of behavioral disclosure. It only states the action ('Get detailed information') without revealing traits like read-only status, potential rate limits, authentication needs, or response format. For a tool with no annotation coverage, this is a significant gap in 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and efficient, with no wasted words. It directly states the tool's purpose without unnecessary elaboration. However, it could be more structured by including key details, but it earns high marks for brevity and clarity in its current form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not explain what 'detailed information' includes, how results are returned, or any behavioral aspects like error handling. For a tool with no structured data to supplement it, the description should provide more context to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both parameters ('candidate_id' and 'election_year') documented in the schema. The description does not add any meaning beyond what the schema provides, such as explaining parameter interactions or usage examples. With high schema coverage, a baseline score of 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose ('Get detailed information about a candidate'), which is clear but vague. It specifies the verb 'Get' and resource 'candidate', but lacks specificity about what 'detailed information' entails. It does not distinguish from sibling tools like 'get_candidate_contributions' or 'search_candidates', which limits its differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention when to use it over sibling tools such as 'get_candidate_contributions' for financial data or 'search_candidates' for finding candidates. There are no explicit instructions on context or exclusions, leaving usage unclear.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Get' implies a read-only operation, it doesn't specify authentication requirements, rate limits, error conditions, or what format the 'detailed information' returns. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a simple lookup tool and gets straight to the point without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficiently complete. It doesn't explain what 'detailed information' includes, how results are structured, or any behavioral constraints. For a tool that presumably returns structured data about committees, more context about the response format would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'committee_id' clearly documented as 'FEC committee ID' in the schema. The description adds no additional parameter information beyond what the schema provides, which is acceptable given the high schema coverage but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get detailed information about a committee' clearly states the action (get) and resource (committee), making the purpose understandable. However, it's somewhat vague about what 'detailed information' entails and doesn't differentiate this tool from siblings like get_candidate or get_filings that also retrieve information about political entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or how it differs from sibling tools like get_candidate (which retrieves candidate data) or get_filings (which retrieves filing data). The agent must infer usage from the tool name alone.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it 'gets' data (implying read-only), but doesn't mention any behavioral traits like pagination, rate limits, authentication requirements, or what happens when multiple optional parameters are combined. For a data retrieval tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 6 words ('Get FEC audit cases and findings'). It's front-loaded with the core purpose and contains no unnecessary verbiage. Every word earns its place in communicating the essential function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what 'audit cases and findings' actually means in practice, what data format is returned, or how the optional parameters interact. For a data retrieval tool with multiple filtering options, more context would be helpful for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema itself. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get FEC audit cases and findings' clearly states the verb ('Get') and resource ('FEC audit cases and findings'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'get_filings' or 'search_candidates', but the specificity of 'audit cases and findings' provides inherent domain distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_filings' that might overlap in data retrieval contexts, there's no mention of when this tool is appropriate or when other tools should be preferred. The description is purely functional without contextual usage information.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action 'Get' but does not describe traits like whether it's read-only, requires authentication, has rate limits, or what the output format looks like. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It is appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and the description lacks behavioral and usage details, it is incomplete. For a tool with 3 parameters and potential complexity in contributions data, the description should provide more context on output format, limitations, or how it fits with siblings, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents all parameters (candidate_id, election_year, sort). The description adds no additional meaning beyond what the schema provides, such as clarifying the scope of 'individual contributions' or how parameters interact. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'individual contributions for a candidate', making the purpose understandable. However, it does not differentiate from siblings like 'get_candidate_financials' or 'search_candidates', which might also involve candidate data, so it lacks specific distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it does not mention how it differs from 'get_candidate_financials' or when to prefer it over 'search_candidates' for contribution-related queries, leaving usage context implied at best.
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 of behavioral disclosure. It states the tool 'Get financial data' but does not clarify if this is a read-only operation, requires authentication, has rate limits, or what the output format might be. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not address behavioral aspects like safety, permissions, or output format, which are crucial for a tool that retrieves data. This leaves the agent with insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for 'candidate_id' and 'election_year'. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('financial data for a candidate'), making the purpose understandable. However, it does not differentiate this tool from potential siblings like 'get_candidate' or 'get_candidate_contributions', which might also retrieve candidate-related data, so it lacks specificity for sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_candidate' and 'search_candidates' available, there is no indication of scenarios where this tool is preferred or excluded, leaving usage ambiguous.
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 of behavioral disclosure. 'Get' implies a read operation, but the description doesn't address important behavioral aspects like authentication requirements, rate limits, pagination behavior, error conditions, or what format the costs are returned in. For a 7-parameter tool with no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 4 words, with zero wasted language. It's front-loaded with the core purpose and uses efficient phrasing. Every word earns its place in this minimal description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a 7-parameter tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'communication costs' encompass, what format results are returned in, or any behavioral characteristics. For a data retrieval tool in what appears to be an FEC API context, more context about the data domain and return format would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all 7 parameters well-documented in the schema itself. The description adds no parameter-specific information beyond what's already in the schema. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'corporate/union communication costs', providing a specific purpose. However, it doesn't distinguish this tool from its siblings like get_audit_cases or get_filings, which likely retrieve different types of FEC data. The description is accurate but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With 10 sibling tools on the server, there's no indication of what makes this tool unique for retrieving communication costs versus other FEC data types. No context about prerequisites, typical use cases, or exclusions is provided.
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 of behavioral disclosure. It only states what the tool does ('Get electioneering communications') without mentioning any behavioral traits such as whether this is a read-only operation, potential rate limits, authentication requirements, pagination behavior, or what the output looks like. This leaves significant gaps for an agent to understand how to interact with it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, front-loading the core purpose without any wasted text. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a tool with 7 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the return values, behavioral aspects, or usage context, leaving the agent with incomplete information to operate the tool effectively despite the good parameter documentation in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with all 7 parameters well-documented (e.g., committee_id, candidate_id, date ranges, amounts, sort). The description adds no additional parameter information beyond what's in the schema, so it meets the baseline score of 3 for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('electioneering communications'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its siblings (like get_communication_costs or get_independent_expenditures) which might also retrieve related political communication data, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like get_communication_costs and get_independent_expenditures that might overlap in domain, there's no indication of what makes electioneering communications distinct or when this specific tool is appropriate.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions retrieval with filters but doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication needs, pagination behavior, or error handling. This is inadequate for a tool with 7 parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no annotations, no output schema), the description is insufficient. It doesn't explain what 'official FEC filings' entail, how results are returned, or any behavioral traits, leaving significant gaps for an AI agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by mentioning 'filters', which aligns with the optional parameters in the schema, but doesn't provide additional context or examples beyond what's in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve') and resource ('official FEC filings'), making the purpose understandable. However, it doesn't specifically differentiate this tool from its siblings like 'get_candidate_financials' or 'get_committee', which might also retrieve FEC-related data, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_candidate' or 'search_candidates'. It mentions filters but doesn't specify scenarios or exclusions, leaving the agent to infer usage from the tool name and parameters alone.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'gets' data, implying a read-only operation, but doesn't specify whether it's a search, list, or filter operation, nor does it describe output format, pagination, rate limits, or authentication requirements. This leaves significant gaps for a tool with 8 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to quickly understand the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'independent expenditures' are in this context, how results are returned, or provide any behavioral context beyond the basic purpose. The agent would need to rely heavily on the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'supporting or opposing candidates,' which aligns with the support_oppose_indicator parameter, but doesn't add meaningful context beyond what the 100% schema coverage already provides. The schema descriptions thoroughly document all 8 optional parameters, so the description adds minimal value here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('independent expenditures') with the purpose of retrieving data about expenditures supporting or opposing candidates. It distinguishes itself from siblings like get_candidate_contributions or get_communication_costs by focusing specifically on independent expenditures, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or compare with sibling tools like get_communication_costs or get_party_coordinated_expenditures, leaving the agent to infer usage based on the tool name alone.
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 of behavioral disclosure. It states the action ('search') but doesn't describe key traits like whether results are paginated, sorted, or limited; authentication needs; rate limits; or what the output looks like (e.g., list of candidates). This leaves significant gaps for a search 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads the core purpose ('search for candidates') and adds just enough detail ('by name or other criteria') without redundancy. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a search tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., result format, pagination), usage context, and output expectations, which are critical for effective tool invocation. It relies too heavily on the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters (name, state, office, election_year). The description adds minimal value beyond the schema, mentioning 'name or other criteria' which loosely maps to parameters but doesn't provide additional syntax, format, or usage details. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('search') and resource ('candidates'), specifying search criteria ('by name or other criteria'). It distinguishes from siblings like 'get_candidate' (singular retrieval) by indicating a search operation, though it doesn't explicitly contrast with other search-like tools (none listed).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. It doesn't mention when to prefer this over 'get_candidate' (for specific retrieval) or other sibling tools, nor does it specify prerequisites or exclusions. Usage is implied by the search functionality but not explicitly framed.
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 of behavioral disclosure. It mentions 'Get links' but doesn't specify whether this is a read-only operation, if it requires authentication, what format the links are in (e.g., URLs, file paths), or any rate limits. For a tool with no annotation coverage, this leaves critical behavioral traits unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place, achieving optimal conciseness without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, no output schema), the description is minimally adequate. It states the purpose but lacks behavioral details, usage context, and output information. With no output schema, the description doesn't explain what 'links' entail (e.g., format, structure), leaving gaps that could hinder effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear descriptions for both parameters, including an enum for 'data_type'. The description adds no additional parameter semantics beyond what the schema provides, such as explaining the relationship between 'data_type' and 'election_year' or usage examples. Baseline 3 is appropriate given the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get links') and resource ('bulk data downloads'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'get_filings' or 'get_candidate_contributions' that might also provide data downloads, missing an opportunity for precise distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_filings' or 'search_candidates' that might offer similar or overlapping data, there's no indication of scope, prerequisites, or comparative use cases, leaving the agent to guess based on tool names alone.
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:
Score Badge
Copy to your README.md:
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/psalzman/mcp-openfec'
If you have feedback or need assistance with the MCP directory API, please join our Discord server