Skip to main content
Glama

Distil — Machine-Native Public Data Refinery

Get Tender Pricing Intelligence

get_tender_intelligence
Read-onlyIdempotent

Computes statistical pricing intelligence, winning bidder concentration, and recommended RFP bid discount windows across public procurement tenders in Spain (PLACSP) and the European Union (TED) (< 1.5 KB). Accepts a tender notice ID (e.g. '2026-OJS-FR-CYBERSEC-001', '2024/00123'), a CPV code (e.g. '72000000', '30200000'), or a sector keyword query (e.g. 'cybersecurity', 'cloud infrastructure', 'limpieza'). Returns average/median budgets, winning contractor market shares, historical discount rates, and benchmark reference contracts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNoSearch keyword, sector name, or project title (e.g. 'cybersecurity', 'cloud', 'limpieza', 'software').
countryNoTwo-letter country code filter for EU tenders (e.g. 'FR', 'DE', 'ES', 'IT', 'NL').
cpvCodeNoCommon Procurement Vocabulary code prefix (e.g. '72000000', '30200000') OR tender notice ID.
noticeIdNoAlias for tenderId (e.g. '2026-OJS-FR-CYBERSEC-001').
tenderIdNoSpecific tender identifier or EU TED notice ID (e.g. '2026-OJS-FR-CYBERSEC-001', '2024/00123') to benchmark against its sector.
authorityNoContracting public authority name filter (e.g. 'Ministerio de Hacienda', 'ENISA').
forceFreshNoSpend Control: When true, bypasses Edge KV cache and forces a real-time statutory primary registry call (applies 2.5x Freshness Inconvenience Surcharge). Default: false.
maxAgeHoursNoSpend Control: Maximum acceptable data age in hours (e.g. 48 for 2 days tolerance). If cache satisfies this, delivers sub-5ms at standard 1.0x Economy rate. Set to 0 to force live primary fetch.
contractTypeNoContract type classification filter (e.g. 'SERVICES', 'SUMINISTROS', 'SERVICIOS', 'WORKS').
jurisdictionNoJurisdiction scope: 'ALL' (default, covers EU TED + Spain PLACSP), 'ES' (Spain), 'EU' (European Union TED), or country code ('FR', 'DE', 'ES', etc.).ALL

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
contentYes
isErrorNo

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about the data sources (PLACSP and TED), the scope (Spain/EU), and the computed nature of outputs, which goes beyond the safety profile. It does not disclose failure modes or caching behavior, but the bar is lowered by 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused paragraph with no redundant sentences. It front-loads the core purpose, then lists accepted inputs and outputs efficiently. The mention of '< 1.5 KB' is a minor oddity but does not detract from clarity.

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

Completeness3/5

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

The tool has 10 optional parameters, and the description does not explain parameter precedence or how they combine (e.g., if both tenderId and query are provided). While output schema exists, the interaction logic is missing. For a complex tool, this gap could lead to incorrect invocation. However, the schema descriptions and examples partially compensate.

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 descriptions cover all 10 parameters (100% coverage), so the schema already explains each parameter. The description merely reiterates that the tool accepts tender ID, CPV code, or keyword, but adds no new semantic detail about parameter usage, interactions, or valid formats beyond the schema. Baseline 3 is warranted.

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 states a specific verb ('Computes'), a clear resource ('statistical pricing intelligence ... across public procurement tenders in Spain (PLACSP) and the European Union (TED)'), and explicit output types ('average/median budgets, winning contractor market shares, historical discount rates, and benchmark reference contracts'). This distinguishes it from sibling retrieval tools like get_es_public_tender or search_eu_tenders, which focus on single tenders or search results.

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 clarifies that the tool accepts a tender ID, CPV code, or sector keyword, implying its analytical use case. However, it does not explicitly state when to prefer this over alternatives (e.g., 'Use this instead of get_eu_public_tender when you need pricing intelligence'). The context is clear but lacks direct exclusions or alternative routing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation5/5

Each tool maps to a distinct data product: country-specific filings, tender records/search, risk scoring, sanctions screening, and entity graphs. The search/get split cleanly separates discovery from retrieval, and even similar country-specific tools are clearly qualified by region and entity type.

Naming Consistency5/5

All tools use a consistent snake_case verb_noun pattern: get_* for retrieval and search_* for discovery, with country or region qualifiers where applicable. Cross-cutting tools like get_corporate_risk_score and get_tender_intelligence fit the same pattern without feeling out of place.

Tool Count4/5

At 16 tools, the server is slightly above the ideal 3-15 range, but the multi-country, multi-domain scope justifies nearly every tool. The set is heavier than a tightly focused server, yet no tool feels redundant.

Completeness4/5

The set covers the core read-only workflow well: search to find entities or tenders, get to retrieve records, plus analytical tools for risk, sanctions, and tender intelligence. Minor gaps exist, such as no Spanish company registry access and no UK tender search, but these are workable and do not block primary due-diligence workflows.

Resources