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). 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

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

TableJSON 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.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 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.