Skip to main content
Glama
malkreide

swiss-procurement-mcp

by malkreide
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

get_publication_history

Read-onlyIdempotent

Retrieve earlier publications of a procurement project to trace its lifecycle from tender to award. Use when you need to know what happened to a specific procurement.

Instructions

Trace one project through time — tender to award to correction. Use when the question is "what happened to this procurement?".

Return earlier publications of the same procurement project.

Traces a project's lifecycle: tender → correction → award. An empty list is normal for a first publication.

When the publication has lots (lots_type is "with" in the search result), pass lot_id from its lots list: upstream keeps the history per lot and refuses the request without one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
argsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNo
countYes
sourceYes
project_idNo
provenanceYes
publicationsYes
retrieved_atYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.19.0
    • addedInput schema / $defs / HistoryInput / properties / lot_id
      Added value: +{
+  "anyOf": [
+    {
+      "pattern": "^[A-Za-z0-9._-]{1,64}$",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Required when the publication has lots — take `lot_id` from the matching entry in the search result's `lots` list. Upstream history is kept per lot, so a lot publication cannot be traced without it. Leave unset for a publication without lots.",
+  "title": "Lot Id"
+}
  2. First observedv0.18.3

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely useful behavior beyond that: an empty list is a normal result for a first publication, and the upstream service rejects requests for lot-based publications without lot_id.

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 use case, then the core function, then the edge cases. Every sentence carries information; the XML-style <use_case> wrapper is slightly ornamental but costs almost nothing.

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?

An output schema exists, so return structure needn't be explained, and the description still pre-empts the two things an agent could get wrong: interpreting an empty list and omitting lot_id on lot publications. Nothing further is needed to call this correctly.

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?

The included-schema descriptions already document publication_id and language; the prose adds real semantics for lot_id by explaining the failure mode (upstream keeps history per lot and refuses without one) and where to source the value from the search result. Minor gap: language selection is not addressed in the description.

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 states a specific verb and resource — 'Return earlier publications of the same procurement project' — and frames it as a lifecycle trace (tender → correction → award). This clearly distinguishes it from the sibling search_* tools, which find procurements rather than trace one project's history.

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?

It gives an explicit trigger ("Use when the question is 'what happened to this procurement?'") and a conditional rule for when lot_id is required. It does not name an alternative sibling tool or state when not to use it, which keeps it short of a 5.

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

Deploy Server

Other Tools