sejm-mcp

Treść aktu prawnego

tresc_aktu

Read-onlyIdempotent

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

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.
`fraza`	No	Szukaj tej frazy w tekście (bez wielkości liter, z polskimi znakami): zamiast porcji zwraca tylko trafienia z kontekstem i ich pozycje (od)
`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

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.

Changed1 schema field changedv0.3.1Oct 14, 2026

addedInput schema / properties / fraza

Added value: +{
+  "description": "Szukaj tej frazy w tekście (bez wielkości liter, z polskimi znakami): zamiast porcji zwraca tylko trafienia z kontekstem i ich pozycje (od)",
+  "maxLength": 200,
+  "minLength": 2,
+  "type": "string"
+}

First observedv0.3.0Oct 2, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare a safe, idempotent read, but the description adds substantial behavior beyond them: chunk size of 12,000 characters, PDF-only fallback with the zPdf flag, article cut-off after the 'Art. N.' heading, inability to read image-only scans, preserved superscripts, and a wynikCzesciowy flag with an instruction to disclose partial results to the user. This is exactly the operational context annotations cannot carry.

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?

Purpose and mode selection are front-loaded and every sentence carries operational content (mode rules, PDF caveat, partial-result handling). It is, however, a single dense block of semicolon-chained clauses that is harder to scan than a short bulleted structure would be.

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 a 7-parameter schema, an output schema, and full annotation coverage, the description is complete: it covers mode selection, address sourcing, PDF/scan limits, partial-result disclosure, and result verification. Nothing an agent needs in order to call this 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 100%, so the baseline is 3, but the description adds real cross-parameter meaning: spis=true returns the article/chapter list together with the ids consumed by fragment, fragment ids are defined as coming from that list, and brzmienie=aktualne is explained as the latest consolidated text from HTML or, when ELI only has PDF, from PDF. It stops short of elaborating od/paging behavior beyond the schema's own note.

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: returns the text of a legal act from the ELI database as plain text, with three distinct retrieval modes (whole text in 12k chunks, single article, single unit). The scope and the mode-selection rules are stated up front, so an agent knows exactly what it gets without opening the schema.

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?

Explicit when-to-use rules: long acts/codes should be read article-by-article rather than in full, unit ids come from a spis=true listing, and the address must not be guessed — if unsure, obtain it from szukaj_aktow. It also tells the agent to verify the returned akt designation and how to react to a partial result, covering both selection and post-call behavior.

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