Skip to main content
Glama

Overfit — German tenders & procurement law

Ausschreibung komplett mit Unterlagen

vergabe_bekanntmachung_voll
Read-onlyIdempotent

Complete record of one tender: all fields of vergabe_bekanntmachung plus the AI-structured sections (description, criteria, …), a Q&A list (e.g. 'Is a security clearance required?'), topic facets, and a list of available procurement documents (filenames, sizes, MIME types, download status). Field guide: assistant_ready = true means the procurement documents are downloaded and analysed, so sections (AI-structured summary), qa and eligibility_summary are filled; when false these stay empty and the notice fields and summaries are what is available. documents[].download_status: ok = file stored at Overfit, pending = not fetched yet, failed/skipped = could not be fetched. The files themselves are not returned; they are available via the notice's portal link (procedure_room_url or detail_url). Input: the numeric notice_id (not the string uid 'source:id' of vergabe_bekanntmachung). Every Vergabe result carries both: field 'notice_id' in vergabe_suche and vergabe_bekanntmachung results, field 'id' in vergabe_liste results. Rate-limited at 30 requests/10 min and 200/day per IP (same bucket as notice detail).

Example user questions: "Welche Unterlagen gibt es für diese Ausschreibung?"; "Gibt es eine strukturierte Zusammenfassung der Vergabeunterlagen?"; "Welche Fragen und Antworten sind zu dieser Ausschreibung bekannt?"

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
notice_idYesNumeric notice ID (not the string uid): field 'notice_id' in vergabe_suche / vergabe_bekanntmachung results, field 'id' in vergabe_liste results.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • removedInput schema / properties / id
      Removed value: -{
      -  "description": "Numeric notice ID (not the string uid): field 'notice_id' in vergabe_suche / vergabe_bekanntmachung results, field 'id' in vergabe_liste results.",
      -  "examples": [
      -    171884
      -  ],
      -  "type": "integer"
      -}
    • addedInput schema / properties / notice_id
      Added value: +{
      +  "description": "Numeric notice ID (not the string uid): field 'notice_id' in vergabe_suche / vergabe_bekanntmachung results, field 'id' in vergabe_liste results.",
      +  "examples": [
      +    171884
      +  ],
      +  "type": "integer"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "id"
      -]New value: +[
      +  "notice_id"
      +]
  2. Changed1 schema field changed
    • changedInput schema / properties / id / description
      Previous value: -"Numeric notice ID from the 'notice_id' or 'id' field in /api/search or /api/list responses."New value: +"Numeric notice ID (not the string uid): field 'notice_id' in vergabe_suche / vergabe_bekanntmachung results, field 'id' in vergabe_liste results."
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Far exceeds the annotations (which only cover read-only/idempotent safety): it explains the assistant_ready gating semantics, the download_status enum meanings (ok/pending/failed/skipped), that the files themselves are NOT returned but reachable via procedure_room_url/detail_url, and concrete rate limits (30/10 min, 200/day). This is unusually rich behavioral disclosure.

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 purpose, then a compact field guide and example queries; every block earns its place. It is dense and somewhat long, with a little duplication between the body and the schema property text, but nothing is wasted filler.

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?

No output schema exists, so the description must carry the return-shape burden, and it does: it names the field groups, the flag that gates them, the status vocabulary, and what is deliberately omitted (the files). An agent has everything needed to call and interpret this tool.

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% and the single parameter is self-documenting, but the description still adds cross-tool context by mapping where notice_id comes from across vergabe_suche, vergabe_bekanntmachung and vergabe_liste (field 'notice_id' vs field 'id'), reducing a common source of invocation error.

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+resource: 'Complete record of one tender' and enumerates exactly what it returns (all vergabe_bekanntmachung fields, AI-structured sections, Q&A list, facets, documents). It is clearly differentiated from the sibling vergabe_bekanntmachung, which it explicitly builds on.

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?

Provides real decision context: the `assistant_ready` flag tells the agent when AI sections are populated vs empty, and it warns that the input is the numeric notice_id, not the string uid used by vergabe_bekanntmachung. It stops short of an explicit 'use this instead of X when…' rule, but the German example questions anchor the intended use cases.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources