guardian-contributions-mcp

by cstillick

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Each tool has a well-defined purpose, with clear distinctions between similar concepts like get_combined, get_summary, and get_continuing. The query tool is flexible but still distinct as a category-based aggregator.
Naming Consistency4/5
Most tools follow a consistent 'get_' pattern for data retrieval, with 'list_', 'query', 'search_', and 'refresh_' used for different types of operations. The pattern is logical but not perfectly uniform.
Tool Count5/5
13 tools cover the domain of campaign finance data comprehensively without being excessive. Each tool addresses a specific aspect of the system, from calendar to contributions to flags.
Completeness5/5
The tool surface covers all major operations expected for a read-only campaign finance data API: querying committees, candidates, contributions, reports, filings, and computed alerts. The flexible query tool fills any gaps.
Average 3.2/5 across 13 of 13 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
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?
No annotations are present, so the description carries full burden. It mentions 'computed alerts' but does not state if the tool is read-only, whether it requires specific authentication, or what side effects occur. The list of alert types gives some output context but no behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one line with a colon-separated list) but lacks structure. It front-loads 'Computed alerts:' then enumerates types, but no sentences or logical flow. It is appropriately short but could be better organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, no annotations, and 0% parameter coverage, the description is severely incomplete. It fails to explain what the tool returns, how parameters affect results, or any fundamental behavior, making it nearly unusable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters. It does not mention 'district', 'org_id', or 'year' at all, leaving the agent without any understanding of how to use these optional parameters to filter results.
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 lists specific types of alerts (e.g., 'large-loan self-dealing', 'amended-report-used'), which clarifies that the tool returns computed flags. The verb is implied ('get') but missing the resource object; however, the list of alert types provides a clear purpose and distinguishes from sibling tools that fetch different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no indication of prerequisites, filtering logic, or scenarios where this tool is appropriate, leaving the agent to guess.
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 provided; the description does not disclose behavioral traits like read-only, authentication needs, or rate limits. For a tool with no annotations, the description should provide more context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one short sentence), but lacks important details about the output and parameter. It is not optimally informative for its brevity.
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?
Given the lack of output schema and minimal description, the tool is incomplete for an agent to understand what the 'parsed Schedule Summary' contains or how to interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to explain what 'filing_id' represents or how to obtain it. The single parameter is critical but entirely undocumented beyond its name.
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 specifies it returns a 'parsed Schedule Summary' for one filed report, indicating a specific verb and resource. It distinguishes from sibling tools like get_summary and get_contributions, though the term 'Schedule Summary' could be clearer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus sibling tools like get_summary or list_filings. The context hints are insufficient for an agent to decide appropriate usage.
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, the description carries full burden but only mentions 'whole-race rollup' as a behavioral hint. It does not disclose read-only status, pagination, response structure, 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?
Single sentence with no redundancy. Every word is meaningful and front-loaded. However, conciseness sacrifices substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% parameter coverage, the description is far from complete. It omits essential information for correct agent invocation, such as parameter details and behavioral expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds no meaning to the parameters (district, year). It does not explain district format, year filter behavior, or defaults. Agent cannot infer parameter usage from description alone.
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 subject (every candidate/committee) and scope (House/Senate district, whole-race rollup), but the verb 'list' is implied rather than explicit. It differentiates from sibling tools like search_candidates by indicating a broader listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 such as search_candidates or get_committee. The description does not specify prerequisites or exclusions.
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 full burden. It states it returns 'itemized receipts + totals' and supports filtering, but does not disclose any behavioral traits such as pagination, rate limits, or whether the operation is read-only or destructive. This is insufficient for understanding the tool's side effects or constraints.
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 a single sentence that front-loads the core purpose and then lists key filters. It is concise with no wasted words, though it could be structured slightly better to include the omitted parameters. For a short description, it is efficient.
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?
Given the complexity of 8 parameters, no output schema, and no annotations, the description is incomplete. It does not explain the return format, how dedup works, what receipt_type values are valid, or how org_id and district relate to one another. The agent lacks sufficient context to invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains 4 of 8 parameters (date_from, date_to, receipt_type, min_amount) and fails to mention org_id, district, dedup, and year, which are significant. The description adds some value but leaves half the parameters unexplained.
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 that the tool returns 'itemized receipts + totals for a committee or a whole district'. It uses a specific verb ('get') and resource ('contributions'), and the scope (committee/district) helps distinguish it from sibling tools like get_committee (which likely focuses on committee info) and get_summary (which might return aggregated totals).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions optional filters (date window, receipt_type, min_amount) but does not provide explicit guidance on when to use this tool versus alternatives like get_committee or get_summary. No 'when not to use' or alternative tool names are given, leaving the agent to infer usage context.
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?
Describes that the calendar is computed according to Rule 1, indicating dynamic behavior. However, no explicit read-only or side-effect declaration, and no annotations to supplement. The description adds some behavioral context but is not comprehensive.
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?
One sentence, concise and front-loaded. No unnecessary words, every part adds value.
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?
Describes what the tool returns (key dates) but lacks details on the response structure or how the data is represented. Given no output schema, additional description of return format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the 'year' parameter's purpose, format, or behavior when null. With 0% schema description coverage, the description should compensate but fails to do so.
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 tool returns the reporting calendar with specific dates (primary date, pre-primary period, continuing window) and notes it's computed, not hardcoded. It distinguishes from sibling tools by being about calendar, not committees, candidates, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 like get_combined, get_committee, etc. No mention of prerequisites or context for selection.
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 transparency burden. It discloses the data source (parsed PDF) and a rule about not re-summing from bulk, but does not discuss side effects, authentication, or rate limits.
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 only two sentences, with no redundant words. Key information is front-loaded: the type of figures and the source rule.
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?
With a simple input schema and no output schema, the description should cover return format and parameter details. It omits both, leaving the agent without guidance on what to expect or how to use org_id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter (org_id) with no description. The tool description does not mention org_id or its purpose, so it adds no meaning beyond the schema. Schema coverage is 0%, yet the description fails to compensate.
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 retrieves summary figures from parsed report PDF, specifying the fields (Beginning, Raised excl-loans, etc.). It provides a specific verb-resource combination but does not directly distinguish from sibling tools like get_combined or get_report, though the source is unique.
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 indicates it should always be used from the parsed report PDF and never re-summed from bulk, implying a specific context. However, it does not explicitly state when to use this tool versus alternatives or 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 provided, so the description carries full burden. It discloses the sorting (newest-first) but fails to mention other behavioral traits like read-only nature, authentication needs, or rate limits. For a tool with no annotations, this is insufficient.
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 with one sentence that front-loads the core purpose. No extraneous words; every part adds value.
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 no output schema, the description partially covers return values by listing fields, but omits details like possible values, pagination, or error conditions. For a simple list tool with one param, it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description does not explain the sole parameter 'org_id' beyond implying it identifies a committee. It lists output fields (type, period, amended) but provides no definitions or context for those, leaving meaning unclear.
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 tool lists all reports for a committee, including details like type, period, and amendment status, sorted newest-first. This distinguishes it from sibling tools like 'get_report' which fetch individual reports, though it does not explicitly name the verb.
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 when needing a list of filings for a committee, but provides no explicit guidance on when not to use it or alternatives. Siblings like 'get_report' exist for single-record lookups, but this is not stated.
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 full burden. It discloses that Ending excludes continuing-period spend and that the tool recomputes values, but does not state whether it is read-only, requires authentication, or has 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded with key information. However, the second sentence is somewhat technical, and every sentence earns its place.
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?
Given no output schema, the description should explain return values; it does not. It also omits the year parameter explanation. The tool is moderately complex with three parameters, and the description only partially covers them, making it incomplete for intelligent selection and invocation.
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 0% schema description coverage, the description should explain all parameters. It mentions org_id and district in context, clarifying their roles, but fails to mention the 'year' parameter, leaving one of three parameters undocumented.
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 tool computes a headline number combining pre-primary and continuing totals for a committee or district. It explains the formula and distinguishes from siblings like get_continuing by specifying the combination.
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 for one committee (org_id) or every candidate in a district, but does not provide explicit guidance on when to use versus alternatives like get_continuing or list_district_candidates. No exclusions or when-not scenarios are mentioned.
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 full burden. It discloses the dedup logic and default window, but lacks details on permissions, side effects, or output format. For a read-only tool, this is adequate but not comprehensive.
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 concise with two sentences, front-loading the main purpose. Every sentence adds value, though it could be more structured with separate parameter explanations.
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's specificity, the description covers core behavior but omits output format, error conditions, and permissions. No output schema or annotations exist, leaving gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It only vaguely relates date parameters to the cycle's computed window and does not explain org_id or year. Significantly deficient in parameter documentation.
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 tool returns a deduped continuing-window total split by Raised vs Loans, counting each receipt once across multiple reports. This is specific and distinguishes it from sibling tools like get_summary or get_contributions.
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 for deduped continuing totals but does not explicitly state when to use this tool versus alternatives or provide exclusions. No guidance on prerequisites or when not to use.
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 exist, so the description carries the burden. It discloses that the tool surfaces other committees of the same candidate and Rule 6 classification, which are key behaviors. However, it does not confirm read-only nature, required permissions, 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?
The description is concise with two sentences, front-loading the primary purpose and adding a valuable detail about cross-referencing. No unnecessary words.
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?
With no output schema, the description should explain what 'Committee detail' includes, but it only hints at returning other committees. It lacks field descriptions, return structure, and practical examples, leaving gaps for the 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 0%, but the description explains that 'org_id' is an 'Ethics #', adding context beyond the schema's minimal 'Org Id'. However, it provides no format, validation, or examples.
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 it retrieves committee detail by Org ID, and explicitly mentions it also includes other committees of the same candidate, distinguishing it from sibling tools like get_continuing. The reference to 'Rule 6' adds specificity.
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 for looking up committees by an Ethics number, but does not explicitly state when to use this tool over alternatives like get_continuing or when not to use it. No exclusions or prerequisites are given.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states that an identical re-pull is reported as 'no change' (Rule 13), not a fake update. This is a key behavioral trait beyond just extracting data. However, it does not mention side effects, authorization needs, or rate limits, which are minor for a read-only 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 a single, well-structured sentence that front-loads the core action and outcome. It is concise and avoids unnecessary words. However, it could be improved by adding the missing parameter information without becoming verbose.
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?
Given the tool has 1 optional parameter, no output schema, and no annotations, the description is incomplete. It does not explain what the 'as-of' date looks like or the format of the change indicator. The mention of 'Rule 13' is cryptic without context. The year parameter is ignored entirely, making the description insufficient for an agent to use the tool correctly without further inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter (year) with no description, and the schema description coverage is 0%. The description does not mention this parameter at all, leaving the agent guessing how year affects the output (e.g., filtering to a specific filing year). This is a severe omission.
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 that the tool extracts the as-of (max Filed/Receipt date) and whether it changed since the prior pull. This is a specific action (extract) on a specific resource (status change indicator), and the mention of Rule 13 helps distinguish it from sibling tools that retrieve raw data (e.g., get_report, get_summary).
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 implicitly defines when to use the tool: to check if a re-pull would result in a 'no change' or a real update. This is clear for an agent performing data synchronization. However, it does not explicitly state when not to use it or list alternatives, but the purpose is self-explanatory enough.
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?
With no annotations, the description covers key behaviors: exact matching, returning all matches, and providing a flag (has_multiple_committees) for disambiguation. It does not discuss authorization, rate limits, or error states, but the essential behavior is well-explained.
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 two sentences, front-loaded with purpose and key behavior, followed by filter examples. No extraneous words.
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?
Given no output schema, the description explains the main output feature (returns all matches, flags multiple committees). It does not detail pagination, error handling, or full return structure, but for a search tool this is adequate and consistent with sibling tool descriptions.
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 0%, so the description partially compensates by listing filterable parameters and giving format examples (e.g., district: 'HD-42/SD-15', party: '(D)/(R)'). However, it omits the 'year' parameter and does not describe each parameter's full semantics or constraints.
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 defines the tool's purpose: 'Resolve candidates to committees (Org IDs)' and distinguishes it from siblings by noting it never fuzzy-matches and flags multiple committees. The verb 'resolve' and resource 'candidates to committees' are specific.
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 lists filterable attributes (name, district, office, party, cycle) and states the tool never fuzzy-matches, but does not explicitly compare to sibling tools like list_district_candidates or provide guidance on when to choose this over alternatives.
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?
With no annotations, the description adequately discloses behavior: it returns a uniform envelope with specified fields, defaults for window to the calendar, and lists options. It does not mention authorization or rate limits, but for a query tool, the description is sufficient.
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 concise and well-structured: a single sentence explaining the tool's purpose, followed by bullet-like explanations of each parameter and the return structure. Every part is necessary and earned its place.
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 complexity (5 parameters, nested objects, no output schema, many siblings), the description is moderately complete. It explains the main parameters and return envelope but omits the 'year' parameter and does not fully clarify how the 'select' object works (schema says it's an object, description implies specific strings). More detail would be beneficial.
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 description coverage is 0%, so the description must compensate. It adds meaning by listing possible values for select and category, describing window as ISO dates with default, and options as a set of flags. However, it fails to mention the 'year' parameter present in the schema, which is a gap.
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 that the tool is a flexible category selector that picks combinations of entity and category in one call, listing specific options. It distinguishes itself from sibling tools (e.g., get_summary, get_combined) by implying it can replace multiple specific tools.
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 provides clear context on what the tool does and how to use it (select and category options, window, options). However, it does not explicitly state when to use this tool versus the sibling tools, nor does it mention any exclusions or 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.

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:

[![guardian-contributions-mcp MCP server](https://glama.ai/mcp/servers/cstillick/guardian-contributions-mcp/badges/card.svg)](https://glama.ai/mcp/servers/cstillick/guardian-contributions-mcp)

Score Badge

Copy to your README.md:

[![guardian-contributions-mcp MCP server](https://glama.ai/mcp/servers/cstillick/guardian-contributions-mcp/badges/score.svg)](https://glama.ai/mcp/servers/cstillick/guardian-contributions-mcp)

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/cstillick/guardian-contributions-mcp'

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