Skip to main content
Glama

EU TED Tenders: Public Procurement Notices

eu_ted_tenders
Read-only

Search official EU TED public procurement notices by keyword, CPV code, buyer country, or date, and retrieve notice details, values, deadlines, and HTML/PDF links for bid and research teams.

Instructions

Search official EU TED (Tenders Electronic Daily) public procurement notices through the TED Search API v3, with English title, publication date, buyer country, NUTS, notice and contract type, procedure, estimated or award value when published, tender deadline, CPV codes and TED HTML/PDF links. Unlike federal_contract_finder (US federal awards) and grants_finder (US assistance grants), this covers European public tenders. Use when BD or capture teams, EU suppliers or researchers need tenders by keyword, CPV code or buyer country. Do not use to submit bids, for US opportunities or for national portals outside TED. Parameters: daysBack (default 7) or publishedFrom/To set the window; keywords and cpvCodes (e.g. 72000000 IT services) match the notice; countries takes ISO-3 buyer codes such as DEU or FRA; maxResults caps billed notices. Value is often missing because many notices omit it. Empty input runs a small IT-services demo. Runs with no matches are free. Returns per item: agentSummary, noticeId, title, publicationDate, countries, nuts, noticeType, contractType, procedure, estimatedValue, deadline, CPV codes, noticeUrl, pdfUrl, htmlUrl; plus TED_XLSX/CSV.

Behavior: read-only; runs the Apify Actor pandadad0214/eu-ted-tenders (https://apify.com/pandadad0214/eu-ted-tenders) on your own Apify account. Price: $0.002 per notice returned. Runs that find nothing are not charged per result, and spending is capped per call by run_max_charge_usd (default $0.50). run_max_items (default 50) limits items returned and fills maxResults when you leave it unset, so it also limits what is billed; setting maxResults higher can bill more than is returned. Most calls finish in 5-15 s for a few inputs; large inputs or crawls can take minutes, so raise run_timeout_secs (max 300) or shrink the input after a timeout error. Returns JSON {actor, count, items}; long text output is trimmed to whole items, with all items in structuredContent.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "eu_ted_tenders"
  }
}

Input Schema

NameRequiredDescriptionDefault
cpvCodesNoCPV codes. Common Procurement Vocabulary codes, e.g. 72000000 (IT services), 45000000 (construction), 33000000 (medical). Several codes are OR'd.
daysBackNoPublished in the last N days. Default 7. Searches publication-date >= today minus (N-1) days (UTC). Use 1 on a daily schedule. Ignored when Published from / Published to are set.
keywordsNoKeywords. Full-text search. Each keyword becomes FT ~ "..." and they are joined with AND. Quotes are stripped. Example: software, cloud.
countriesNoBuyer countries. ISO-3 country codes, e.g. DEU, FRA, ITA, ESP, POL, NLD, BEL, IRL, SWE. Two-letter codes (DE, FR, IT) are converted. Filtered server-side with buyer-country.
maxResultsNoMaximum results. You pay per notice returned, so this also caps the cost. Default 200; hard max 2000.
publishedToNoPublished to. Optional YYYY-MM-DD.
publishedFromNoPublished from. Optional YYYY-MM-DD. Overrides days back for the start of the window.
run_max_itemsNoOptional. Most results to return from this call (default from PANDA_MAX_ITEMS, 50). Also limits how many results the Actor produces and charges for, unless you set its own max field.
run_timeout_secsNoOptional. Seconds to wait for results (default from PANDA_TIMEOUT_SECS, 120; max 300).
run_max_charge_usdNoOptional. Hard spending cap for this call in USD (default from PANDA_MAX_CHARGE_USD, 0.50).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations cover read-only/open-world/non-idempotent, and the description still adds substantial non-redundant behavior: $0.002 per notice, free on zero-match runs, run_max_charge_usd cap of $0.50 default, 5-15 s typical vs minutes on large inputs, and 300 s timeout ceiling. The only notable omission is rate limits or failure modes beyond timeouts, which keeps it off a 5.

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?

Purpose and sibling disambiguation are front-loaded, and the 'Parameters:' block is dense with genuinely useful caveats rather than filler. It does, however, restate schema facts already at 100% coverage (daysBack default 7, ISO-3 codes, CPV examples), so a few lines are redundant.

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?

With no output schema, the description enumerates the returned per-item fields (noticeId, title, deadline, CPV, noticeUrl/pdfUrl/htmlUrl, TED_XLSX/CSV) and the top-level {actor, count, items} envelope, plus cost, timing, and empty-result behavior. Nothing material for a correct call is left out.

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 the baseline is 3; the description still earns credit by explaining interactions the schema states only in isolation, notably that run_max_items fills maxResults when unset and that setting maxResults higher can bill more than is returned. It also flags that value is often missing and that empty input triggers a small demo run, neither of which is in the schema.

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 ('Search official EU TED public procurement notices through the TED Search API v3') plus the field set returned, and explicitly names the two siblings it is not (federal_contract_finder, grants_finder) with the distinguishing axis: European vs US.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives both when-to-use ('BD or capture teams, EU suppliers or researchers need tenders by keyword, CPV code or buyer country') and when-not ('Do not use to submit bids, for US opportunities or for national portals outside TED'), which is about as explicit as routing guidance gets.

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