Skip to main content
Glama

Open data: clinical trials, EU tenders, companies, fuel prices

by org.duckdns.gregswarm.api
OverviewDiscussionsAdmin

EU Public Tender Monitor (TED)

ted-tender-monitor
Read-onlyIdempotent

New public procurement notices from the EU's official TED search API for a CPV code prefix, buyer country and keyword, returning only the notices that are new or changed since your last run. Read from api.ted.europa.eu when called. Each result: notice_id, publication_date, buyer, country_code, title, cpv_codes, procedure, deadline, estimated_value, currency, url. Needs a RapidAPI key for this API (https://rapidapi.com/IanGregory/api/clinical-trials-eu-tenders-open-data-api), sent as the X-RapidAPI-Key header; the free plan has 50 requests a month.

Input Schema

NameRequiredDescriptionDefault
limitNoAt most this many results (default 100).
countryNoCountry of the buying organisation, as a three-letter ISO code. Example: "FRA".
keywordNoOptional word that the notice title must contain. Leave empty to keep all notices. Example: "services".
cpv_prefixNoStart of the CPV code to follow (for example 72 for IT services, 45 for construction, 33 for medical equipment). Example: "72".
published_sinceNoOnly notices published on or after this date, written YYYYMMDD. Example: "20250101".

Output Schema

NameRequiredDescriptionDefault
countYeshow many results came back
itemsYesthe results, one object each
partialNosome of the source's requests failed: the results are incomplete
productNo
sourcesNowhere the data came from: each source's name, licence and the attribution to show with it
fetched_atNowhen the source was read (Unix seconds)
truncated_fromNothe answer was cut to fit: this many results came back in all

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / sources
      Added value: +{
+  "description": "where the data came from: each source's name, licence and the attribution to show with it",
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "count": {
+      "description": "how many results came back",
+      "type": "integer"
+    },
+    "fetched_at": {
+      "description": "when the source was read (Unix seconds)",
+      "type": "integer"
+    },
+    "items": {
+      "description": "the results, one object each",
+      "items": {
+        "properties": {
+          "buyer": {
+            "description": "buyer (text)"
+          },
+          "country_code": {
+            "description": "country_code (text)"
+          },
+          "cpv_codes": {
+            "description": "cpv_codes (list)"
+          },
+          "currency": {
+            "description": "currency (text)"
+          },
+          "deadline": {
+            "description": "deadline (date)"
+          },
+          "estimated_value": {
+            "description": "estimated_value (number)"
+          },
+          "notice_id": {
+            "description": "notice_id (id)"
+          },
+          "procedure": {
+            "description": "procedure (text)"
+          },
+          "publication_date": {
+            "description": "publication_date (date)"
+          },
+          "title": {
+            "description": "title (text)"
+          },
+          "url": {
+            "description": "url (url)"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "partial": {
+      "description": "some of the source's requests failed: the results are incomplete",
+      "type": "boolean"
+    },
+    "product": {
+      "type": "string"
+    },
+    "truncated_from": {
+      "description": "the answer was cut to fit: this many results came back in all",
+      "type": "integer"
+    }
+  },
+  "required": [
+    "count",
+    "items"
+  ],
+  "type": "object"
+}
  3. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the bar is lower, yet the description adds materially: it reads from api.ted.europa.eu at call time, requires a RapidAPI key sent as the X-RapidAPI-Key header, and discloses the free-plan limit of 50 requests per month. The delta-return semantics ('new or changed since your last run') is also behavioral context not expressed by any annotation. Minor tension with idempotentHint=true is arguable but not a contradiction, since this is a read-only query over changing data.

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 lead sentence is front-loaded with purpose, filters, and delta behavior; the auth and rate-limit facts follow in their own sentence. The enumerated result fields are the only borderline padding given a separate output schema exists, but they are compact and readable in one clause.

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

Completeness4/5

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

With an output schema present, the description needn't explain returns, yet it also covers endpoint, auth, and quota — a lot for a single-tool definition. The remaining gap is statefulness: how 'last run' is tracked and what a first call returns is unstated, which matters for a zero-required-parameter tool.

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 description coverage is 100%, with every parameter documented including the CPV prefix examples and country enum, so the schema does the heavy lifting. The description restates the filter concepts but adds no syntax, default, or interaction detail beyond what the schema already provides, so the baseline 3 applies.

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 a specific verb and resource ('new public procurement notices from the EU's official TED search API') plus the three filter dimensions (CPV prefix, buyer country, keyword) and the delta scope ('only the notices that are new or changed since your last run'). An agent can distinguish it from siblings like clinical-trials-monitor or eu-fuel-monitor purely on domain without opening any schema.

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?

Usage context is clear: it is a monitoring tool that returns deltas since the last run, with the keyword filter explicitly optional ('leave empty to keep all notices'). However, there is no explicit when-not guidance and no statement of what happens on a first run with no prior state, which is the one decision point an agent actually faces.

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

All Open data: clinical trials, EU tenders, companies, fuel prices toolsInspect
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.

Resources