Prozorro

Prozorro Search Tenders

prozorro_search_tenders

Read-onlyIdempotent

Full-text search over ALL Ukraine ProZorro tenders back to 2015 (keyless). Searches ProZorro's own analyzed index, so Ukrainian queries stem correctly ("школа" also matches "школи", "шкільний") — pass Ukrainian keywords for best recall. Filter by buyer EDRPOU, by SUPPLIER/bidder EDRPOU (tenderer — this is the one for supplier due diligence: every tender a company has bid on or won), CPV code, status, value range, and date. date_from/date_to ALONE (no query/tenderer/buyer/cpv) is also valid and is the only live way to BROWSE historical ProZorro tenders by date — e.g. "what did ProZorro buy in March 2015" — verified live: a bare 10-day 2015 window returns a correctly-dated, narrow result set, not the unfiltered corpus. Returns tenderID, title, value, buyer name + EDRPOU + region, status, and an id field (internal 32-hex id) that is NULL unless resolve_ids is passed — the search index itself never carries it (verified live); prozorro_get_tender with just the tenderID now attempts the same resolution automatically, so you usually don't need resolve_ids here. For an OLD tenderID found this way whose full award/contract detail prozorro_get_tender can't resolve (outside the recently-modified window), use prozorro_historical_release instead.

Input Schema

TableJSON Schema

Name	Required	Description
`cpv`	No	Exact CPV classification code, e.g. "09111100-1".
`page`	No	Page number, 1-500. Fixed 20 results per page.
`buyer`	No	Buyer/procuring-entity EDRPOU code (8 digits).
`order`	No	"desc" (default) or "asc".
`query`	No	Free-text query, Ukrainian recommended (e.g. "вугілля", "школа"). Optional if you pass a filter such as tenderer, buyer, or a date range.
`status`	No	Tender status: complete, active.tendering, cancelled, unsuccessful, …
`date_to`	No	End date YYYY-MM-DD. Same rules as date_from.
`sort_by`	No	"dateCreated" (default) or "value.amount".
`tenderer`	No	Supplier/bidder EDRPOU code (8 digits, e.g. "00131305") — returns every tender this company bid on or won. The primary supplier due-diligence filter.
`date_from`	No	Start date YYYY-MM-DD. Valid ALONE (no other filter) to browse a historical window — e.g. date_from:"2015-03-01", date_to:"2015-03-10". Combined with a keyword/tenderer/buyer query, note it filters on tender PERIOD (or dateSigned for a tenderer query) and so drops any matching record with no tender period.
`resolve_ids`	No	Best-effort: try to fill in each result's `id` (the internal 32-hex id prozorro_get_tender needs for full detail) by scanning the most-recently-modified few thousand ProZorro records. Only finds tenders that were THEMSELVES modified recently — an old, untouched tender will still come back with id:null. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 20, 2026

changedInput schema / examples

Previous value: -[
-  {
-    "query": "комп'ютер"
-  },
-  {
-    "query": "вугілля",
-    "status": "complete"
-  },
-  {
-    "tenderer": "00131305"
-  }
-]New value: +[
+  {
+    "query": "комп'ютер"
+  },
+  {
+    "query": "вугілля",
+    "status": "complete"
+  },
+  {
+    "tenderer": "00131305"
+  },
+  {
+    "date_from": "2015-03-01",
+    "date_to": "2015-03-10"
+  }
+]

changedInput schema / properties / date_from / description

Previous value: -"Start date YYYY-MM-DD. NOTE: date filtering DROPS records that have no tender period — leave both dates off unless you need them."New value: +"Start date YYYY-MM-DD. Valid ALONE (no other filter) to browse a historical window — e.g. date_from:\"2015-03-01\", date_to:\"2015-03-10\". Combined with a keyword/tenderer/buyer query, note it filters on tender PERIOD (or dateSigned for a tenderer query) and so drops any matching record with no tender period."

changedInput schema / properties / date_to / description

Previous value: -"End date YYYY-MM-DD. Same caveat as date_from."New value: +"End date YYYY-MM-DD. Same rules as date_from."

changedInput schema / properties / query / description

Previous value: -"Free-text query, Ukrainian recommended (e.g. \"вугілля\", \"школа\"). Optional if you pass a filter such as tenderer or buyer."New value: +"Free-text query, Ukrainian recommended (e.g. \"вугілля\", \"школа\"). Optional if you pass a filter such as tenderer, buyer, or a date range."

addedInput schema / properties / resolve_ids

