Diavgis — Greek Public Procurement

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). A computed date is an estimate, not a published date. 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

Name	Required	Description
`h`	No	horizon in days; 0 = expiring today (free on every plan). Default 180.
`cpv`	No	CPV division, 2 digits (e.g. 33 for medical equipment)
`region`	No	NUTS code, e.g. EL30 for Attica
`page_size`	No	rows to return, 1-200 (default 50)

Output Schema

Name	Required	Description
`data`	Yes
`next`	Yes	next page NUMBER, or null at the end
`page`	Yes
`total`	Yes
`page_size`	Yes
`horizon_days`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedAug 29, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "data": {
+      "items": {
+        "properties": {
+          "amount_net": {
+            "description": "EUR, excludes VAT",
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "buyer_afm": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "buyer_name": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "contract_end": {
+            "description": "ISO date the contract stops running",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "cpv_primary": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "id": {
+            "type": "string"
+          },
+          "nuts": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "source": {
+            "type": "string"
+          },
+          "source_url": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "supplier_afm": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "title": {
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "required": [
+          "id",
+          "source"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "horizon_days": {
+      "type": "number"
+    },
+    "next": {
+      "description": "next page NUMBER, or null at the end",
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "page": {
+      "type": "number"
+    },
+    "page_size": {
+      "type": "number"
+    },
+    "total": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "data",
+    "page",
+    "page_size",
+    "total",
+    "next"
+  ],
+  "type": "object"
+}

First observedAug 14, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond annotations, it discloses non-obvious behavior: one procurement is counted once via lifecycle-chain deduplication, and every row's expiry_basis explains how the date was derived, with an explicit warning that computed_from_publication is systematically early and is an estimate, not a published date. It also discloses the plan/paywall boundary. That is exactly the kind of context annotations cannot carry.

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 purpose and the key caveat are front-loaded, and the ACCESS clause is clearly delineated in caps. It is on the dense side — the middle sentence about duration being published on award records is a long way to say 'de-duplicated' — but no sentence is superfluous.

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?

Output schema exists, so return values need no explanation, and the description still covers what an agent actually needs: which horizons are free, what expiry_basis means for data trustworthiness, and how rows are de-duplicated. Nothing material is missing for correct invocation.

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 real value on the h parameter by tying horizon values to expansion ('expiring today') and to the paywall, plus the warning that any horizon above 0 is a paid feature. cpv and region are left entirely to the schema, so it isn't a full 5.

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-plus-resource with scope: Greek public contracts running now that expire within a 0/7/30/180-day horizon, framed as a 'renewal pipeline'. It also gives the distinguishing content (incumbent holder, award procedure, bid count), which separates it from generic sibling searches like search_tenders or spend_by_cpv.

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?

It implies the use case clearly (renewal chasing) and gives concrete plan-based guidance: horizon 0 is free and complete, while 7/30/180 require a paid plan, so an agent knows which horizon values it can actually call. It does not explicitly name sibling alternatives or exclusions (e.g., 'use search_tenders for historical awards'), which keeps it below 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 tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.