Skip to main content
Glama

Prozorro

by io.github.pipeworx-io
OverviewAdmin

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. Returns tenderID, title, value, buyer name + EDRPOU + region, and status, plus a total match count. Use prozorro_get_tender for the full detail of one result.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cpvNoExact CPV classification code, e.g. "09111100-1".
pageNoPage number, 1-500. Fixed 20 results per page.
buyerNoBuyer/procuring-entity EDRPOU code (8 digits).
orderNo"desc" (default) or "asc".
queryNoFree-text query, Ukrainian recommended (e.g. "вугілля", "школа"). Optional if you pass a filter such as tenderer or buyer.
statusNoTender status: complete, active.tendering, cancelled, unsuccessful, …
date_toNoEnd date YYYY-MM-DD. Same caveat as date_from.
sort_byNo"dateCreated" (default) or "value.amount".
tendererNoSupplier/bidder EDRPOU code (8 digits, e.g. "00131305") — returns every tender this company bid on or won. The primary supplier due-diligence filter.
date_fromNoStart date YYYY-MM-DD. NOTE: date filtering DROPS records that have no tender period — leave both dates off unless you need them.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed13 schema fields changed
    • 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"
-]
  2. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "query": "комп'ютер"
+  },
+  {
+    "query": "школа",
+    "scan": 150
+  }
+]
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral context beyond that: it explains that the search uses ProZorro's own analyzed index with stemming, mentions the date-filtering caveat that 'DROPS records that have no tender period,' and discloses fixed 20-results-per-page pagination. It also notes that Ukrainian queries stem correctly, which is a behavioral nuance. No contradiction with annotations.

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 description is concise relative to the tool's complexity. It front-loads the core purpose and then methodically lists filters and return fields. Every sentence provides distinct information: scope, stemming behavior, filter options, return fields, and a pointer to the sibling. No filler, but it is fairly long; considering the 10 parameters and the need to explain caveats, the length is justified. It earns a 4 because it is efficiently structured, though slightly dense.

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?

The tool is complex with 10 optional parameters and no output schema, so the description must carry the burden of explaining what to expect. It covers the return fields (tenderID, title, value, buyer name + EDRPOU + region, status, total match count), the keyless nature, pagination (fixed 20 per page, page 1-500), and critical caveats (date filtering dropping records). It also routes to the sibling for full detail. Combined with the rich annotations, the description is complete for an agent to invoke the tool correctly without additional clarification.

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 description coverage is 100%, so every parameter is already documented. The description adds extra meaning: it highlights that the 'tenderer' parameter is the primary supplier due-diligence filter, clarifies that 'query' is optional when a filter is provided, and explains the date filtering caveat. This goes beyond the schema's basic descriptions, adding nuance that helps the agent select parameters correctly. Not a 5 because the schema already covers basic semantics, but the added context is valuable.

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 opens with a precise statement: 'Full-text search over ALL Ukraine ProZorro tenders back to 2015 (keyless).' It names the specific verb (search), the resource (ALL ProZorro tenders), and the scope (back to 2015). It also distinguishes itself from the sibling prozorro_get_tender by explicitly stating that the sibling should be used for full detail, making the purpose unambiguous.

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?

The description gives clear context on when to use the tool (full-text search, filtering by various criteria) and explicitly redirects to a sibling: 'Use prozorro_get_tender for the full detail of one result.' It also emphasizes the tenderer filter for supplier due diligence, guiding the agent on when to choose this search over others. While it doesn't list exhaustive 'when-not' conditions, the explicit alternative and the context of its keyless search versus the sibling's detail retrieval sufficiently guide usage.

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

All Prozorro toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources