Skip to main content
Glama

mcp-knowledge

by io.github.getgapup

gov_procurement_multi

Read-only

Aggregate public procurement tenders (calls for tender / appels d'offres) from multiple government sources simultaneously: TED Europa v3 (27 EU countries, keyless API), BOAMP France (opendatasoft, keyless), UK Contracts Finder (OCDS standard, keyless), SAM.gov United States (requires SAM_GOV_API_KEY env var), and bund.de Germany (HTML scraping, partial). Returns structured tender records with buyer authority, EU CPV sector code, estimated contract value converted to EUR via live FX rates, submission deadlines, and direct notice URLs. Use when: a B2G agent needs to find government contract opportunities matching keywords across multiple jurisdictions; building a pipeline of public tenders for bid/no-bid qualification; monitoring a domain by CPV code; market sizing public sector spend. Key inputs: query (keywords), countries (ISO-2 array), cpv_codes (EU standard codes, e.g. 72000000=IT services, 45000000=construction, 79000000=business services), min_value_eur (filter), published_after (ISO date, defaults to 30 days ago). SLA: <=25s p95 (all sources fetched in parallel, 8s budget per source). Optional env var SAM_GOV_API_KEY enables US federal tenders (free key at api.sam.gov). Quality score: 25 pts if TED EU retrieved, 15 pts per other source retrieved (max 60), 10 pts if >= 10 tenders returned, 5 pts if aggregates computed. Status: failed < 30 / partial 30-59 / final >= 60.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
asyncNoIf true, returns a job_id immediately (<200ms) instead of waiting for the result. Poll the result with job_result(job_id). Use for slow tools to avoid client timeouts.
queryYesKeywords to search for tenders (e.g. "cybersecurity audit", "construction", "consulting AI")
countriesNoCountries to search. Defaults to ["EU","US","FR","UK","DE"]. Use "EU" for all 27 EU member states via TED Europa.
cpv_codesNoEU Common Procurement Vocabulary codes (e.g. ['72000000'] for IT services, ['45000000'] for construction). Optional.
min_value_eurNoMinimum contract value in EUR. Tenders below this are excluded. Optional.
published_afterNoISO date YYYY-MM-DD. Only return tenders published after this date. Defaults to 30 days ago.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes
statusYes
sourcesYes
tendersYes
by_sourceYes
by_countryYes
quality_scoreYes
countries_searchedYes

TDQS

A4.6/5.0
Behavior5/5

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

Discloses beyond annotations: parallel execution, SLA (25s p95), quality scoring system (points per source), status categories (failed/partial/final), optional env var for US. Annotations indicate readOnlyHint=true and no destruction; description adds workflow and success criteria without contradiction.

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 relatively long but efficient, front-loading purpose and use cases. Every sentence adds value, though it could be slightly more structured (e.g., bullet points for sources). No wasted words.

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

Completeness5/5

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

Given the tool's complexity (6 parameters, multiple sources, aggregation logic), the description is very complete. It explains output fields (buyer, CPV, value in EUR, deadlines, URLs), quality scoring, and status mapping. The presence of an output schema (implied by context) offsets the need for further return value details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining default countries, CPV code examples (e.g., IT services), and the effect of published_after defaulting to 30 days ago. It also clarifies that 'EU' covers 27 EU states.

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 aggregates public procurement tenders from multiple government sources, listing specific APIs and standards. It distinguishes itself from sibling tools by focusing on multi-source tender aggregation, which is unique among the listed siblings.

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?

Explicitly states when to use ('B2G agent needs to find government contract opportunities', 'building a pipeline', 'monitoring by CPV code', 'market sizing'). However, it does not explicitly state when NOT to use or mention alternative tools.

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

All mcp-knowledge toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

C2.8/5.0
Disambiguation2/5

Many tools have overlapping purposes, especially in competitive intelligence, ESG, and risk assessment. For example, there are multiple tools for competitor analysis (competitive_deep_dive, competitor_intel, competitor_moves, etc.) with unclear boundaries. Agents would struggle to select the correct tool without deep understanding of subtle differences.

Naming Consistency2/5

Tool names are a mix of English and French, and follow no consistent pattern. Some use snake_case (e.g., abm_architect, action_plan_esg), while others are verb-focused (e.g., content_catalog, fx_rate). The lack of a uniform naming convention makes it hard for agents to predict tool names.

Tool Count1/5

With 271 tools, the server is excessively large. Even for a broad knowledge domain, this number of tools makes discovery and selection inefficient. Typical coherent servers have 3-15 tools; this has an order of magnitude more, indicating poor scoping.

Completeness3/5

The tool set covers many domains (compliance, finance, marketing, HR, etc.), but the coverage is uneven due to redundancy. Key areas have multiple overlapping tools, while some sub-domains may still have gaps. Overall, the surface is broad but not well-curated.

Resources