Beobachte die Beobachter. Kongress-Aktiengeschäfte, Bundesauftragsvergaben, Wahlkampffinanzierung, Lobbying-Meldungen und neue Vorschriften – neun MCP-Tools über offizielle US-Regierungsdaten, pro Aufruf bezahlt mit x402 USDC auf Base. Kein Konto, kein API-Schlüssel, kein Abonnement.
Kommerzielle Anbieter verkaufen Kongress-Handelsdaten hinter Monatsabonnements. Hier gibt es sie pro Aufruf, als strukturiertes JSON, für Agenten: $0.005–$0.02 pro Abfrage.
Tool | Preis | Was zurückgegeben wird |
| $0.02 | Aktiengeschäfte von Mitgliedern des US-Repräsentantenhauses, geparst aus offiziellen Meldungen nach dem STOCK Act – Mitglied, Ticker, Kauf/Verkauf, Datum, Betragsspanne. Filter nach Mitglied, Ticker, Typ, Bundesstaat, Zeitraum. |
| $0.01 | Der Index der Offenlegungsmeldungen – wer wann Handelsberichte eingereicht hat, mit offiziellen PDF-Links. |
| $0.01 | Bundesauftragsvergaben an beliebige Unternehmen – Beträge, Behörden, Daten, Beschreibungen. |
| $0.01 | Unternehmen → offizielle Bundesdatensätze zu Empfängern mit UEI und aktuellen Auftragssummen. |
| $0.01 | Wahlkampffinanz-Summen pro Kandidat – Einnahmen, Ausgaben, Kassenbestand, Schulden. |
| $0.005 | Kandidatenname → offizielle IDs, Partei, Amt, Ausschüsse. |
| $0.01 | Lobbying-Meldungen nach Auftraggeber oder Firma – Geld, Themen, namentlich genannte Lobbyisten. |
| $0.005 | Neueste Vorschriften und Bekanntmachungen zu beliebigen Themen. |
| $0.005 | Offizieller Status beliebiger Gesetzesvorlagen im Kongress. |
| kostenlos | Live-Schemas und ausgearbeitete Beispiele für alle neun Routen. |
Related MCP server: Disruption Intelligence MCP
Alles offiziell, alles gemeinfrei: Finanzoffenlegungen des Clerk des US-Repräsentantenhauses (geparst aus den Quell-PTR-PDFs), USAspending.gov, die Federal Election Commission, die Datenbank des Senate Lobbying Disclosure Act, der Federal Register und Congress.gov. Handelsmeldungen hinken Transaktionen um bis zu 45 Tage hinterher – das ist das gesetzliche Meldefenster, keine Datenverzögerung. Aktuelle Handelsabdeckung: US-Repräsentantenhaus (Senat geplant); in Papierform eingereichte Meldungen sind mit PDF-Links indexiert, aber nicht in Zeilen geparst.
{
"mcpServers": {
"gov-transparency": {
"command": "npx",
"args": ["-y", "@forgemeshlabs/gov-transparency-mcp"],
"env": {
"WALLET_PRIVATE_KEY": "0x..."
}
}
}
}WALLET_PRIVATE_KEY muss eine dedizierte Wallet mit geringem Guthaben sein, die eine kleine Menge USDC auf dem Base-Mainnet hält – niemals deine Haupt-Wallet. get_endpoint_spec funktioniert auch ohne eine solche.
Optionale Umgebungsvariablen: GOV_TRANSPARENCY_BASE_URL (Standard: https://x402.forgemesh.io), BASE_RPC_URL (Standard: https://mainnet.base.org).
Jeder Aufruf sendet eine normale HTTP-Anfrage; der Server antwortet mit 402 Payment Required und den genauen Bedingungen, der Client signiert eine USDC-Transferautorisierung (EIP-3009) und versucht es erneut, und der Transaktions-Hash der Abrechnung wird in der Antwort unter _payment zurückgegeben. Atomar: keine Daten ohne Zahlung, keine Zahlung ohne Daten.
MIT – nur der Code. Die zugrunde liegenden Regierungsdaten sind gemeinfrei.
PAID ($0.005) — Search US federal candidates by name: candidate ids, party, office, state, district, and principal campaign committees. The cheap resolver before get_candidate_money. Requires WALLET_PRIVATE_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| candidate | Yes | Candidate name, min 3 chars (required) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds non-obvious behavioral context beyond these: the call is paid at a specific rate ('$0.005') and requires an authentication credential ('WALLET_PRIVATE_KEY'). This is useful transparency that the annotations alone do not convey. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single, dense sentence that packs cost, purpose, result fields, ordering guidance, and a prerequisite with no filler. The most decision-relevant detail ('PAID ($0.005)') is front-loaded, and every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter search tool with no output schema, the description gives the agent everything needed: what to search, what data comes back, what it costs, what credential is required, and where it fits in the workflow with get_candidate_money. Annotations cover safety and openness. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the only parameter 'candidate' is already described as 'Candidate name, min 3 chars (required)' in the schema. The main description does add what the resolved output includes, but it does not add new meaning about the parameter itself beyond the schema. Baseline 3 is appropriate since the schema fully covers the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Search'), a resource ('US federal candidates'), and the key fields returned ('candidate ids, party, office, state, district, and principal campaign committees'). It also distinguishes itself from the closer sibling by calling itself 'the cheap resolver before get_candidate_money.' An agent can clearly tell what this tool does and how it relates to nearby tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly positions the tool as 'The cheap resolver before get_candidate_money,' giving clear usage guidance for when this tool should be invoked relative to a specific alternative. It also states a prerequisite ('Requires WALLET_PRIVATE_KEY'), which helps the agent decide whether it can call this tool at all.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID ($0.01) — Campaign finance totals for a US federal candidate: receipts, spending, cash on hand, debts, individual vs PAC split, per recent cycle. Pass a name (fuzzy) or exact candidate_id; optional office preference. Requires WALLET_PRIVATE_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| office | No | ||
| candidate | No | Candidate name, min 3 chars | |
| candidate_id | No | Exact FEC candidate id (alternative to name) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint=true and destructiveHint=false, and the description adds genuinely new behavioral disclosures: the $0.01 cost ('PAID ($0.01)'), the WALLET_PRIVATE_KEY authentication requirement, and fuzzy name matching that aligns with openWorldHint. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: cost plus return fields, input strategy, and auth requirement. The core purpose is front-loaded before calling details, with zero filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema present, the description enumerates the returned data fields (receipts, spending, cash on hand, debts, individual vs PAC split) and covers cost, auth, and input modes. It is slightly vague on what 'per recent cycle' concretely means (which cycles, how many) and does not describe output structure, but this is adequate for a simple 3-parameter read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% and the office parameter has no schema description, but the description compensates by explaining the input strategy: fuzzy name vs exact candidate_id as alternatives, and office as an optional preference. The fuzzy-matching semantics and the optionality/preference framing of office go beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource — campaign finance totals for a US federal candidate — and enumerates the exact data returned (receipts, spending, cash on hand, debts, individual vs PAC split, per recent cycle). The campaign-money domain clearly distinguishes it from siblings like get_trade_filings, get_congress_trades, and lookup_bill without needing to inspect their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides calling context ('Pass a name (fuzzy) or exact candidate_id; optional office preference') and a hard prerequisite (Requires WALLET_PRIVATE_KEY), so an agent knows how to invoke it and that it is paid. However, it names no sibling alternatives and gives no explicit when-to-use or when-not-to-use guidance relative to tools like find_candidate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID ($0.02) — Congressional stock trades parsed from official STOCK Act disclosures: US House member trades with ticker, asset, buy/sell, transaction date, and disclosed amount range. Filter by member name, ticker, trade type (purchase/sale/sale_partial/exchange), state, or date window. Disclosures lag trades by up to 45 days by law. Requires WALLET_PRIVATE_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| limit | No | Max rows (default 25, max 100) | |
| since | No | ISO date lower bound on transaction date | |
| state | No | State or district prefix, e.g. 'VA' or 'VA01' | |
| until | No | ISO date upper bound on transaction date | |
| member | No | Member name substring, e.g. 'wittman' | |
| ticker | No | Exact ticker, e.g. 'NVDA' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context beyond annotations: a $0.02 cost, a required WALLET_PRIVATE_KEY, and the statutory 45-day disclosure lag. This gives an agent important operational expectations for an otherwise 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences deliver cost, source, scope, fields, filters, regulatory lag, and authorization. Information is front-loaded with the paid indicator and each sentence earns its place; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only query tool with no required parameters and no output schema, the description covers the source, data scope, returned fields, filtering dimensions, cost, auth requirement, and data freshness caveat. It gives an agent enough to call the tool correctly and interpret the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 86%, and the schema already documents the meaning of member, ticker, state, since, until, and limit. The description restates the filter concepts (date window, trade type, state) without adding substantial new semantics or value formats beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Describes a specific verb ('get') and resource ('Congressional stock trades parsed from official STOCK Act disclosures'), and enumerates the returned fields and available filters. It does not explicitly distinguish itself from the sibling tool 'get_trade_filings', so it lacks full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context about the domain (US House member trades), the data source, the available filters, and a precondition (requires WALLET_PRIVATE_KEY). It does not explicitly state when to prefer this tool over 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.
PAID ($0.01) — Resolve a company name to its official federal recipient records: legal name, UEI, parent/child level, recent federal award totals, profile link. Use before search_federal_contracts to disambiguate entities. Requires WALLET_PRIVATE_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max entities (default 5, max 20) | |
| company | Yes | Company name, min 3 chars (required) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, and non-destructive behavior. The description adds meaningful context beyond the annotations: the $0.01 cost, the authentication requirement, and the specific federal records involved. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the most decision-relevant facts (cost and purpose), and each clause earns its place: what it resolves, what it returns, when to use it, and what is required. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by listing the key return fields. It also covers cost, auth, use case, and relationship to a sibling tool. For a straightforward two-parameter lookup, this is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage for both parameters, including default/max for limit and min character length for company. The tool description does not add material detail about how the parameters affect behavior beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Resolve') and resource ('official federal recipient records'), and enumerates exactly what is returned: legal name, UEI, parent/child level, recent award totals, and profile link. It also distinguishes itself from the sibling search_federal_contracts by explicitly positioning itself as the disambiguation step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit directive: 'Use before search_federal_contracts to disambiguate entities.' It also discloses a prerequisite (WALLET_PRIVATE_KEY) and the paid nature of the call, giving the agent concrete conditions for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE — no wallet needed. Live call spec for the gov-transparency routes: price, input JSON schema, and worked request/response examples from the service's OpenAPI doc. Call with no arguments to list all nine routes, or pass a path for full detail.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Route path, e.g. 'congress-stock-trades' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the description does not need to restate safety. The description adds useful behavioral context: the call is free, live, sourced from the service's OpenAPI doc, and behaves differently depending on whether a path is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the most important facts—free and what the tool returns—then gives precise invocation guidance. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple introspection tool with one optional parameter and no output schema, the description fully covers invocation modes, what the returned spec contains, and cost semantics. An agent has enough information to select and call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single 'path' parameter at 100% coverage. The description adds meaningful behavior beyond the schema by explaining that omitting the path lists all nine routes while providing a path returns full detail. This clarifies optionality and default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: getting the live OpenAPI spec for gov-transparency routes, including price, input JSON schema, and worked examples. It also distinguishes itself from the sibling data-retrieval tools by positioning itself as a meta/introspection tool rather than a data-fetching tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when to use each invocation style: call with no arguments to list all nine routes, or pass a path for full detail. It also notes that the call is free and requires no wallet, which is useful context. It does not explicitly name alternative tools or when-not-to-use, but the usage context is otherwise clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID ($0.01) — US House financial-disclosure filing index: who filed periodic transaction reports, annual reports, amendments, and more — filer, district, type, date, and official PDF link. Poll filing_type 'P' to catch fresh trade disclosures early. Requires WALLET_PRIVATE_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Filing year, e.g. 2026 | |
| limit | No | Max rows (default 25, max 100) | |
| state | No | State or district prefix | |
| member | No | Member name substring | |
| filing_type | No | Filing type code, e.g. 'P' for trade reports |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive. The description adds valuable behavioral context beyond that: the call costs $0.01, requires WALLET_PRIVATE_KEY, and returns an index with official PDF links.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the cost, and covers the resource, output contents, primary use case, and authentication requirement. Every clause carries useful information with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by listing what the index contains: filer, district, type, date, and official PDF link. It also addresses payment, key requirements, and the polling use case; only minor details such as rate limits or explicit alternative routing are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3 because each parameter is already explained. The description only lightly adds to parameter meaning; mentioning polling filing_type 'P' mostly restates the schema's own example of 'P' for trade reports.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: the U.S. House financial-disclosure filing index, including filer, district, type, date, and PDF link. It does not explicitly differentiate this from the similarly named sibling get_congress_trades, so it stops short of full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a concrete usage cue: poll filing_type 'P' to catch fresh trade disclosures early. It also highlights the wallet-key requirement, but it does not state when to avoid this tool or prefer a sibling alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID ($0.005) — Official status of a bill in the US Congress: title, sponsor, latest action, policy area, committees, and counts of actions/cosponsors/amendments. Address by congress number, type (hr, s, hjres, sjres...), and bill number. Requires WALLET_PRIVATE_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Bill type: hr, s, hjres, sjres, hconres, sconres, hres, sres | |
| number | No | Bill number, e.g. '1' | |
| congress | No | Congress number, e.g. '119' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and destructiveHint annotations, the description discloses that the call is paid ($0.005) and requires WALLET_PRIVATE_KEY. This is important behavioral context that the annotations do not convey, and it directly affects whether an agent should proceed with the call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence with no filler. It front-loads the cost and official-status nature, then lists the return fields, the addressing parameters, and the required credential. Every part of the sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set, complete schema coverage, and strong annotations, the description supplies the remaining critical context: what data is returned, how to identify a bill, and the financial/credential prerequisites. No output schema exists, but the description enumerates the returned fields well enough for an agent to know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for all three parameters with examples, so the baseline is appropriate. The description reinforces the addressing pattern by naming congress number, type, and bill number, but it does not add meaning materially beyond what the schema already covers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a lookup for official status of a US Congress bill, listing the exact fields returned (title, sponsor, latest action, policy area, committees, counts). The explicit verb 'lookup' plus the resource scope distinguishes it from the sibling tools, which are all in different domains like trade filings or contracts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete addressing instructions: use congress number, bill type, and bill number. It also notes the payment and wallet-key requirement, which is essential before calling. It does not explicitly state when to prefer this over alternatives, but none of the listed siblings appear to be comparable bill-lookup tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID ($0.01) — Federal contract awards won by any company: award id, dollar amount, awarding agency, dates, description, and record link, sorted largest first. Optional agency and date-window filters. Requires WALLET_PRIVATE_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max awards (default 10, max 50) | |
| since | No | ISO start date (default: 2 years back) | |
| until | No | ISO end date (default: today) | |
| agency | No | Awarding top-tier agency, e.g. 'Department of Defense' | |
| recipient | Yes | Company name, min 3 chars (required) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description adds critical operational behavior: the call costs $0.01, requires WALLET_PRIVATE_KEY, and returns results sorted largest first. This meaningfully helps an agent understand side effects and prerequisites. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences pack the cost flag, resource, output fields, filter options, and auth requirement without fluff. The most decision-critical detail (PAID) is front-loaded. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description lists the returned fields and sorting order, which is enough for an agent to interpret results. Required auth, cost, and optional filters are all covered. The annotations handle safety and open-world expectations, completing the picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains all parameters. The description loosely refers to 'agency and date-window filters' and 'any company', but adds no parameter-level detail beyond what the schema provides. This meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('search') and resource ('Federal contract awards won by any company'), and enumerates the returned fields. It distinguishes itself from siblings like get_contractor_profile by focusing on award records with award id, dollar amount, agency, dates, description, and link. The sorting behavior ('largest first') adds further precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this to find federal contract awards for a company, with optional agency and date-window filters. It also states the prerequisite that WALLET_PRIVATE_KEY is required. It does not explicitly name alternatives or say when not to use it, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID ($0.01) — US federal lobbying filings by client company or lobbying firm: reported income, issue areas, specific-issue text, and named lobbyists per filing. Optional year filter. Requires WALLET_PRIVATE_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Filing year, e.g. '2025' | |
| client | No | Client organization name, e.g. 'coinbase' | |
| registrant | No | Lobbying firm name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavioral context not present in annotations: the tool is paid ($0.01) and requires WALLET_PRIVATE_KEY. These are operationally critical disclosures. It does not contradict the readOnlyHint=true or destructiveHint=false annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the critical paid marker, then states the resource, return fields, optional filter, and authentication requirement. Every clause earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by naming the returned fields explicitly. It also covers cost, authentication, and optional filtering. It does not mention pagination or result limits, but the tool is sufficiently specified for a first call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds mild extra meaning by framing client and registrant as the searchable entities ('by client company or lobbying firm') and marking year as optional, but it does not materially extend the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as US federal lobbying filings and enumerates the returned content: reported income, issue areas, specific-issue text, and named lobbyists. The lobbying domain distinguishes it from sibling tools like search_federal_contracts, though there is no explicit verb such as 'search' in the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides prerequisites — PAID ($0.01) and Requires WALLET_PRIVATE_KEY — and notes an optional year filter, but gives no guidance on when to prefer this tool over siblings or when not to use it. No alternatives or exclusion conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID ($0.005) — Newest US regulations and official notices matching a topic: proposed and final rules, executive orders, and notices with agency, date, abstract, and links, newest first. Empty query returns the latest government-wide. Requires WALLET_PRIVATE_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Search term, e.g. 'stablecoin' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses the $0.005 cost, the requirement of WALLET_PRIVATE_KEY, the return fields (agency, date, abstract, links), the newest-first ordering, and the empty-query behavior. This is substantial practical behavioral information an agent needs before calling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that front-loads the critical paid requirement, then packs in the result types, output fields, ordering, default behavior, and auth requirement. Every clause contributes without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one optional parameter and no output schema, the description covers the essential invocation details: cost, authentication, query semantics, default behavior, and return content. No significant gap remains for an agent to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes 'q' as a search term with an example. The description adds meaning by framing it as a 'topic', indicating the parameter is optional, and explaining that an empty query returns latest government-wide results. This goes beyond the schema's basic definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: returning the newest US regulations and official notices from the Federal Register, listing specific content types (proposed/final rules, executive orders, notices) and result fields. This clearly differentiates it from sibling tools focused on contracts, lobbying, trades, and bills.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on how to use it: supply a topic query, or leave it empty for government-wide latest notices. It does not explicitly compare against sibling tools, but the domain is distinct enough that an agent can infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0find_candidateget_candidate_moneyget_congress_tradesget_contractor_profileget_endpoint_specget_trade_filingslookup_billsearch_federal_contractssearch_lobbyingwatch_federal_registerThe tools are mostly distinct, each targeting a specific transparency dataset like contracts, lobbying, bills, or campaign finance. The only real ambiguity is between get_trade_filings and get_congress_trades, but their descriptions clarify that one returns the filing index while the other returns parsed stock trade data.
The set generally follows a verb_noun pattern with get_ and search_ prefixes, which is predictable. Minor inconsistencies like find_candidate versus search_federal_contracts and watch_federal_register are understandable but prevent a perfect score.
Ten tools is well-scoped for a government transparency server covering multiple domains without feeling bloated or thin. Each tool serves a distinct purpose, and the resolver tools like find_candidate and get_contractor_profile earn their place.
The server covers a broad set of transparency topics: congressional trades, federal contracts, campaign finance, lobbying, regulations, and bills. Minor gaps exist such as no direct way to retrieve full filing text or detailed congress member profiles, but the core workflows are reasonably complete.
Pay-per-call DeFi and macro intel for AI agents. x402 USDC tools via streamable HTTP /api/mcp.
Paid x402 tools over MCP: search, FX, LEI, company research, risk. Pay-per-call USDC on Base.
Pay-per-call government data over x402: provenance chains, Ed25519 attestations, no API keys.
Pay-per-action access to APIs and MCP tools over Lightning L402 and Base USDC x402.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/forgemeshlabs/gov-transparency-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server