sejm-mcp

Szukaj głosowań

szukaj_glosowan

Read-onlyIdempotent

Search Polish Sejm voting records by phrase in the title; filter by date range or sitting, with newest results first.

Instructions

Wyszukuje głosowania po słowie w tytule (wyszukiwarka rejestru Sejmu), 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

TableJSON 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

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.8/5.0

Behavior5/5

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

Beyond the readOnly/idempotent/openWorld annotations, it discloses a concrete output-size cap (~20k znaków), the pagination mechanism (przesuniecie=nastepnePrzesuniecie), and a partial-result failure mode (wynikCzesciowy) with an instruction to tell the user. This is genuine behavioral context not derivable from annotations.

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 single paragraph, but front-loaded with purpose and most sentences carry unique operational guidance (title-syntax rules, dispatch to siblings, partial-result handling). It is longer than ideal and unsegmented, which costs some scannability, but little is pure filler.

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 described, and the description still flags the partial-result field that matters for user-facing behavior. Combined with title-matching rules and sibling routing, an agent has everything needed to select and call this tool correctly.

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 75% and the description adds real semantics: how to phrase fraza (dopełniacz, no abbreviations, stem matching), that od/do from another kadencja select that kadencja, and that pagination uses przesuniecie. It does not explain posiedzenie or najnowszeNajpierw, but those are self-evident from the schema.

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?

First sentence states a specific verb (wyszukuje), resource (głosowania), and scope (po słowie w tytule, opcjonalnie daty/posiedzenie) plus default ordering. It also explicitly distinguishes itself from glosy_posla_w_dniu and glosowanie, so an agent can separate it from its closest siblings without opening any 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?

Explicitly routes the agent: how to answer 'jak głosował poseł' (use glosowanie/glosy_posla_w_dniu instead), the alternative path via szukaj_procesow → proces (glosowanieKoncowe), and the rule to pick 'całość projektu ustawy' vs 'całość projektu uchwały'. It also states when-not (colloquial names absent from titles) with the workaround (search by subject + date range).

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