sejm-mcp

Treść aktu prawnego

tresc_aktu

Read-onlyIdempotent

Retrieve plain text of Polish legal acts from ELI database by article, fragment, or full text in chunks; optionally list act structure with IDs.

Instructions

Tekst aktu z bazy ELI jako zwykły tekst: cały w porcjach po 12 tys. znaków, jeden artykuł (artykul: "52", "52a", "764^5") albo jedna jednostka (fragment: id ze spisu). Ze spis=true zwraca spis artykułów i rozdziałów z ich id. Długie akty (kodeksy) czytaj artykułami, nie w całości. Każda odpowiedź podaje tytuł, rodzaj i oznaczenie aktu (pole akt): sprawdź, że to ten akt, o który pytano. Indeksy górne są zachowane (Art. 764⁵, § 2¹). Gdy akt albo jego najnowszy tekst jednolity ma tekst tylko w PDF, czyta tekst z PDF (pole zPdf; bez spisu jednostek, artykuł wycięty po nagłówku „Art. N.”); skanu bez warstwy tekstowej nie odczyta. Wynik bywa niepełny (brak czasu, awaria Sejmu, limit): wtedy ma pole wynikCzesciowy i powiedz to użytkownikowi na początku odpowiedzi.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`od`	No	Od którego znaku zacząć (dla długich tekstów)
`spis`	No	Zwróć spis jednostek zamiast tekstu
`adres`	Yes	Adres aktu: wydawca/rok/pozycja, np. "DU/2026/62" (Dziennik Ustaw) albo "MP/2023/1261" (Monitor Polski). Dla aktów sprzed 2012 r. adres to rok/POZYCJA, nie numer dziennika (Dz.U. 1997 nr 78 poz. 483 → DU/1997/483); Konstytucja RP to DU/1997/483. Adresu nie zgaduj: bez pewności weź go z szukaj_aktow.
`artykul`	No	Numer artykułu, np. "52", "52a"; z indeksem górnym "764^5" (art. 764⁵)
`fragment`	No	Id jednostki ze spisu, np. "arti_1-pint_2" albo "book_PIERWSZA-part_OGÓLNA-titl_VI-arti_117-para_2_1"
`brzmienie`	No	aktualne: z najnowszego tekstu jednolitego, z HTML albo, gdy ELI ma go tylko w PDF, z PDF (domyślnie); pierwotne: z dnia ogłoszenia	aktualne

Output Schema

TableJSON Schema

Name	Required	Description
`uwagi`	No
`zrodla`	Yes
`kalendarz`	No
`wynikCzesciowy`	No	Tylko przy wyniku NIEPEŁNYM: powiedz to użytkownikowi na początku

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Oct 2, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: PDF-only acts are read from PDF (field zPdf, no unit index, article cut at the 'Art. N.' header), text-layer-less scans cannot be read, superscripts are preserved, and partial results surface as wynikCzesciowy that must be disclosed to the user up front.

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?

Dense but front-loaded: the core purpose and modes come first, fallbacks and caveats after. Parenthetical clauses add detail without padding, though the sentence on PDF handling and the final partial-result sentence are somewhat packed.

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?

An output schema exists, so return values need not be spelled out, yet the description still names the key response fields (akt, zPdf, wynikCzesciowy) and covers the failure modes an agent must handle. Nothing needed to call it correctly is missing.

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 already 100%, but the description adds semantic glue: it shows what 'spis=true' returns (article/chapter index with ids) and that those ids feed the 'fragment' parameter, plus worked examples for 'artykul' ("52", "52a", "764^5").

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 ('Tekst aktu z bazy ELI jako zwykły tekst') and enumerates the three retrieval modes (whole act chunked at 12k chars, single article, single unit), so an agent immediately knows this is the content-retrieval tool as opposed to the search tools.

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 directives: long acts/codes should be read article-by-article rather than whole, and the response's 'akt' field should be checked to confirm the right act. It lacks explicit routing to siblings (e.g. szukaj_aktow vs tekst_druku), though the search-vs-fetch distinction is implicit.

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