ris-austria-mcp-server
Server Details
Search Austrian federal and state law, court decisions, and the authentic Bundesgesetzblatt (RIS).
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 9 of 9 tools scored.
Each tool has a clearly distinct purpose: fetching documents, resolving citations, searching different legal sources, accessing reference data, and tracking changes. No overlaps.
All tool names follow the consistent pattern 'ris_<verb>_<noun>', making them predictable and easy to remember.
Nine tools is appropriate for covering the complex domain of Austrian legal information without being overwhelming or insufficient.
The set covers searching all major legal document types, fetching full text, citation resolution, reference data, and change tracking, leaving no obvious gaps for core tasks.
Available Tools
9 toolsris_get_documentGet RIS DocumentARead-onlyIdempotentInspect
Fetch one RIS document’s full text or its rendition URLs, with explicit binding status and the amtssigniert authentic PDF surfaced wherever it exists. Address the document exactly one of two ways: document_number plus application (both copied verbatim from a ris_search_* or ris_lookup_citation result), or a document_url from a result’s content_urls. format: markdown (default — the HTML rendition converted to markdown), html (raw HTML rendition), xml (the RIS Nutzdaten XML), or urls_only (no fetch — every rendition URL, including the Authentisch PDF). Format availability varies by application and the tool degrades explicitly, never silently: consolidated law, gazettes, case law, drafts, and most sectoral collections carry full text; district and municipal promulgations and court rules (Bvb, GrA, KmGer) publish only the signed authentic PDF; party-transparency decisions and council minutes (Upts, Mrp) are PDF-only; the 1848–1940 imperial gazettes (BgblAlt) are metadata-only — for these a text-format request returns a format_unavailable notice with the usable URL, not an error. Every result carries binding_status; only authentic (amtssigniert) publications are legally binding. This tool returns content, not fresh metadata — the metadata rides the search/lookup step that produced the document number. When the markdown text overflows the byte budget the tool returns a §/Artikel/Anlage section outline (kind: outline) instead of truncating; re-call with sections:[…] naming outline entries to retrieve just those. Raw html/xml renditions, which carry no such headings, return in full.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | markdown (default — the HTML rendition converted to markdown), html (raw HTML rendition), xml (RIS Nutzdaten schema), or urls_only (no fetch — all rendition URLs incl. the authentic PDF). | markdown |
| sections | No | Section names to retrieve, each copied verbatim from a prior outline response (kind: outline). Omit for the full document — which returns a §/Artikel/Anlage outline instead when the markdown overflows the byte budget. Applies to text formats; ignored for urls_only. | |
| application | No | RIS application the document belongs to (e.g. BrKons, Dsk, BgblAuth) — copy verbatim from the same result. Required with document_number. Codes and coverage: ris_list_reference topic applications. | |
| document_url | No | A https://www.ris.bka.gv.at/Dokumente/… main-document rendition URL as returned in a result’s content_urls — the alternative to document_number + application. Must address a main-document rendition ({documentNumber}.{ext}); content-attachment URLs (Materialien_/Anlagen_… memoranda and annexes) are not fetchable this way. | |
| document_number | No | Technical RIS document number (Technisch.ID), e.g. NOR40262691, JJT_…, BGBLA_2026_II_171 — copy verbatim from a ris_search_* or ris_lookup_citation result. Requires application; mutually exclusive with document_url. |
Output Schema
| Name | Required | Description |
|---|---|---|
| kind | Yes | full — the complete response (document text, selected sections, or rendition URLs). outline — the text overflowed the byte budget, so sections lists the retrievable §/Artikel/Anlage units; re-call with sections:[…] to fetch specific ones. |
| text | No | The document text in the requested format. Absent for urls_only and when the application carries no text rendition (see the notice). |
| format | Yes | The format served — echoes the requested format. |
| notice | No | Agent-facing notice: either the requested text format is unavailable for this application (names why and the usable URL), or the document overflowed to a section outline (names how to retrieve sections). |
| sections | No | Present when kind = outline: the document’s §/Artikel/Anlage sections, largest first, each with its UTF-8 byte size. Copy names into the sections input to retrieve them. |
| byte_size | No | Full UTF-8 byte size of the document text. Present when text was fetched — for an overflowed document (kind: outline) this reports the full text’s size, not the outline payload’s. |
| truncated | No | Present and true when the full text isn’t inline because the document overflowed to a section outline (kind: outline) — retrieve sections via the sections input, or fetch content_urls for the whole artifact. |
| application | Yes | RIS application the document belongs to (echoed). |
| content_urls | Yes | Constructed rendition URLs. Empty for authentic-PDF-only (Bvb/GrA/KmGer) and metadata-only (BgblAlt) applications — see authentic_pdf_url and the notice. |
| binding_status | Yes | Legal binding status: authentic (amtssigniert, legally binding), consolidated_informational (consolidated view — not binding), historical_record (superseded/pre-e-Recht promulgation), decision (court/tribunal ruling), preparatory (draft/bill/minutes), administrative_directive (binds the administration, not citizens), or translation (unofficial English). |
| document_number | Yes | Technical RIS document number (echoed). |
| authentic_pdf_url | No | The amtssigniert authentic PDF (.pdfsig, Authentisch DataType) — the legally binding artifact — where the application publishes one. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, openWorldHint, idempotentHint. The description adds extensive behavioral details: explicit binding status, authentic PDF surfacing, format availability per application, degradation via format_unavailable notice, overflow handling with outline, and sections usage. This significantly exceeds annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but front-loaded with core action. It is well-structured with clauses and punctuation, and every sentence adds necessary information. While effective, it could be slightly more concise given the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, varied format handling, application-specific behavior, output schema exists), the description covers edge cases like imperial gazettes, PDF-only cases, byte budget overflow, and format_unavailable notices. It explains return behavior (outline vs full text, kind: outline) and addresses all foreseeable scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value beyond schema definitions. It explains the two addressing methods (document_number+application or document_url), format meanings (markdown, html, xml, urls_only), format availability by application, sections usage, and constraints on document_url. This thoroughly augments schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches a RIS document's full text or rendition URLs with binding status and authentic PDF. It distinguishes from sibling tools by specifying it returns content, not metadata, and explains the two addressing methods. The verb 'Fetch' and resource 'RIS document' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs alternatives: it returns content, not metadata (which comes from search/lookup). It details format availability per application, degradation behavior, and section retrieval for large documents, providing clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ris_list_referenceRIS Reference ListsARead-onlyIdempotentInspect
Ground the opaque German codes across the RIS surface — static and offline, no upstream call. Topics: applications (all 39, with coverage windows, binding status, and content formats), courts (17 codes with Geschäftszahl examples and successor mapping), states (the three Bundesland request spellings), decision_types, decision_kinds (per-court Entscheidungsart values), issuing_bodies (dsk/dok/pvak/verg bodies and social-insurance issuers), ministries (abbreviations and full designations, historical included), collections (the 7 announcement collections and their parameter matrix), stages (lawmaking pipeline), changed_since_intervals, section_types, gazette_parts (BGBl parts and era tiers), law_types, district_authorities (all Bezirksverwaltungsbehörden), justiz_subject_areas (Fachgebiet taxonomy), search_syntax (operators and wildcard rules), and citation_formats (the shapes ris_lookup_citation parses). Recovery hints from the other ris_* tools route here.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Which reference table to return. Pick the topic named in the error recovery hint or zero-hit notice that sent you here. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notes | Yes | Topic-level caveats and usage guidance. Empty when none apply. |
| topic | Yes | The requested topic, echoed back. |
| entries | Yes | Reference entries for the topic. |
| summary | Yes | What this topic covers and which tool parameters consume its values. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent. The description adds 'static and offline, no upstream call', providing extra behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but front-loaded with purpose and lists all topics. Each sentence adds value, though slightly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with complex topic enumeration and recovery hints, the description is comprehensive: it covers what, when, how, and ties to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with enum values. The description adds guidance to pick topic from error hints, which is helpful beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool grounds opaque German codes, listing 17 topics. It distinguishes from siblings by noting other ris_* tools route recovery hints here.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It mentions the tool is static/offline and to pick a topic from error hints. While it doesn't explicitly list when not to use, the recovery hint context provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ris_lookup_citationResolve Austrian Legal CitationARead-onlyIdempotentInspect
Resolve a single Austrian legal citation to its canonical RIS document deterministically — no keyword search. Four routes are auto-detected from the citation shape (or forced with kind): a norm citation — section-first ("§ 6 DSG", "Art 10 B-VG"), abbreviation-first ("DSG §1", "DSGVO Art32", the shape ris_search_case_law returns in norms_cited), or a bare abbreviation like "ABGB" — resolves through consolidated federal law, or a Bundesland with a state hint, as in force today or on in_force_as_of; a gazette citation ("BGBl. I Nr. 165/1999", pre-2004 "BGBl. Nr. 194/1961", imperial "RGBl. Nr. 189/1902", or "LGBl. Nr. 61/2026" with a state hint) routes to the right federal era tier by year or to a state Landesgesetzblatt; a case number ("Ra 2019/22/0184", "G 287/2022", "6Ob56/25k", "2025-0.934.677", "W256 …") is matched to its court — pass court to skip detection, and ambiguous formats probe up to two courts; a collection number ("VfSlg 19.632/2012", "VwSlg 18.000 A/2010") resolves through the VfGH/VwGH collection. Returns the single best-matching document in the same shape as the corresponding search tool, with alternatives_count when more than one matched. A citation that cannot be classified or resolved returns found: false with next-step guidance — it never throws for a miss; only an upstream RIS outage is an error. For keyword rather than citation lookup, use ris_search_legislation or ris_search_case_law.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Force a route, or auto (default) to classify by shape. Set explicitly when the citation shape is ambiguous. | auto |
| court | No | Court hint for a case number — short-circuits court detection to this court. Codes: ris_list_reference topic courts. | |
| state | No | Bundesland hint — routes a norm to that state’s consolidated law (LrKons) and an LGBl. gazette to that state’s Landesgesetzblatt (LgblAuth). | |
| citation | Yes | The legal citation to resolve, e.g. "§ 6 DSG" or "DSG §1", "Art 10 B-VG", "BGBl. I Nr. 165/1999", "Ra 2019/22/0184", or "VfSlg 19.632/2012". | |
| in_force_as_of | No | For a norm, resolve the version in force on this date (YYYY-MM-DD). Defaults to today in Austria. |
Output Schema
| Name | Required | Description |
|---|---|---|
| kind | Yes | What the citation parsed as — "unknown" when it did not classify into any route. |
| found | Yes | True when the citation resolved to a single best-matching document. |
| record | No | The resolved document, in the same normalized shape the corresponding search tool returns — ris_search_legislation for a norm, ris_search_case_law for a case or collection number, ris_search_gazette for a gazette. Present when found is true. |
| guidance | No | Next-step guidance naming a concrete tool. Present when found is false. |
| resolution_note | No | Which application and filter resolved the citation. Present when found is true. |
| alternatives_count | No | Documents that also matched beyond the one returned — present only when more than one matched. List them all with the search tool named in resolution_note. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations (readOnly, openWorld, idempotent) by detailing that a miss returns found: false with guidance rather than throwing an error, and explains return structure (same shape as search tool with alternatives_count). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long but well-structured with clear sections for each route and example citations. It is front-loaded with the core purpose and alternative tools. Minor redundancy could be trimmed but overall appropriate for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the input schema (5 params, 1 required, 3 enums) and the existence of an output schema, the description covers behavior for all routes, error handling, and return fields (found, alternatives_count). It references the output shape but does not duplicate output schema details, which is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. The description significantly enhances parameter understanding by explaining the auto-detection logic for kind, providing examples for citation, and clarifying the roles of court and state hints and in_force_as_of for norm versions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves a single Austrian legal citation to its canonical RIS document deterministically, distinguishes from keyword search tools, and explicitly names sibling tools (ris_search_legislation, ris_search_case_law) for alternative use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (for citation lookup, not keyword search) and provides explicit alternatives. It also describes auto-detection of four routes and forced modes, but lacks explicit when-not-to-use scenarios beyond the keyword exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ris_search_announcementsSearch Official AnnouncementsARead-onlyIdempotentInspect
Search Austria’s sectoral official gazettes and executive documents — seven collections behind one collection enum: social_insurance (Amtliche Verlautbarungen der Sozialversicherung, authentic), veterinary (Amtliche Veterinärnachrichten, authentic), court_rules (Kundmachungen der Gerichte — rules of procedure and case-allocation plans, authentic; currently LVwG Tirol and Vorarlberg only), trade_exam_rules (Prüfungsordnungen gemäß Gewerbeordnung, authentic), health_structure_plans (Strukturpläne Gesundheit — federal ÖSG and per-state RSG, authentic), ministerial_decrees (Erlässe der Bundesministerien — decrees interpreting law; bind the administration, not citizens), and council_minutes (Ministerratsprotokolle — council-of-ministers session records). Each collection accepts a different filter set: query and title are broadly available; number, published_from/to, in_force_as_of, issuer (ministry abbreviations expanded server-side), norm ("decrees citing the DSG"), case_number, type, department, plan_type/plan_state (health plans), and session_number/legislature (council minutes) apply where the collection supports them — a filter outside its set is rejected locally. Every result carries a binding label and the authentic PDF where it exists. Per-collection parameter matrix and issuers: ris_list_reference topic collections or issuing_bodies.
| Name | Required | Description | Default |
|---|---|---|---|
| norm | No | Cited-provision filter (Norm) — "DSG §1", "DSGVO Art32" style. veterinary and ministerial_decrees only ("decrees citing the DSG"). | |
| page | No | 1-based result page. Default 1. | |
| type | No | Document type (Typ) — trade_exam_rules (Befaehigungspruefungsordnung | Meisterpruefungsordnung), court_rules (Geschaeftsordnung | Geschaeftsverteilung), veterinary (Kundmachungen | VeroeffentlichungenAufGrundVEVO | SonstigeVeroeffentlichungen). | |
| query | No | Full-text search (Suchworte). Boolean operators UND/ODER/NICHT or AND/OR/NOT, parentheses, quoted phrases; wildcard * is trailing-only. Valid for all collections. | |
| title | No | Title search (Titel) — phrase field. Valid for all collections except council_minutes. | |
| issuer | No | Issuing body — social_insurance (Urheber, e.g. ÖGK/SVS/BVAEB/AUVA/PVA), ministerial_decrees (Bundesministerium — abbreviation expanded server-side), council_minutes (Einbringer ministry). Values: ris_list_reference topic issuing_bodies or ministries. | |
| number | No | Serial number (Avsvnummer / Avnnummer / Spgnummer) — social_insurance, veterinary, health_structure_plans. | |
| sort_by | No | Sort column: published or number, where the collection has the column. Default: upstream order. | |
| page_size | No | Documents per page — RIS accepts 10, 20, 50, or 100. Default 20. | |
| plan_type | No | health_structure_plans only. Plan kind — all (default), expert_opinion (Gutachten), or regulation (Verordnungen). Searches the federal ÖSG unless plan_state is set. | |
| collection | Yes | Which collection to search — one per call. social_insurance | veterinary | court_rules | trade_exam_rules | health_structure_plans | ministerial_decrees | council_minutes. Per-collection filter matrix: ris_list_reference topic collections. | |
| department | No | Ministry department (Abteilung) — ministerial_decrees only. | |
| plan_state | No | health_structure_plans only. Restrict to one Bundesland’s regional health-structure plan (RSG) — setting it switches the search from the federal ÖSG to that state’s RSG. | |
| case_number | No | Business reference number (Geschäftszahl) — veterinary and ministerial_decrees only. | |
| legislature | No | Legislative period (Gesetzgebungsperiode, e.g. "XXVII") — council_minutes only. | |
| published_to | No | Latest publication/session date (YYYY-MM-DD). | |
| changed_since | No | Coarse recency filter — documents changed in RIS within the interval. For exact windows use ris_track_changes. | |
| in_force_as_of | No | Version in force on this date (YYYY-MM-DD) — veterinary, court_rules, trade_exam_rules, health_structure_plans, ministerial_decrees (the consolidated-ish collections). | |
| published_from | No | Earliest publication/session date (YYYY-MM-DD). All collections except ministerial_decrees (decrees date by force — use in_force_as_of / entered_force_from/to). | |
| session_number | No | Council session number (Sitzungsnummer) — council_minutes only. | |
| sort_direction | No | Sort direction; applies with sort_by. | |
| entered_force_to | No | Provisions that entered force on/before this date (YYYY-MM-DD) — ministerial_decrees only. | |
| entered_force_from | No | Provisions that entered force on/after this date (YYYY-MM-DD) — ministerial_decrees only. |
Output Schema
| Name | Required | Description |
|---|---|---|
| page | Yes | 1-based page number RIS served. |
| notice | No | Zero-hit guidance — names the likely cause and the concrete next call. |
| results | Yes | Matching documents for the requested page. Totals and paging in enrichment. |
| pageSize | Yes | Page size RIS applied. |
| truncated | No | Present and true when more pages exist beyond this one — raise page to continue. |
| totalCount | Yes | Total matching documents across all pages. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds that results carry a binding label and authentic PDF, extending beyond annotations (readOnlyHint, etc.). No contradiction. Mentions local rejection of invalid filters, aiding in understanding tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with front-loaded purpose and bullet-like list of collections. While lengthy, it avoids redundancy and every sentence adds value. Could be slightly shorter, but still highly effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 23 parameters, 7 collections, and an output schema, the description covers parameter-collection mappings, filter restrictions, and result features (binding label, PDF). It is thorough and leaves little ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage; the description adds critical per-collection applicability for parameters (e.g., which collections accept 'norm', 'case_number', etc.), significantly enhancing clarity beyond schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Search Austria’s sectoral official gazettes and executive documents' with verb 'Search' and specific resource. Seven collections are enumerated, distinguishing it from sibling tools like ris_search_case_law and ris_search_legislation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides per-collection filter sets and notes that invalid filters are rejected locally. Refers to ris_list_reference for details. While not explicitly contrasting with siblings, the description gives enough context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ris_search_case_lawSearch Austrian Case LawARead-onlyIdempotentInspect
Search Austrian case law (Judikatur) in ONE court or tribunal per call — court is required: vfgh (Constitutional Court), vwgh (Supreme Administrative Court), justiz (ordinary courts incl. OGH, selected decisions), bvwg (federal administrative), lvwg (state administrative), dsk (data protection authority), normenliste (VwGH norm index), dok, pvak, gbk, verg, upts (party transparency), and the historical uvs, asylgh, ubas, umse, bks. Cross-court research is one call per court (calls are cheap); historical bodies are closed windows with successors — codes, windows, and Geschäftszahl examples: ris_list_reference topic courts. Filter by full-text query, cited norm ("DSG §1", "DSGVO Art32" — the highest-value filter), exact case_number (Geschäftszahl), decision date range, decision_type (headnote vs full text), decision_kind, or the court-conditional filters: issuing_body (dsk/dok/pvak/verg), court_name/legal_area/subject_area (justiz), state (lvwg/uvs), party (upts), commission/senate/discrimination_ground (gbk), subject_law (bks), collection_number (vfgh/vwgh/uvs). For a known Geschäftszahl or VfSlg/VwSlg cite, ris_lookup_citation resolves it directly.
| Name | Required | Description | Default |
|---|---|---|---|
| norm | No | Cited-provision filter (Norm) — "DSG §1", "DSGVO Art32", "GewO 1994 §129", matching the format returned in norms_cited. The highest-value case-law filter. | |
| page | No | 1-based result page. Default 1. | |
| court | Yes | Which court/tribunal application to search — one per call. Codes, coverage windows, and successor mapping: ris_list_reference topic courts. | |
| party | No | Political party the decision concerns (upts only). Documented values: ÖVP, SPÖ, FPÖ, KPÖ, BZÖ, Team Stronach — the filter is full-text, and further party names appear in live data (e.g. "Wandel"). | |
| query | No | Full-text search over decisions (Suchworte). Boolean UND/ODER/NICHT or AND/OR/NOT, quoted phrases, trailing-only * wildcard. | |
| state | No | Which of the nine state administrative courts/senates to search (lvwg and uvs only). | |
| senate | No | Commission senate (gbk only). | |
| sort_by | No | Sort column. Default: upstream order. | |
| page_size | No | Documents per page — RIS accepts 10, 20, 50, or 100. Default 20. | |
| commission | No | Equal-treatment commission (gbk only): federal (Bundes-Gleichbehandlungskommission) or general (Gleichbehandlungskommission). | |
| court_name | No | Filter within the ordinary courts (justiz only) — "OGH", "OLG Wien", "LG Linz". | |
| decided_to | No | Latest decision date (YYYY-MM-DD). | |
| legal_area | No | Legal area (Rechtsgebiet, justiz only): civil (Zivilrecht) or criminal (Strafrecht). | |
| case_number | No | Exact Geschäftszahl — returns that decision’s documents. Formats differ per court (examples: ris_list_reference topic courts). Not available for normenliste. | |
| subject_law | No | Media statute the case concerns (Bereich, bks only) — e.g. "ORF-Gesetz", "Privatradiogesetz". | |
| decided_from | No | Earliest decision date (YYYY-MM-DD). Not available for normenliste. | |
| issuing_body | No | Deciding body (EntscheidendeBehoerde) — dsk, dok, pvak, and verg only. dsk: Datenschutzbehoerde (2014+) or Datenschutzkommission (up to 2013). Full value lists: ris_list_reference topic issuing_bodies. | |
| subject_area | No | Subject-area taxonomy filter (Fachgebiet, justiz only) — 39 exact German values like "Datenschutzrecht", validated locally: ris_list_reference topic justiz_subject_areas. The corpus carries no tagged documents yet (every value returns 0 hits, verified 2026-07-05) — filter with query or norm instead until RIS populates the tags. | |
| changed_since | No | Coarse recency filter — decisions changed in RIS within the interval. For exact windows use ris_track_changes. | |
| decision_kind | No | Decision kind (Entscheidungsart) — per-court value sets, validated locally: ris_list_reference topic decision_kinds. No such parameter exists for normenliste, dok, pvak, umse, bks, or upts. For justiz the four documented values are not yet populated in the corpus (every value returns 0 hits, verified 2026-07-05) — filter justiz with query or norm instead. | |
| decision_type | No | Search headnotes (Rechtssätze), full decision texts (Entscheidungstexte), or both (all, the default). Not available for gbk, upts, or normenliste. | all |
| sort_direction | No | Sort direction; applies with sort_by. | |
| collection_number | No | Official collection number (Sammlungsnummer) — VfSlg/VwSlg cites. vfgh, vwgh, and uvs only. | |
| discrimination_ground | No | Discrimination ground (gbk only): Alter (age), EthnischeZugehoerigkeit (ethnic origin), Geschlecht (gender/sex), Mehrfachdiskriminierung (multiple grounds), Religion (religion), SexuelleOrientierung (sexual orientation), Weltanschauung (worldview/belief). Upstream German enum values, sent verbatim. |
Output Schema
| Name | Required | Description |
|---|---|---|
| page | Yes | 1-based page number RIS served. |
| notice | No | Zero-hit guidance — names the likely cause and the concrete next call. |
| results | Yes | Matching decision documents for the requested page. Totals and paging in enrichment. |
| pageSize | Yes | Page size RIS applied. |
| truncated | No | Present and true when more pages exist beyond this one — raise page to continue. |
| totalCount | Yes | Total matching documents across all pages. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it notes that some filters (subject_area, decision_kind) currently return zero hits, that historical bodies are closed windows with successors, and that certain filters are court-conditional. This helps the agent set expectations and avoid ineffective queries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and required parameter, then lists optional filters. It is dense but not verbose; every sentence adds information. Given 24 parameters, the length is justified. A slight deduction for not being more structured with bullet points, but still clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all essential aspects: purpose, required parameter, filter options, limitations, and references to sibling tools for specific use cases. With an output schema present, the description does not need to detail return values, and it adequately informs the agent of the tool's capabilities and constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description still adds value by explaining the norm filter as 'highest-value', providing example values, listing court-specific parameter restrictions (e.g., issuing_body only for certain courts), and warning about empty filter results. This enhances agent understanding of parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches Austrian case law by court, listing all supported courts and noting cross-court research requires separate calls. It distinguishes from sister tools like ris_lookup_citation and ris_list_reference by referencing them for specific lookups and reference data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions when to use ris_lookup_citation instead (for known citation) and references ris_list_reference for court codes and window mapping. It also advises that cross-court research requires separate calls, implying it is acceptable. However, it doesn't explicitly compare with other search tools (like ris_search_legislation) or provide negative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ris_search_draftsSearch Draft LegislationARead-onlyIdempotentInspect
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 server-side 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. Documents are preparatory, not binding law. Ministry codes: ris_list_reference topic ministries.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based result page. Default 1. | |
| query | No | Full-text search (Suchworte). Boolean operators UND/ODER/NICHT or AND/OR/NOT, parentheses, quoted phrases; wildcard * is trailing-only. | |
| stage | Yes | Which 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. | |
| title | No | Title search (Titel) — phrase field: * allowed leading or trailing with ≥2 characters beside it. | |
| sort_by | No | Sort column: date (review deadline or adoption date per stage), ministry, or title. Default: upstream order. | |
| ministry | No | Submitting ministry (EinbringendeStelle). Accepts an abbreviation ("BMF") — expanded server-side to RIS’s exact-match designation; use the ministry’s name at the time of submission. Table: ris_list_reference topic ministries. | |
| page_size | No | Documents per page — RIS accepts 10, 20, 50, or 100. Default 20. | |
| decided_to | No | government_bills only. Latest adoption date (YYYY-MM-DD). | |
| decided_from | No | government_bills only. Earliest council-of-ministers adoption date (YYYY-MM-DD). | |
| in_review_on | No | review_drafts only. Drafts whose public-review window covers this date (YYYY-MM-DD). Today = drafts currently in Begutachtung. | |
| changed_since | No | Coarse recency filter — documents changed in RIS within the interval. For exact windows use ris_track_changes. | |
| sort_direction | No | Sort direction; applies with sort_by. |
Output Schema
| Name | Required | Description |
|---|---|---|
| page | Yes | 1-based page number RIS served. |
| notice | No | Zero-hit guidance — names the likely cause and the concrete next call. |
| results | Yes | Matching pipeline documents for the requested page. Totals and paging in enrichment. |
| pageSize | Yes | Page size RIS applied. |
| truncated | No | Present and true when more pages exist beyond this one — raise page to continue. |
| totalCount | Yes | Total matching documents across all pages. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, and idempotent hints. The description adds significant behavioral context: documents are preparatory and non-binding, ministry abbreviations are expanded server-side, and date filters are stage-specific. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but necessary due to complexity. It is front-loaded with purpose and efficiently covers key details without redundancy. Each sentence contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, annotations, and an output schema, the description fully covers purpose, stage selection, filtering details, and references for related resources. It is complete for an agent to understand and use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the pipeline stages, ministry abbreviation behavior, and filter applicability per stage, going beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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, distinguishing itself as the monitoring counterpart to ris_search_gazette. It specifies the verb 'search' and resource 'draft legislation' with precise context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts with ris_search_gazette and mentions using ris_track_changes for exact windows. It explains when to use different stage filters but does not comprehensively list all alternatives or when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ris_search_gazetteSearch Austrian GazettesARead-onlyIdempotentInspect
Browse Austria’s promulgation record — the authentic, legally binding gazettes — at every level of government. scope picks the jurisdiction: federal (default; the Bundesgesetzblatt across three era tiers auto-routed by year — BgblAuth 2004+ authentic, BgblPdf 1945–2003, BgblAlt 1848–1940 metadata-only ÖNB scans), one Bundesland (its Landesgesetzblatt), district (Bezirke promulgations), or municipal (Gemeinde promulgations). For a state scope, series selects law gazettes (law_gazette, the default → LGBl) vs ordinance gazettes (ordinance_gazette → Verordnungsblätter, currently Tirol only), and include_non_authentic adds the historical non-authentic state gazette (Niederösterreich’s systematic LgblNO, or the older Lgbl elsewhere). Filter by query (full text), title, number ("171/2026" — a pre-2004 number auto-routes to the right era tier), part (federal I/II/III or pre_1997), type (laws/regulations/announcements/other), published_from/to, issuer (federal or ordinance gazettes only), district_authority (district only), or municipality (municipal only). Every result carries a binding label (authentic vs historical_record vs consolidated_informational) and the amtssigniert authentic PDF wherever it exists — the binding artifact, never a paraphrase. For one known gazette number, ris_lookup_citation resolves it directly. Coverage windows, era tiers, and part semantics: ris_list_reference topic applications or gazette_parts.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based result page. Default 1. | |
| part | No | Federal only. part1 (Gesetze) | part2 (Verordnungen) | part3 (Staatsverträge) — parts exist from 1997; pre_1997 searches the older partless BGBl (routes to the 1945–2003 tier). Semantics: ris_list_reference topic gazette_parts. | |
| type | No | Document-type filter (Typ) for federal and state law gazettes: laws (Gesetze) | regulations (Verordnungen) | announcements (Kundmachungen) | other (Sonstiges). | |
| query | No | Full-text search (Suchworte). Boolean operators UND/ODER/NICHT or AND/OR/NOT, parentheses, quoted phrases; wildcard * is trailing-only. Syntax: ris_list_reference topic search_syntax. | |
| scope | No | Jurisdiction level: federal (default — the Bundesgesetzblatt, era tier auto-routed), a Bundesland (burgenland … wien, its Landesgesetzblatt), district (Bezirke promulgations), or municipal (Gemeinde promulgations). | federal |
| title | No | Title search (Titel) — phrase field: * allowed leading or trailing with ≥2 characters beside it. | |
| issuer | No | Issuing body — federal (EinbringendeStelle, e.g. "BMF") or ordinance gazettes (Vbl Einbringer: Landeshauptmann/frau, Landesregierung, Amt der Landesregierung, Sonstige Landesbehörden) only. Phrase field. | |
| number | No | Gazette number, e.g. "171/2026" or "BGBl. II Nr. 171/2026" (federal), "61/2026" (state), a Kundmachungsnummer (district/municipal). A trailing year routes a federal query to the right era tier; a bare number searches the current tier. | |
| series | No | State scopes only. law_gazette (default when omitted) searches the authentic Landesgesetzblatt; ordinance_gazette searches the Verordnungsblätter (Vbl — currently Tirol only, 2022+). | |
| sort_by | No | Sort column: published (Kundmachungsdatum) or number. Availability varies by tier; default: upstream order. | |
| page_size | No | Documents per page — RIS accepts 10, 20, 50, or 100. Default 20. | |
| municipality | No | Municipal only. Exact municipality name (Gemeinde), RIS’s spelling. | |
| published_to | No | Latest promulgation date (YYYY-MM-DD). | |
| published_from | No | Earliest promulgation date (YYYY-MM-DD). A pre-2004 range routes a federal query to an earlier era tier. | |
| sort_direction | No | Sort direction; applies with sort_by. | |
| district_authority | No | District only. Bezirksverwaltungsbehörde name, e.g. "Bezirkshauptmannschaft Liezen" — full list: ris_list_reference topic district_authorities. | |
| include_non_authentic | No | State scopes only. Adds the historical non-authentic state gazette — Niederösterreich’s systematic LgblNO, or the older Lgbl for the other Bundesländer (Wien is not carried). |
Output Schema
| Name | Required | Description |
|---|---|---|
| page | Yes | 1-based page number RIS served. |
| notice | No | Zero-hit guidance — names the likely cause and the concrete next call. |
| results | Yes | Matching gazette entries for the requested page. Totals, paging, and the served application in enrichment. |
| pageSize | Yes | Page size RIS applied. |
| truncated | No | Present and true when more pages exist beyond this one — raise page to continue. |
| totalCount | Yes | Total matching entries across all pages. |
| servedApplication | Yes | The RIS application that served the query — for federal, the era tier auto-routed by year (BgblAuth 2004+, BgblPdf 1945–2003, BgblAlt 1848–1940); otherwise the resolved state/district/municipal application. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds rich behavioral context: auto-routing of era tiers by year, binding labels (authentic vs historical), and that results contain authentic PDFs. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured, front-loading the main purpose and then detailing parameters and behavioral nuances. Every sentence adds value, though slight verbosity keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 17 parameters, 6 enums, and an output schema, the description is remarkably complete. It covers all parameters, explains complex behaviors like era-tier routing and scope-specific options, and references sibling tools for further details. No missing essential guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). The description adds meaning beyond the schema for parameters like scope (explains jurisdictions), series (law vs ordinance gazettes, Tirol only), number (auto-routes era tiers), part (explains pre-1997), and others. Provides examples and references ris_list_reference for details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool browses Austrian gazettes at all government levels, with specifics on scope, series, era-tier auto-routing, and binding labels. It distinguishes itself from sibling tools like ris_lookup_citation and ris_list_reference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (browsing promulgation record) and points to alternatives: ris_lookup_citation for known gazette numbers, ris_list_reference for coverage windows and parts. Provides context for scope selection and auto-routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ris_search_legislationSearch Austrian LegislationARead-onlyIdempotentInspect
Search Austrian consolidated law and English translations: federal law (scope: federal, the default), one Bundesland (scope: burgenland … wien), municipal law (municipality plus a state scope — selected norms in 6 Bundesländer), or English translations of selected federal laws (language: english, federal only, ~138 documents). One document is one § / Artikel / Anlage; fetch a whole law by filtering law_id. Searches apply the version in force today in Austria by default — set in_force_as_of for another date, include_all_versions: true for full version history, or an entered_force / left_force window for new-law and repeal tracking; the three version filters are mutually exclusive, and the applied date is echoed back in the result. query is full text (boolean UND/ODER/NICHT or AND/OR/NOT, trailing-only * wildcard); title matches title, short title, and abbreviation ("DSG"). For a specific citation like "§ 6 DSG", ris_lookup_citation resolves it deterministically instead. Consolidated text is informational, not legally binding — the authentic gazette artifact lives in ris_search_gazette.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based result page. Default 1. | |
| index | No | Systematik classification filter (e.g. "10/10 Datenschutz"). Federal/state consolidated law only. | |
| query | No | Full-text search (Suchworte). Boolean operators UND/ODER/NICHT or AND/OR/NOT, parentheses, quoted phrases; wildcard * is trailing-only ("Datenschutz*", never "*schutz"). Syntax: ris_list_reference topic search_syntax. | |
| scope | No | Jurisdiction: federal (default) searches consolidated federal law; a Bundesland searches that state’s consolidated law (or, with municipality set, its municipal law). | federal |
| title | No | Title search (Titel) — matches title, short title, and official abbreviation ("ABGB", "DSG"). Phrase field: * allowed leading or trailing with ≥2 characters beside it. | |
| law_id | No | Law-level grouping key (Gesetzesnummer, e.g. 10001597 = DSG) — exact match; returns every section of that law. Federal/state consolidated law only. | |
| sort_by | No | Sort column: section (§/Artikel/Anlage label) or in_force_date. Default: upstream order. Federal/state consolidated law only. | |
| language | No | german (default) searches the authoritative German corpus; english searches the ~138 unofficial English translations of selected federal laws (requires scope: federal; combines only with query and title). | german |
| page_size | No | Documents per page — RIS accepts 10, 20, 50, or 100. Default 20. | |
| section_to | No | End of the section range. Equal to section_from for a single section. | |
| municipality | No | Municipality name for municipal law (e.g. "Graz" — RIS’s spelling, not "Stadt Graz"). Requires a state scope; combines only with query, title, and in_force_as_of. Coverage is selected norms in 6 Bundesländer (no Burgenland/Tirol/Vorarlberg). | |
| section_from | No | Start of a § / Artikel / Anlage number range, digits with optional letter ("6", "1a"). Federal/state consolidated law only. | |
| section_type | No | Which section kind the range addresses. Defaults to Paragraph when a section range is set. Values: ris_list_reference topic section_types. | |
| changed_since | No | Coarse recency filter — documents changed in RIS within the interval. For exact windows and deletions use ris_track_changes. | |
| left_force_to | No | Provisions that left force on/before this date (YYYY-MM-DD). | |
| in_force_as_of | No | Return only the version in force on this date (YYYY-MM-DD). DEFAULTS TO TODAY in Austria — omitting it never searches all historical versions; opt into that with include_all_versions. | |
| sort_direction | No | Sort direction; applies with sort_by. | |
| left_force_from | No | Provisions that left force on/after this date (YYYY-MM-DD) — repeal tracking. Same exclusivity as entered_force_from. | |
| entered_force_to | No | Provisions that entered force on/before this date (YYYY-MM-DD). | |
| entered_force_from | No | Provisions that entered force on/after this date (YYYY-MM-DD) — new-law tracking. Federal/state consolidated law only; mutually exclusive with in_force_as_of and include_all_versions. | |
| include_all_versions | No | true searches every historical version (no in-force date filter) — version-history research. Overrides in_force_as_of; mutually exclusive with the force-window filters. |
Output Schema
| Name | Required | Description |
|---|---|---|
| page | Yes | 1-based page number RIS served. |
| notice | No | Zero-hit guidance — names the likely cause and the concrete next call. |
| results | Yes | Matching documents for the requested page. Totals and paging in enrichment. |
| pageSize | Yes | Page size RIS applied. |
| truncated | No | Present and true when more pages exist beyond this one — raise page to continue. |
| totalCount | Yes | Total matching documents across all pages. |
| appliedInForceAsOf | No | The in-force date the server actually applied (defaulted to today in Austria when omitted). Absent when include_all_versions, a force-window, or language: english searched without a date filter. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, openWorldHint, idempotentHint. Description adds that consolidated text is informational and not legally binding, explains default in-force date, mutual exclusivity of version filters, and that applied date is echoed back.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Long but well-structured and front-loaded. Each paragraph serves a purpose. Slightly verbose in places but still efficient for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Highly comprehensive covering jurisdiction, version filtering, query syntax, title search, language, sorting, and sibling tool references. Full coverage despite 21 parameters and conditional constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds significant meaning: default scope and language, query syntax details, law_id as grouping key, municipality coverage explanation, and version filter behavior. Goes well beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Austrian consolidated law and English translations, specifying scope (federal, state, municipal) and that one document is one §/Artikel/Anlage. It distinguishes from sibling tools like ris_lookup_citation and ris_search_gazette.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use this tool vs alternatives: for specific citations use ris_lookup_citation, for gazette use ris_search_gazette, for exact windows use ris_track_changes. Explains mutual exclusivity of version filters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ris_track_changesTrack RIS ChangesARead-onlyIdempotentInspect
Track every document added or changed in one RIS application within an exact date window (changed_from/changed_to) via the History controller, optionally including deletions (include_deleted) — the delta-sync and monitoring primitive for mirrors and watchers, and the only surface that reports removals. Unlike the search tools’ coarse, additive-only changed_since intervals, this is exact-dated and deletion-aware. application takes any RIS application code (e.g. BrKons, Dsk, BgblAuth); the four History name aliases are handled internally. Each changed document comes back in a compact cross-class record — document_number (for ris_get_document), title, dates, binding_status, and rendition URLs — plus its last-changed date; removed documents come back as deleted records with a deletion timestamp. One application per call; page explicitly for large windows. Application codes and coverage: ris_list_reference topic applications.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based result page. Default 1. | |
| page_size | No | Documents per page — RIS accepts 10, 20, 50, or 100. Default 20. | |
| changed_to | No | Include documents changed on/before this date (YYYY-MM-DD, AenderungenBis). | |
| application | Yes | RIS application whose change feed to read (standard code, e.g. BrKons, LrKons, Dsk, BgblAuth). History’s four aliased names are mapped internally. Codes: ris_list_reference topic applications. | |
| changed_from | No | Include documents changed on/after this date (YYYY-MM-DD, AenderungenVon). Exact date, not a coarse interval. | |
| include_deleted | No | true also returns documents removed from RIS in the window, as deleted records — the only way to observe deletions. |
Output Schema
| Name | Required | Description |
|---|---|---|
| page | Yes | 1-based page number RIS served. |
| notice | No | Zero-hit guidance — names the likely cause and the concrete next call. |
| results | Yes | Change-feed entries for the requested page. Totals, paging, and the applied window in enrichment. |
| pageSize | Yes | Page size RIS applied. |
| changedTo | No | The changed_to bound the server applied (echo), when set. |
| truncated | No | Present and true when more pages exist beyond this one — raise page to continue. |
| totalCount | Yes | Total change-feed entries across all pages. |
| application | Yes | The application whose change feed was read. |
| changedFrom | No | The changed_from bound the server applied (echo), when set. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds significant context: it uses the History controller, returns compact cross-class records, and handles deletion detection, without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and is well-structured. There is some verbosity in the output details, but each sentence adds value and no information is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, output schema, annotations), the description covers purpose, usage, parameter details, output format, and paging. It references sibling tools for application codes, making it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but description adds value by explaining application code handling, exact-date semantics for changed_from/changed_to, and that include_deleted is the only way to observe deletions. This enriches the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool tracks document changes in a single RIS application with exact date window and optional deletions. It distinguishes itself from sibling search tools by highlighting that it is deletion-aware and uses exact dates, not coarse intervals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it: for delta-sync and monitoring, and as the only surface reporting removals. It contrasts with search tools and advises paging for large windows. However, it could be more explicit about when not to use it, but the contrast is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!