Skip to main content
Glama

Search Austrian Legislation

ris_search_legislation
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo1-based result page. Default 1.
indexNoSystematik classification filter (e.g. "10/10 Datenschutz"). Federal/state consolidated law only.
queryNoFull-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.
scopeNoJurisdiction: federal (default) searches consolidated federal law; a Bundesland searches that state’s consolidated law (or, with municipality set, its municipal law).federal
titleNoTitle search (Titel) — matches title, short title, and official abbreviation ("ABGB", "DSG"). Phrase field: * allowed leading or trailing with ≥2 characters beside it.
law_idNoLaw-level grouping key (Gesetzesnummer, e.g. 10001597 = DSG) — exact match; returns every section of that law. Federal/state consolidated law only.
sort_byNoSort column: section (§/Artikel/Anlage label) or in_force_date. Default: upstream order. Federal/state consolidated law only.
languageNogerman (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_sizeNoDocuments per page — RIS accepts 10, 20, 50, or 100. Default 20.
section_toNoEnd of the section range. Equal to section_from for a single section.
municipalityNoMunicipality 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_fromNoStart of a § / Artikel / Anlage number range, digits with optional letter ("6", "1a"). Federal/state consolidated law only.
section_typeNoWhich section kind the range addresses. Defaults to Paragraph when a section range is set. Values: ris_list_reference topic section_types.
changed_sinceNoCoarse recency filter — documents changed in RIS within the interval. For exact windows and deletions use ris_track_changes.
left_force_toNoProvisions that left force on/before this date (YYYY-MM-DD).
in_force_as_ofNoReturn 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_directionNoSort direction; applies with sort_by.
left_force_fromNoProvisions that left force on/after this date (YYYY-MM-DD) — repeal tracking. Same exclusivity as entered_force_from.
entered_force_toNoProvisions that entered force on/before this date (YYYY-MM-DD).
entered_force_fromNoProvisions 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_versionsNotrue 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

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 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.
appliedInForceAsOfNoThe 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.

TDQS

A5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, but the description adds substantial behavioral context beyond them: the default in-force date (today in Austria), mutual exclusivity of version filters, the document granularity (one document = one §/Artikel/Anlage), coverage limitations (municipal law only in 6 Bundesländer), and the informational nature of consolidated text. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every sentence contributes unique information. It is logically structured: scope options, document granularity, versioning, search syntax, and pointers to alternatives. Despite length, it avoids redundancy and is front-loaded with the core purpose.

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 tool's complexity (21 parameters, multiple scopes, versioning), the description is remarkably complete. It covers all major use cases, explains constraints and limitations, names sibling tools for adjacent needs, and the presence of an output schema means return format needn't be described. 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?

Schema coverage is 100%, but the description adds meaning far beyond the parameter descriptions. It explains query syntax (boolean UND/ODER/NICHT, trailing-only wildcard), title matching including abbreviations, version filter semantics (default today, include_all_versions override), and language restrictions (english requires federal and combines only with query/title). This significantly enhances an agent's ability to use parameters correctly.

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 Austrian consolidated law and English translations, covering federal, Bundesland, municipal, and English scopes. It also distinguishes itself from siblings by explicitly redirecting citation lookups to ris_lookup_citation and authentic text to ris_search_gazette. The purpose is specific and unambiguous.

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?

Explicitly names alternatives and conditions: 'For a specific citation like "§ 6 DSG", ris_lookup_citation resolves it deterministically instead' and 'the authentic gazette artifact lives in ris_search_gazette'. It also notes that exact windows and deletions should use ris_track_changes. This gives clear when-to-use vs when-not-to-use guidance.

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.

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.