swiss-procurement-mcp

by malkreide

Overview Schema Source Related Servers Discussions Admin

Python

Remote

search_awards

Read-onlyIdempotent

Search awarded contracts to find who won completed procurement, covering all four award types.

Instructions

Find who won, not what is open — all four award types at once. Use when the question is about completed procurement rather than current opportunities.

Search only awarded contracts (who won).

Convenience wrapper over search_procurements that queries all four award publication types at once.

Two coverage caveats. First, award coverage is uneven across cantons — some publish awards diligently, others rarely, so absence is not proof that no award happened. Second, the filter matches a project's NEWEST publication: a project awarded in May and corrected in June is no longer an "award" to this filter and drops out. Use get_publication_history on a project to see whether an award exists further back.

canton_match works exactly as in search_procurements and defaults to matching the procuring body.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`args`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`note`	No
`count`	Yes
`source`	Yes
`results`	Yes
`has_more`	Yes	True if the pagination cursor can be advanced.
`match_type`	No	exact when results were returned, none when empty.	none
`provenance`	Yes
`next_cursor`	No	Pass as `cursor` to search_procurements for the next page.
`retrieved_at`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.19.0Sep 27, 2026

addedOutput schema / $defs / LotRef

Added value: +{
+  "description": "One lot of a publication, carrying the id `get_publication_history` needs.\n\nUpstream keeps the publication history per lot: a lot publication answers\n`past-publications` only when a `lotId` comes with it. Dropping this list\nfrom the summary left that id unobtainable through this server, so the\nhistory tool could not be called correctly for any lot-based procurement.",
+  "properties": {
+    "lot_id": {
+      "title": "Lot Id",
+      "type": "string"
+    },
+    "lot_number": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "title": "Lot Number"
+    },
+    "lot_title": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "title": "Lot Title"
+    },
+    "pub_type": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "title": "Pub Type"
+    },
+    "publication_id": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "description": "The lot's own publication id, which may differ from the project's.",
+      "title": "Publication Id"
+    }
+  },
+  "required": [
+    "lot_id"
+  ],
+  "title": "LotRef",
+  "type": "object"
+}

addedOutput schema / $defs / ProcurementSummary / properties / lots

Added value: +{
+  "description": "Empty unless lots_type is 'with'. Pass a lot_id from here to get_publication_history, which cannot trace a lot publication without one.",
+  "items": {
+    "$ref": "#/$defs/LotRef"
+  },
+  "title": "Lots",
+  "type": "array"
+}

addedOutput schema / $defs / ProcurementSummary / properties / lots_dropped

Added value: +{
+  "default": 0,
+  "description": "How many lots upstream listed without a lotId, and this server could therefore not carry through. Above 0 the `lots` list is incomplete: those lots exist upstream, but their history is unreachable from here. Treat a non-zero value as missing data, not as fewer lots.",
+  "title": "Lots Dropped",
+  "type": "integer"
+}

addedOutput schema / $defs / ProcurementSummary / properties / lots_type

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "with or without — whether the project is split into lots.",
+  "title": "Lots Type"
+}

First observedv0.18.3Jul 31, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover read-only, idempotent, open-world, and non-destructive behavior, but the description adds important caveats: uneven canton award coverage, absence not proof, and the newest-publication filter that can drop corrected awards. This goes well beyond what annotations provide.

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 a clear use-case summary, then caveats. There is some redundancy between the `<use_case>` tag and the following sentence, and the wrapper sentence repeats 'all four award types', but overall the structure is efficient.

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 a filtered search wrapper with coverage caveats and an existing output schema, the description supplies purpose, routing, and limitations. Nothing essential is missing for correct invocation.

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?

The nested schema already documents canton, cursor, language, canton_match, and date fields thoroughly. The description only cross-references `canton_match` semantics and its default, adding little beyond what the schema provides, so baseline 3 is appropriate.

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 ('Search') and resource ('awarded contracts'), plus scope ('all four award types at once'). Distinguishes from siblings by contrasting completed procurement with current opportunities and naming `search_procurements` as the wrapper base.

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?

Explicitly says to use it when the question is about completed procurement rather than current opportunities, effectively stating when-not. It also names `get_publication_history` as an alternative for checking older awards, and the caveats guide appropriate use.

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

Deploy Server