Skip to main content
Glama
Sign In
parlament-at

parlament-at

by bernhardbrugger
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Parlamentarische Anfragen und Anfragebeantwortungen suchen

parl_anfragen
Read-onlyIdempotent

Search written parliamentary inquiries and answers in Austria’s Nationalrat or Bundesrat by legislative period, type, and subject keyword; results are newest first with status and links.

Instructions

Sucht schriftliche parlamentarische Anfragen und deren Beantwortungen im Nationalrat oder Bundesrat, neueste zuerst. Filter: Gesetzgebungsperiode (gp, z. B. "XXVIII" oder 28), Art (Anfrage oder Beantwortung, getrennt abgefragt) und Suchbegriff (im Betreff). Die Liste enthält Nummer, Datum, Betreff, Status und Link, aber NICHT, wer die Anfrage gestellt hat; das (Partei, Ministerium) liefert parl_gegenstand zur jeweiligen Nummer. Ohne gp ist die Trefferzahl auf rund 20.000 begrenzt. Quelle: offene Daten des Parlaments (CC BY 4.0).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "parl_anfragen"
  }
}

Input Schema

NameRequiredDescriptionDefault
gpNoGesetzgebungsperiode: 28 oder "XXVIII"
artNoAnfragen oder Anfragebeantwortungen (nicht beides in einer Abfrage)anfrage
limitNoAnzahl Treffer pro Aufruf
sucheNoSuchbegriff, z. B. "Budget" oder "Polizeischutz"
offsetNoTreffer überspringen (Seiten)
gremiumNoNR = Nationalrat, BR = BundesratNR
kompaktNoEine Zeile pro Treffer (Betreff gekürzt, Link bleibt) statt eines Blocks; spart Kontext bei langen Listen

Output Schema

NameRequiredDescriptionDefault
itemsYes
totalYesTotal number of hits reported by the Parliament (may be a lower bound, see the text)
offsetYesIndex of the first returned item

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.1

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover readOnly/openWorld/idempotent, but the description adds substantial behavior: newest-first ordering, the exact fields returned (Nummer, Datum, Betreff, Status, Link), the notable field that is NOT returned (who filed the query), the ~20,000 hit cap without gp, and the data source/license. That is exactly the kind of context an agent cannot infer from the schema.

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 and ordering, then filters, then output caveats and source. Dense but every clause carries information; the semicolon-chained layout makes it slightly harder to scan than a fully structured version.

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 7-parameter, zero-required search tool with an output schema and annotations, the description supplies the missing pieces an agent needs: the separate-query constraint on art, the gp cap, and the follow-up call to parl_gegenstand for submitter data. Nothing essential is absent.

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%, so baseline is 3; the description goes beyond it by clarifying that gp accepts "XXVIII" or 28 and — importantly — that suche matches only the Betreff, which the schema does not say. limit, offset, gremium and kompakt are left entirely to the schema.

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 ("Sucht") plus the exact resource (schriftliche parlamentarische Anfragen und deren Beantwortungen) and the two chambers, with ordering ("neueste zuerst"). It also implicitly separates itself from parlamentary siblings by naming parl_gegenstand as the place to resolve the missing (Partei, Ministerium) field.

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?

Gives concrete usage constraints: art must be queried separately ("nicht beides in einer Abfrage"), and without gp the result set is capped at ~20,000. It also routes the agent to parl_gegenstand for the missing submitter info. It stops short of an explicit statement of when to prefer parl_suche or parl_gegenstaende instead, so not a full 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