Skip to main content
Glama

ris-austria-mcp-server

by io.github.cyanheads

Search Draft Legislation

ris_search_drafts
Read-onlyIdempotent

Search Austria’s federal lawmaking pipeline BEFORE promulgation — the monitoring counterpart to ris_search_gazette (what will become law). stage selects the phase: review_drafts (Begutachtungsentwürfe — draft laws a ministry has put into public review, before any government bill exists) or government_bills (Regierungsvorlagen — bills the council of ministers adopted and submitted to parliament, 2004+). Filter by query (full text), title, ministry (accepts an abbreviation like "BMF" — expanded to RIS’s exact designation; the historical name at submission time counts), in_review_on (review_drafts only — drafts whose review window covers the date; today = "what is in Begutachtung right now"), or decided_from/to (government_bills only — council adoption date). changed_since gives coarse recency. Each record carries materials — the companion documents filed with the draft (Erläuterungen, Textgegenüberstellung, Vorblatt/WFA, covering letter, annexes); the Erläuterungen carry the drafting reasoning the bill text omits, and passing a materials[].url to ris_get_document as document_url is the only way to read one (format there picks the rendition returned). Documents are preparatory, not binding law. Ministry codes: ris_list_reference topic ministries.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo1-based result page. Default 1.
queryNoFull-text search (Suchworte). Boolean operators UND/ODER/NICHT or AND/OR/NOT, parentheses, quoted phrases; wildcard * is trailing-only.
stageYesWhich pipeline stage to search — one per call. review_drafts (Begut, ministerial review) or government_bills (RegV, council-adopted bills). Details: ris_list_reference topic stages.
titleNoTitle search (Titel) — phrase field: * allowed leading or trailing with ≥2 characters beside it.
sort_byNoSort column: date (review deadline or adoption date per stage), ministry, or title. Default: upstream order.
ministryNoSubmitting ministry (EinbringendeStelle). Accepts an abbreviation ("BMF") — expanded to RIS’s exact-match designation; use the ministry’s name at the time of submission. Table: ris_list_reference topic ministries.
page_sizeNoDocuments per page — RIS accepts 10, 20, 50, or 100. Default 20.
decided_toNogovernment_bills only. Latest adoption date (YYYY-MM-DD).
decided_fromNogovernment_bills only. Earliest council-of-ministers adoption date (YYYY-MM-DD).
in_review_onNoreview_drafts only. Drafts whose public-review window covers this date (YYYY-MM-DD). Today = drafts currently in Begutachtung.
changed_sinceNoCoarse recency filter — documents changed in RIS within the interval. For exact windows use ris_track_changes.
sort_directionNoSort direction; applies with sort_by.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo1-based page number RIS served.
errorNoPresent when the call failed. Absent on success.
noticeNoZero-hit guidance — names the likely cause and the concrete next call.
resultsNoMatching pipeline documents for the requested page. Totals and paging in enrichment.
pageSizeNoPage size RIS applied.
truncatedNoPresent and true when more pages exist beyond this one — raise page to continue.
totalCountNoTotal matching documents across all pages.

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is known. The description adds meaningful behavioral context: documents are preparatory and not binding law, and the only way to read materials is via ris_get_document with a materials[].url. This goes beyond the annotations by explaining the non-binding nature and the complementary document retrieval path.

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 longer than typical but appropriately dense for the tool's complexity. It front-loads the core purpose and then efficiently covers stage semantics, filters, and materials without redundancy. Every sentence adds value, though a slight trim of repetitive 'only' qualifications could tighten it further.

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?

Given the 12 parameters, two stages with distinct filters, and the materials concept, the description covers all operational facets an agent needs: stage selection, filter semantics, ministry handling, recency options, and the document retrieval method. It also points to reference data for ministries and stages, and the output schema (per signals) presumably handles return-structure details. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already describes all 12 parameters (100% coverage), but the description enriches them substantially: it expands stage into detailed explanations of both phases, clarifies that ministry abbreviations are expanded to historical designations, explains that in_review_on means 'today = what is in Begutachtung right now', and notes that decided_from/to are council adoption dates. It also defines what materials are and their significance, which the schema does not.

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 clearly states the tool searches Austria's federal lawmaking pipeline before promulgation, and names it as the monitoring counterpart to ris_search_gazette. It distinguishes the two stages (review_drafts and government_bills) with German terms, making the purpose unambiguous and differentiating it from sibling tools.

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 explicitly explains when to use this tool (pre-promulgation monitoring) versus ris_search_gazette (what will become law). It also directs users to ris_list_reference for ministry codes and stages, and to ris_track_changes for exact recency windows. Stage-specific filters (in_review_on vs decided_from/to) are clearly scoped, leaving no ambiguity about when to use which.

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

All ris-austria-mcp-server 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.

TDQS

A4.8/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: fetching documents, resolving citations, searching different content domains (legislation, case law, gazette, drafts, announcements), listing reference data, and tracking changes. No two tools overlap in function or could be confused for the same task.

Naming Consistency5/5

All tools follow a uniform ris_[verb]_[noun] snake_case pattern, using verbs like get, list, lookup, search, and track. The naming convention is entirely predictable and consistent across the server.

Tool Count5/5

With 9 tools, the server is well-scoped for its purpose of Austrian legal information retrieval. Each tool serves a distinct and necessary function, with no redundancy or unnecessary bloat.

Completeness5/5

The tool set covers the full lifecycle of legal research: reference lookup, citation resolution, five content-type searches, document retrieval with format control, and delta tracking for mirrors. There are no obvious gaps—every action an agent might need is available.

Resources