sejm-mcp

Szukaj głosowań

szukaj_glosowan

Read-onlyIdempotent

Instructions

Wyszukuje głosowania po słowie w tytule i temacie (wyszukiwarka rejestru Sejmu), a przy kilku trafieniach dobiera głosowania z tymi słowami w opisie; opcjonalnie w przedziale dat lub na jednym posiedzeniu. Domyślnie najnowsze najpierw. Tytuły są w dopełniaczu i bez skrótów: szukaj "ustawy budżetowej na rok 2024", "Krajowej Radzie Sądownictwa", nie "budżetowa 2024" ani "KRS"; rdzeń słowa też działa ("budżet", "podatk"). Fraza z nazwiskiem posła (np. „Mejza immunitet”) szuka tego nazwiska w TYTUŁACH głosowań (wnioski o uchylenie immunitetu, sprawy z oskarżenia prywatnego); jak dany poseł głosował, daje glosowanie z poselId albo glosy_posla_w_dniu, nie to narzędzie. Pytanie „jak głosował poseł nad ustawą X”: szukaj tu po tytule ustawy i opisie „całość projektu”, albo przez szukaj_procesow → proces (pole glosowanieKoncowe); sprawdź, czy data, tytuł i druk zgadzają się z pytaniem, zanim wybierzesz głosowanie: kilka ustaw ma identyczny tytuł i różni się tylko numerem druku. Uwaga: ustawa „o zmianie ustawy budżetowej” albo „o szczególnych rozwiązaniach służących realizacji ustawy budżetowej” to INNE ustawy niż sama ustawa budżetowa. Pytanie o ustawę: bierz głosowanie z opisem „całość projektu ustawy”; „całość projektu uchwały” to uchwała, nie ustawa. Nazw potocznych („lex TVN”, „ustawa kagańcowa”, „nowelizacja”) nie ma w tytułach: szukaj przedmiotem ustawy („radiofonii i telewizji”) z datą od/do. Daty od/do z innej kadencji wybierają tę kadencję. Wynik mieści się w ok. 20 tys. znaków; resztę daje przesuniecie=nastepnePrzesuniecie. 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
`do`	No	Do dnia (RRRR-MM-DD)
`od`	No	Od dnia (RRRR-MM-DD)
`fraza`	No	Słowo lub fraza z tytułu głosowania
`limit`	No	Ile wyników najwyżej (domyślnie 20, max 50)
`kadencja`	No	Numer kadencji Sejmu; domyślnie 10 (bieżąca, od 13 listopada 2023)
`posiedzenie`	No
`przesuniecie`	No	Od którego wyniku zacząć (stronicowanie)
`najnowszeNajpierw`	No

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.

First observedv0.3.0Oct 2, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: a ~20k character result cap, pagination via przesuniecie=nastepnePrzesuniecie, and the wynikCzesciowy partial-result flag with an instruction to surface it to the user first. This is exactly the behavioral detail 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?

The core purpose is front-loaded and almost every sentence carries actionable guidance, but the text sprawls into a dense run-on with some repetition (the 'jak głosował poseł' case is restated) and a long tail of edge cases. Dense value, but not maximally tight.

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?

With an output schema present, the description needn't explain return shapes, and it instead covers what structured fields cannot: search semantics, pagination, partial-result handling, term selection, and correct sibling routing. Nothing an agent needs to invoke this correctly 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 75%, and the description compensates with real semantics: fraza behavior (phrase with a surname searches titles only; stems work), od/do interaction with kadencja (dates from another term select that term), and the od/do+przedział date usage. It adds meaning well beyond the schema's terse descriptions.

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 and resource ('Wyszukuje głosowania po słowie w tytule i temacie') and immediately scopes it as the Sejm registry search engine. It also distinguishes itself from siblings by explicitly excluding glosowanie z poselId and glosy_posla_w_dniu, so an agent knows when this is the wrong tool.

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?

Gives explicit when-to-use and when-not-to-use guidance, names alternatives (glosy_posla_w_dniu, glosowanie z poselId, szukaj_procesow → proces) with the condition that selects each, and supplies concrete search-syntax rules (dopełniacz, no abbreviations, stems work) plus a worked example of the correct routing for 'how did MP X vote'.

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