Added value: +{
+  "description": "Best-effort: try to fill in each result's `id` (the internal 32-hex id prozorro_get_tender needs for full detail) by scanning the most-recently-modified few thousand ProZorro records. Only finds tenders that were THEMSELVES modified recently — an old, untouched tender will still come back with id:null. Default false.",
+  "type": "boolean"
+}

Changed13 schema fields changedAug 28, 2026

changedInput schema / examples

Previous value: -[
-  {
-    "query": "комп'ютер"
-  },
-  {
-    "query": "школа",
-    "scan": 150
-  }
-]New value: +[
+  {
+    "query": "комп'ютер"
+  },
+  {
+    "query": "вугілля",
+    "status": "complete"
+  },
+  {
+    "tenderer": "00131305"
+  }
+]

addedInput schema / properties / buyer

Added value: +{
+  "description": "Buyer/procuring-entity EDRPOU code (8 digits).",
+  "type": "string"
+}

addedInput schema / properties / cpv

Added value: +{
+  "description": "Exact CPV classification code, e.g. \"09111100-1\".",
+  "type": "string"
+}

addedInput schema / properties / date_from

Added value: +{
+  "description": "Start date YYYY-MM-DD. NOTE: date filtering DROPS records that have no tender period — leave both dates off unless you need them.",
+  "type": "string"
+}

addedInput schema / properties / date_to

Added value: +{
+  "description": "End date YYYY-MM-DD. Same caveat as date_from.",
+  "type": "string"
+}

addedInput schema / properties / order

Added value: +{
+  "description": "\"desc\" (default) or \"asc\".",
+  "type": "string"
+}

addedInput schema / properties / page

Added value: +{
+  "description": "Page number, 1-500. Fixed 20 results per page.",
+  "type": [
+    "number",
+    "string"
+  ]
+}

changedInput schema / properties / query / description

Previous value: -"Keyword(s) to match against title/buyer/tenderID. Ukrainian recommended (e.g. \"комп'ютер\", \"школа\"). Matches by substring."New value: +"Free-text query, Ukrainian recommended (e.g. \"вугілля\", \"школа\"). Optional if you pass a filter such as tenderer or buyer."

removedInput schema / properties / scan

Removed value: -{
-  "description": "How many recent tenders to scan (1-200). Default 100. Higher = deeper but slower.",
-  "type": [
-    "number",
-    "string"
-  ]
-}

addedInput schema / properties / sort_by

Added value: +{
+  "description": "\"dateCreated\" (default) or \"value.amount\".",
+  "type": "string"
+}

addedInput schema / properties / status

Added value: +{
+  "description": "Tender status: complete, active.tendering, cancelled, unsuccessful, …",
+  "type": "string"
+}

addedInput schema / properties / tenderer

Added value: +{
+  "description": "Supplier/bidder EDRPOU code (8 digits, e.g. \"00131305\") — returns every tender this company bid on or won. The primary supplier due-diligence filter.",
+  "type": "string"
+}

removedInput schema / required
```
Removed value: -[
-  "query"
-]
```

Changed1 schema field changedJul 29, 2026

addedInput schema / examples

Added value: +[
+  {
+    "query": "комп'ютер"
+  },
+  {
+    "query": "школа",
+    "scan": 150
+  }
+]

First observedJul 2, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/openWorld, yet the description still adds genuine context: keyless auth, exactly which fields are returned, the fact that `id` is null unless resolve_ids is passed (verified live), and the caveat that resolve_ids only finds recently-modified records. It stops short of pagination/ordering caveats beyond the schema, keeping it at a strong 4 rather than 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?

Front-loaded with the core capability and search-quality tip, and every clause is substantive. It is dense and slightly repetitive around resolve_ids (restated from the schema description), which keeps it just under top marks.

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?

For an 11-parameter, zero-required search tool with no output schema, the description covers return fields, the resolve_ids/id quirk, date-only browsing validity, and escalation paths to sibling tools — nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, but the description adds meaning the schema does not: the Ukrainian stemming behavior and why Ukrainian keywords improve recall, and critically that date_from/date_to filters on tender PERIOD (or dateSigned for tenderer queries) and therefore drops records lacking a period — a non-obvious semantic the schema omits.

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?

Opens with a specific verb+resource ('Full-text search over ALL Ukraine ProZorro tenders back to 2015'), states scope and coverage, and distinguishes itself from siblings by naming prozorro_get_tender and prozorro_historical_release and explaining when each supersedes it.

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?

Explicit when-to-use routing: 'tenderer' is called out as the supplier due-diligence filter, date-only browsing is flagged as the only live way to browse historical tenders, and the old-tenderID fallback to prozorro_historical_release is spelled out. Alternatives are named with the conditions that select them.

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

All Prozorro 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.

Prozorro Search Tenders

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources