Skip to main content
Glama

Diavgis — Greek Public Procurement

by gr.diavgis

Greek Public Contracts About to Expire

expiring_contracts
Read-onlyIdempotent

Greek public contracts that are RUNNING NOW and expire within a horizon of 0, 7, 30 or 180 days — the renewal pipeline. Each row carries who currently holds the contract and HOW it was awarded (direct award vs competitive tender, and the number of bids where the source reports it), which is what tells you whether the re-tender is worth chasing. One procurement is counted ONCE: Greek sources publish the duration on the award record as well as the contract, so award records are dropped when a contract in the same lifecycle chain already defines the expiry. ⚠ expiry_basis on every row states how the date was obtained — published (the buyer published an end date), computed_from_start (start date + declared duration) or computed_from_publication (no start date published, so the publication date was substituted; systematically early). Do not present a computed date as a published one. ACCESS: horizon 0 (expiring today) is free on every plan and returns the complete record. Horizons 7/30/180 require a paid plan — lead time is the paid product.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hNohorizon in days; 0 = expiring today (free on every plan). Default 180.
cpvNoCPV division, 2 digits (e.g. 33 for medical equipment)
regionNoNUTS code, e.g. EL30 for Attica
page_sizeNorows to return, 1-200 (default 50)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYes
nextYesnext page NUMBER, or null at the end
pageYes
totalYes
page_sizeYes
horizon_daysNo

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark the operation safe/read-only, and the description adds substantial behavioral detail: deduplication drops award records, expiry_basis explains date provenance, and computed_from_publication is flagged as systematically early. This is exactly the kind of value beyond structured annotations the dimension rewards.

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 longer than average but every sentence earns its place: definition, use-case value, dedup rule, date-provenance warning, and access constraint. It is front-loaded with the core purpose before caveats.

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 an output schema exists, the description covers everything needed to call the tool correctly: valid horizons, row semantics, deduplication, expiry_basis provenance, access requirements, and parameter coverage is already in the schema. No critical gap remains.

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?

Input schema already documents all four parameters with 100% coverage, so the baseline is 3. The description adds meaning beyond the schema by explaining that h=0 is free on all plans while 7/30/180 require a paid plan, and by tying horizon choice to the paid product.

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?

States exact purpose with specific verb/resource: lists Greek public contracts currently running and expiring within 0/7/30/180 days, and contrasts it as the renewal pipeline. This clearly distinguishes it from generic search_tenders or get_entity 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?

Provides strong context for when to use it: paid lead time is the core product, horizon 0 is free, and warns not to present computed dates as published. It does not name alternative sibling tools or explicitly say when not to use them, so it stops short of a 5.

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

All Diavgis — Greek Public Procurement 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

A4.4/5.0
Disambiguation4/5

Each tool targets a distinct concern: entity resolution, entity profiles, counterparties, rankings, spend aggregates, search, act detail, lifecycle chains, expiring contracts, and quota. Minor overlap exists between get_act and get_chain since get_act can include lifecycle chain data, but the descriptions make the intended primary use clear.

Naming Consistency4/5

All names use snake_case and most follow a verb_noun pattern like find_entity, get_entity, search_tenders, and rank_entities. A few tools such as entity_counterparties and expiring_contracts are noun-phrase names, and spend_by_cpv uses a different structure, so the pattern is mostly consistent but not uniform.

Tool Count5/5

Ten tools is well-scoped for a Greek public procurement data API: the count is large enough to cover discovery, search, entity analytics, spend analytics, lifecycle detail, and quota management without feeling bloated. Each tool appears to earn its place with no obvious redundant duplicates.

Completeness5/5

The tool surface covers the full read-only procurement workflow: resolve names to tax IDs, profile entities, find counterparties, rank entities, search tenders with filters, inspect individual acts, follow lifecycle chains, monitor expiring contracts, and aggregate spend by CPV. There are no major missing operations for the stated purpose.

Resources