sejm-mcp

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely useful behavior: relations come back in titled chunks, per-kind counts are available in odpowiedz and powiazania[].liczba so no list fetch is needed to count them, and stanPrawnyNa is the date the consolidated text was prepared. It does not describe output shape beyond that, which is acceptable given an output schema exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Purpose and routing are front-loaded in the opening sentences and the density is high with little filler. It is long and repeats some parameter examples already in the schema, which keeps it from a 5, but each sentence carries an operational instruction.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter, one-required read tool with a full output schema and rich annotations, the definition covers addressing (don't guess), pagination via powiazaniaLimit/Przesuniecie, count access, consolidated-text semantics, and cross-tool handoff to proces. Nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description goes beyond it: it warns that adres must come from szukaj_aktow rather than being guessed, explains that kolokwial terms like 'nowelizacje' work for powiazania, and clarifies that tekst concerns only this act while najnowszyTekstJednolity.html gives the latest consolidated format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource (one legal act from the ELI database) and enumerates the exact content returned: legal status, entry-into-force date, promulgation, issuer, keywords, parliamentary prints, and typed relations to other acts. It differentiates from proces and szukaj_aktow, but does not explicitly contrast with tresc_aktu, the closest sibling for full act text, so it falls short of a clean 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing rules are given: the eli field from proces is the address for this tool, addresses must not be guessed but taken from szukaj_aktow, and drukiSejmowe[].proces should be forwarded to proces for presidential signature/veto/TK referrals. It also directs the agent to use this act's 'Akty zmieniające' relation for the latest amendment rather than a title search, naming the alternative approach to avoid.

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

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

Annotations already cover read-only/idempotent/destructive-free, so the bar is lower, yet the description adds substantial semantics: the distinction between dataDokumentu (authoring date) and doreczono (delivery to MPs), plus the cross-cadence caveat with a concrete example (druk 164). It does not discuss pagination or error behavior for an unknown numer, keeping it shy of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The front-loaded first clause states the resource and payload efficiently; the date-semantics guidance is dense and useful. The historical example (druk 164 with three dates) is long but earns its place as disambiguation, so only slight verbosity cost.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-record lookup with annotations covering safety and an output schema covering return shape, the description supplies the one thing that cannot be inferred — the meaning and interrelation of the date fields and where the true 'influence' date lives. Nothing an agent needs to answer correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already documented in the schema (numer format, kadencja default/min/max). The description adds no syntax or defaulting detail for either parameter, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

It states precisely that the tool returns a single Sejm print ('Jeden druk sejmowy') and enumerates the payload — title, dates, related processes, file addresses, and附加 druki. The singular scope implicitly separates it from the sibling search tool szukaj_drukow, though it never names that sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It directly instructs how to answer the common question 'when did it reach the Sejm' — do not use dataDokumentu, use the proces tool's wszczeto field — and warns that across cadences the dates can diverge by years, telling the agent to report which date applies. It names the alternative tool (proces) and the condition selecting it.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, and the description adds substantial behavior beyond them: batched pagination (default and max 30, shrinking for long titles to stay under ~20k chars), the non-obvious rule that the next page uses przesuniecie equal to nastepnePrzesuniecie rather than przesuniecie+limit, term inference from an out-of-term date, and how porzadek restructures output (with a 'Pozostałe głosowania' bucket). 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.

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

Front-loaded with the resource and its output shape before the usage rules, and every sentence carries operational information (pagination, mode switching, sibling routing). It is dense and would read better with light structuring, but there is no filler to cut.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 explained; the description covers the remaining decision points — which mode, whether to pass data, how to page, how the term is resolved, and which sibling handles detail. 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.

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 genuine meaning the schema does not: that omitting data yields a whole-sitting tally, that limit=1 is the idiom for aggregate questions, and the precise offset-chaining rule for przesuniecie. It leaves minor gaps (e.g. odPunktu is only lightly covered) but clearly exceeds the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: it returns the votes (głosowania) of one sitting or one day, including threshold-derived verdicts and a tally of adopted/rejected/quorum-appeal/election votes. It explicitly routes detail/club-breakdown requests to the sibling tool glosowanie, so an agent can distinguish the two without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use rules: call WITHOUT the data parameter (e.g. limit=1) for 'how many / how many adopted at this sitting' questions because the tally then covers the whole sitting, and do not sum daily tallies. It also names porzadek=true as the alternative mode and points to glosowanie for details — clear conditions with named alternatives.

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

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

Annotations already declare readOnly/idempotent/no-destructive, and the description adds substantial domain behavior: club breakdown uses membership ON THE VOTING DAY, kluby[] carry kartOddanych and nieobecni, and crucially the Senate-amendment trap where 'against' means for the amendment and the rozstrzygniecie field disambiguates it. This is real value beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Dense but front-loaded, with the core output shape stated first and the semantic edge case (Senate amendment) and the sibling routing sentences following logically. Every sentence carries information, though the density of Polish clauses makes it heavy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Complete for a complex read tool: with an output schema and annotations already covering the safety profile, the description still surfaces the non-obvious vote-interpretation rule and the club-field semantics an agent needs to interpret results correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 83% schema coverage the schema already documents most parameters, but the description adds meaning: klub yields the roll-call row-by-row for one club, poselId shows how one or several MPs voted, and listaImienna attaches every MP's vote. It complements rather than merely repeats the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (single vote with details) and enumerates what it returns: verdict from threshold, required majority, club breakdown, optional MP vote, and roll-call list. It distinguishes itself from the sibling glosy_posla_w_dniu by naming it and its use case.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Routes the agent explicitly: for a series of votes on one day (e.g. all Senate amendments) it points to glosy_posla_w_dniu as 'one call instead of many'. It also clarifies the optional poselId/listaImienna usage. No explicit when-not-to-use beyond that single alternative.

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

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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), lowering the bar. The description usefully adds the aggregation behavior ('jedno wywołanie, a nie glosowanie po kolei'), but the rest of its content (topic, agenda item, Senate amendment/veto outcome) is return-content detail that the output schema already provides.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two compact sentences lead with the core purpose and then the routing/alternative information; nothing is wasted and the most important claim is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a rich output schema and full annotations, the description only needs to frame purpose and routing, which it does. The only gap is the undocumented 'posiedzenie' parameter, which is minor given the schema and the defaulted 'kadencja'.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is high (75%), so the schema carries most parameter meaning; the description adds no parameter-level detail (formats, ranges, or what 'posiedzenie' means, which is the one undocumented field). Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb+resource+scope: 'Wszystkie głosy jednego posła w jednym dniu posiedzenia'. It also distinguishes itself from the per-vote alternative ('to narzędzie, jedno wywołanie, a nie glosowanie po kolei'), so an agent can separate it from glosowanie/glosowania_posiedzenia without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear usage context ('Jak poseł głosował w serii głosowań jednego dnia, np. nad wszystkimi poprawkami Senatu') and names the alternative sources for the required date (lista_posiedzen, profil_posla z dni=true). It stops short of stating when NOT to use it (e.g. multi-day or multi-MP queries), so it is strong but not exhaustive.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description usefully adds what the entity is and that member records include both deputies and senators, but discloses nothing further about permissions, rate limits, or result size. With annotations carrying the burden, a 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

A single tightly packed sentence that front-loads the resource and the example, then states both retrieval modes. No wasted words, though the parenthetical example and dual-mode clause make it slightly dense.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With annotations covering the safety profile and an output schema present, the description need not explain return values. It captures the entity, the search field, and the member-inclusive mode, leaving little an agent would need beyond structured data.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so each parameter (id, fraza, kadencja, dawniCzlonkowie) is already documented in the schema. The description adds only a light gloss (search by name, members on lookup) that maps to those fields, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (Polish-foreign parliamentary groups) with a concrete example, and clearly distinguishes its two operating modes: a searchable list vs a single group with its members (deputies and senators). It does not, however, differentiate itself from any sibling tool, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: the two modes (list-with-name-search vs one-group-with-members) hint at how parameters select behavior, but there is no explicit when-to-use/when-not guidance and no named alternative among the many sibling tools for parliamentary data.

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

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

Annotations already declare the full safety profile (readOnly, idempotent, non-destructive, openWorld), so the burden is light. The description adds useful scope context (coverage begins 1991, flags the currently active term), but discloses nothing about volume, caching, or refresh behavior beyond what annotations and the output schema cover.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two tight sentences: content scope is front-loaded, then a single usage clause. No filler, though the closing usage sentence is slightly imprecise ('dawnych lat') relative to the stated 1991 coverage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless listing tool with an output schema and full safety annotations, the description supplies adequate scope and content framing, so an agent can decide when to call it. Only the absence of explicit alternative-routing guidance keeps it from being fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the schema-side baseline is 4. The description still lists the fields returned (numer, dates, current flag, druki count), which adds orientation value even though parameters themselves need no explanation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific resource (kadencje Sejmu RP) and enumerates exactly what each entry contains: number, start/end dates, which term is current, and paper count. This level of content detail clearly separates it from data-heavy siblings like druk or glosowanie, though it does not explicitly name an alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a when-to-use hint: 'Przydaje się, gdy pytanie dotyczy dawnych lat' (useful when the question concerns earlier years). However, it names no sibling tool and gives no exclusions or conditions that would route the agent between this and other reference tools.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds real behavioral context beyond them: data is 'as of today', the fuzzy-match fallback (colloquial abbreviation or partial name resolved to the registry abbreviation only when unambiguous), and that last-changes are included by default.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Three sentences, front-loaded with the no-parameter case first, then the parameter case, then the extra last-changes payload. Dense but each sentence carries distinct information; only minor redundancy in the closing restatement of what the no-parameter mode adds.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-shape detail is unnecessary, and the description still covers both invocation modes, matching behavior, and a default payload. Complete enough for a 2-param read tool; only the absence of any comparison to related tools (e.g. komisje) leaves a sliver of ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description meaningfully extends it: it explains the matching semantics for 'klub' (colloquial shorthand like "PSL" resolved to "PSL-TD" when unambiguous) rather than just repeating the schema's example values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (kluby i koła w Sejmie danej kadencji) with concrete output fields, and clearly describes the two modes: no parameter returns the roster with member counts and type; with 'klub' returns one club with name, contact, logo, composition and entry dates. An agent can distinguish this from komisje or grupy_bilateralne without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly splits behavior by presence/absence of the 'klub' parameter, telling the agent what each mode yields and that the no-parameter mode also returns recent club-switching. It does not name sibling tools or state when another tool would be preferable, so it stops short of full alternative routing.

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

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

PLACEHOLDER

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Dense but well structured: each clause maps to a distinct parameter mode, and the sibling redirection comes last. It is longer than a single-sentence tool but nearly every phrase carries information; only the enumeration of returned fields borders on redundancy given the output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all four call modes and routes to the sittings sibling, and an output schema exists so return shapes need not be spelled out. The only minor gap is the behavior of dawniCzlonkowie (include departed members), which is left to the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so baseline is 3, but the description adds genuine value by explaining the branching semantics — that 'kod' resolves to either a committee or a subcommittee depending on the pattern, and that poselId switches the response to an MP-centric view. This is more than the schema's per-parameter strings convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (sejm committees and their composition) and enumerates exactly what each mode returns (kod/nazwa/rodzaj, membership, subcommittees, MP assignments). It explicitly differentiates itself from the sibling 'posiedzenia_komisji', which handles sittings rather than committee composition.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use routing for four distinct call shapes: no params for all committees, kod for one committee, a subcommittee kod for one subcommittee, and poselId for an MP's memberships. It also names the sibling tool to use for sittings, leaving nothing to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds genuine behavior beyond that: the default result window, the caveat that sumy still aggregate over the whole term, an output-size hint (~11 tys. znaków), and that planowane adds not-yet-numbered sittings. It stops short of describing ordering or pagination details, so it is not a full 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The most important points (what is returned, default window, alternatives, cross-reference) are front-loaded in a compact paragraph with no filler. It is dense and information-rich, though the parenthetical about sumy mid-sentence slightly taxes readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return-value documentation is not required, and the description covers defaults, alternatives, aggregation caveat and a cross-tool handoff. Nothing an agent needs 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.

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 interaction semantics not present in the schema: it clarifies how wszystkie relates to od/do (whole term vs. specific period) and that default filtering does not narrow the sumy aggregates. That is meaningful parameter behavior beyond field-level docs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (listing Sejm sittings of a given term) and enumerates the returned fields: numer, daty, stan, liczba głosowań oraz numer ostatniego zakończonego posiedzenia. It is clearly distinguishable from siblings like porzadek_posiedzenia and glosowania_posiedzenia, which it explicitly cross-references.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use routing: no od/do yields the 10 most recent plus upcoming sittings, wszystkie=true yields the whole term, od/do selects a specific period, and agenda-with-votes is delegated to glosowania_posiedzenia with porzadek=true. Both the default and the alternatives are spelled out rather than implied.

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

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

Annotations declare readOnly/idempotent/non-destructive, so safety is covered, and the description layers on genuinely useful behavior: the server extracts text from PDF only after odpowiedzKlucz is given, cannot read scans lacking a text layer, and returns wynikCzesciowy on timeout/Sejm failure/limit. These are real operational caveats beyond the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

It is a single dense paragraph; the key framing 'Jedno pismo' is front-loaded, and the partial-result handling sentence earns its place, but the middle clauses about addressee attribution and signed-vs-motion answers are verbose and could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be explained, and the description covers the important edge cases (PDF-only answers, unreadable scans, partial results). It is essentially complete for an agent to call it correctly, missing only explicit sibling guidance.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 83%, so the baseline is 3, but the description adds meaning: odpowiedzKlucz triggers server-side PDF reading, and the 'w porcjach' phrasing connects to the 'od' offset parameter for chunked long text. It does not cover every field (numer, kadencja) but meaningfully explains the non-obvious ones.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with 'Jedno pismo' (a single letter) and enumerates what is returned: adresaci with deadline and status, answers with PDF addresses, and optional plain-text content. This is a specific verb+resource framing that separates it from the sibling search tool szukaj_pism, though it never names that sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It implies when to pass odpowiedzKlucz (to pull the answer body) and instructs the agent to surface partial results ('powiedz to użytkownikowi na początku odpowiedzi'), but it offers no explicit when-not-to-use and does not route the agent to alternative tools like szukaj_pism or druk.

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

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

Adnotacje pokrywają profil bezpieczeństwa (readOnlyHint, idempotentHint, destructiveHint=false), więc opis nie musi tego powtarzać. Wnosi jednak istotny kontekst zachowaniowy poza adnotacjami: semantykę braku numeru posiedzenia (bieżące/najbliższe) oraz to, że dla posiedzeń zakończonych zwracany jest porządek zrealizowany, co wpływa na interpretację wyniku. Brakuje informacji o ewentualnej paginacji mimo parametru od.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Zwięzłe, jednoliniowe zdanie z front-loadingiem najważniejszej informacji (co to jest i jak traktować brak numeru). Każdy fragment zdania wnosi konkretną informację. Mimo to konstrukcja z nawiasami i wieloma myślnikami może utrudniać szybkie skanowanie.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Biorąc pod uwagę, że istnieje output schema (opis nie musi wyjaśniać zwracanych wartości), adnotacje pokrywają bezpieczeństwo, a schemat opisuje parametry, opis uzupełnia kluczowe luki: semantykę trybu bez numeru oraz zachowanie dla posiedzeń zakończonych. Wystarczająco kompletny dla agenta, by poprawnie wywołać narzędzie, choć brak wskazania relacji z sąsiednimi narzędziami pozostawia niewielką niepewność.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema ma 100% pokrycia opisami (od, kadencja, posiedzenie), więc zgodnie z regułą bazą jest 3. Opis dodaje jedynie znaczenie braku parametru posiedzenie (bieżące/najbliższe), co jest już częściowo odzwierciedlone w schemacie, ale nie wnosi nowych szczegółów formatu, zakresu wartości ani interakcji między kadencją a posiedzeniem.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Precyzyjnie określa czasownik+zasób (porządek obrad posiedzenia Sejmu jako tekst) i natychmiast rozróżnia tryby działania: bez numeru (bieżące/najbliższe) vs z numerem (dowolne posiedzenie kadencji). W kontekście licznego rodzeństwa z rodziny posiedzeń (lista_posiedzen, glosowania_posiedzenia, wypowiedzi_posiedzenia) wyraźnie wskazuje na unikalny zwrot tekstowy porządku obrad, a nie metadane czy głosowania.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Jasno opisuje warunki użycia: bez numeru posiedzenia dla bieżącego/najbliższego, z numerem dla dowolnego posiedzenia kadencji, z doprecyzowaniem że dla zakończonych to porządek zrealizowany. Nie wymienia jednak wprost alternatyw (np. lista_posiedzen do metadanych lub wypowiedzi_posiedzenia do treści), więc agent musi sam wywnioskować, kiedy sięgnąć po to narzędzie zamiast sąsiednich.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: it discloses newest-first ordering, that joint meetings with other committees are included, the 7-day window cap, and a partial-result failure mode signalled by the wynikCzesciowy field with an instruction to warn the user first.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

One dense paragraph with the three modes front-loaded and no filler; every clause carries operational meaning. It would read better broken into bullets, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter tool with an output schema, the description covers the mode logic, the code dependency on a sibling tool, pagination/limit behavior, and the degraded-result case — an agent has everything needed to call it and interpret the response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so individual parameter meaning is already carried by the schema and baseline would be 3. The description adds real cross-parameter semantics the schema does not state — how data/do/od interact across the three modes and that 'razem' is a count of meeting numbers rather than days.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (committee meetings) and enumerates three distinct invocation modes keyed on which parameters are supplied. An agent can tell exactly what each mode returns 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes mode selection (data-only vs. code vs. code+numer), names the sibling tool 'komisje' as the source of committee codes, and even maps a concrete user question ('ile posiedzeń...') to mode (2) with a stated interpretation rule for the count.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety and idempotency profile is fully covered. The description adds useful cross-tool data-flow context (how glosowanieKoncowe and eli connect to sibling tools) but does not disclose return format, error behavior, or pagination limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is a single long sentence packed with field-level explanations, which front-loads the main content but becomes dense and difficult to parse. While every clause contains useful information, the lack of sentence breaks and broad length reduce readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema, the description needn't explain return values, and it appropriately focuses on how to use key returned fields (glosowanieKoncowe, eli, dataOgloszenia) with related tools. It is nearly complete for an agent's needs, with minor gaps around default kadencja behavior already covered by the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters (numer, kadencja) are already documented. The description adds non-obvious meaning: 'Numer procesu to zwykle numer druku, który go rozpoczął' is a genuinely useful interpretation of the numer field that the schema description only illustrates with a generic example.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves a single legislative process with its full ordered list of stages, naming the specific stage categories and fields returned. It is distinguishable from search tools like szukaj_procesow, though that differentiation is achieved through the detailed content listing rather than an explicit contrast.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides concrete, actionable guidance for using related tools: pass glosowanieKoncowe to glosowanie with poselId to check a deputy's vote, and use the eli field with akt to check the published act's status. It does not spell out when-not-to-use versus szukaj_procesow, but the usage context is clear for the primary retrieval scenario.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so safety is covered; the description adds real context beyond that: the statistics are the Sejm's own numbers rather than a local computation, klub reflects the current affiliation, and id semantics differ across terms. No return-format disclosure, but the output schema covers that.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Long, but every clause carries distinct information (payload fields, statistics semantics, flag behaviours, id/term caveat) and the primary payload is front-loaded. The parenthetical parameter syntax is slightly dense but not wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter tool with an output schema documented separately, the description covers everything an agent needs: the identity/term caveat, all flag interactions, the date-range semantics, and the source of the statistics. No material gap remains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage the baseline is 3, yet the description goes further: it explains that dni=true adds a per-sitting-day breakdown, posiedzenia=true aggregates per sitting, and od/do are inclusive and populate the 'zakres' field, with a worked example (od=2025-01-01, do=2025-12-31).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete resource (poseł's registry record) and enumerates the payload: klub, okręg, głosy, dane biograficzne, ślubowanie, wygaśnięcie mandatu, plus voting statistics scoped to a Sejm term. It is clearly distinguishable from siblings like znajdz_posla (search) or glosy_posla_w_dniu (per-day votes).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: numeric id is valid only within one kadencja, so an MP in another term must be located via znajdz_posla. It also warns that klub is today's affiliation and that a day-specific klub must come from glosowanie via poselId, which prevents misuse.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered by structured data. The description adds modest context – the ~2500 keyword volume, that 'wydawcy' includes act counts, and that 'tytuly' requires a phrase – but discloses nothing about response sizing, pagination, or auth that would matter for a ~2500-entry result set.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

A compact two-clause sentence that front-loads the returned vocabulary before the usage directive. No filler, though the enumerated list is dense and could be marginally tightened without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Since an output schema exists, return-value format needn't be restated, and the description covers what the enum values mean plus the call ordering relative to szukaj_aktow. For a two-parameter read-only lookup this is essentially complete, with only the enumeration/response-size detail left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50% and the enum parameter has no schema description, so the description carries real weight by mapping each enum value (rodzaje, statusy, instytucje, slowa_kluczowe, powiazania, wydawcy, tytuly) to its meaning. It also reinforces that 'tytuly' needs a fraza, which the schema notes but the description corroborates in context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (permissible lookup values for act searching) and enumerates exactly what it returns: act types, statuses, institutions, keywords (~2500), relation types, publishers, and title suggestions. This clearly differentiates it from the search sibling szukaj_aktow, so an agent knows it is a vocabulary/dictionary endpoint rather than a query endpoint.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs 'Użyj, zanim podasz słowo kluczowe albo rodzaj do szukaj_aktow' – a clear trigger condition tied to the named sibling szukaj_aktow, which is the strongest form of routing guidance. There is no explicit 'when-not-to-use' statement, but the single-use case is unambiguous.

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

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

Annotations already declare readOnly/idempotent/openWorld, so safety is covered; the description goes further by disclosing result ordering (ustawy before obwieszczenia), the inclusive date semantics, and a failure mode — partial results flagged by wynikCzesciowy with an instruction to inform the user first. That is substantive behavioral context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Front-loaded with what is searched, then qualifications, then chaining and caveats. Dense and every clause carries information, though the nowelizacje caveat is reiterated in two sentences and the text is longer than strictly necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 15-parameter open search tool with an output schema, the description covers purpose, parameter nuances, result ordering, chaining to 'akt', and the partial-result failure mode. An agent has everything needed to call it correctly and to handle the response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: fraza matches title words in the dependent grammatical case (rdzeń też działa), dates od/do are inclusive, and obowiazuje reflects today's force status while statusWELI is the raw ELI status. These clarifications go beyond the schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (wyszukuje) and resource (opublikowane akty prawne in the ELI base), enumerates the act categories searched (ustawy, rozporządzenia, obwieszczenia, uchwały), and names the qualifying facets. It clearly distinguishes itself from the sibling 'akt', which is for retrieving a single act by address.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: search by title/words/year here, then pass the returned address (e.g. DU/2019/914) to 'akt'. It states the conditions where this tool is insufficient (title search misses nowelizacje) and names the exact alternative call (akt with powiazania="Akty zmieniające").

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so the bar is lower. The description adds useful operational context beyond that: the result is capped at roughly 20k characters and the remainder is retrieved via paging, and that with dates only the count of additional prints is returned unless dodatkowe=true. This is genuine behavioral detail not present in the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

One dense but front-loaded block: purpose and scope lead, then filtering nuances, then pagination, then sibling routing. Every clause carries information, though the middle section is fairly packed and could be split for scannability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With annotations covering the safety profile and an output schema present, the description need not explain return values, and it correctly focuses on filter semantics and routing. It covers the non-obvious behaviors (inclusive dates, additional-print handling, result-size paging) so an agent can call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so a baseline of 3 already applies, but the description goes further by explaining semantics the schema only labels: the doreczenia-vs-dokumentu date choice (including that it drives the 'week's prints' interpretation) and the number-phrase matching behavior of fraza. This meaningfully enriches what the enum and patterns convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource up front: searching parliamentary prints of a term by title words and date, enumerating the content types (projekty, sprawozdania, opinie, autopoprawki, informacje) and the sort order (od najnowszych). It also routes to siblings at the end (druk for details, proces for the legislative path), so an agent can distinguish it from szukaj_projektow or szukaj_pism.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear conditional guidance: dates are inclusive and default to delivery date ('doreczenia') while 'dokumentu' filters by drafting date; phrases with a print number (e.g. "autopoprawka 2865") surface related prints; additional prints are counted via razemDodatkowych or listed with dodatkowe=true. It names sibling tools for follow-up (druk, proces), though it does not frame explicit when-not-to-use conditions versus those siblings.

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

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.

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.

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.

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.

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.

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.

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

Annotations declare the safe-read profile (readOnly, idempotent, non-destructive), and the description adds substantial value beyond them: the 21-day deadline status model (odpowiedziano/w terminie/po terminie), the poTerminieU addressee list, the adresat scoping subtlety, and the partial-result behavior (wynikCzesciowy) with an instruction to surface it. This is rich behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

A single dense paragraph that front-loads purpose before the special-case behaviors. Nearly every sentence carries useful information, though the paragraph is long enough to benefit from slight structuring.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Because an output schema exists, return values need not be explained, yet the description still flags the key derived field (wynikCzesciowy) and status semantics. Combined with the annotations and 11 fully described params, an agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 semantic value the schema lacks: how adresat changes status/delay to apply ONLY to that addressee, and how sortuj="opoznienie" reorders results. These are cross-parameter behaviors not expressible in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ("Wyszukuje") and resource ("interpelacje albo zapytania pisemne w rejestrze Sejmu"), and enumerates the search dimensions (author, addressee, title word, date). This clearly distinguishes the tool from siblings like pismo (detail view) or szukaj_drukow. An agent can identify the tool 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete usage routing: for "which are most late" use sortuj="opoznienie", and default ordering is newest-first. It also clarifies the adresat scoping case. It stops short of explicitly naming alternative sibling tools for author lookup or dispute detail, so it is clear context without full when-not/alternative guidance.

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

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

With annotations covering read-only/idempotent/open-world safety, the description adds real operational context: ~20k character result cap, pagination, and a partial-result failure mode ('wynikCzesciowy') with the instruction to warn the user upfront. The pagination hint 'przesuniecie=nastepnePrzesuniecie' is muddled against the schema's integer type, keeping this from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Purpose and core scoping are front-loaded, and each sentence carries substantive information about dates, states, and pagination. It is long and dense for a tool description, and the agent-directed instruction about the opening line of the reply sits awkwardly inside a tool spec.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter, mostly-optional search tool with an output schema, the description covers the interpretive gaps the schema cannot: date-window semantics, state semantics, colloquial-query behaviour, pagination, and partial-result handling. Nothing an agent needs to call it correctly appears missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so baseline is 3, but the description adds cross-parameter meaning the schema lacks: the default date semantics of od/do (start, closure, or last registry change, inclusive) and how wedlugDaty narrows it. It also clarifies stan counts by state across the whole term and that the phrase may be colloquial.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Wyszukuje procesy legislacyjne') and enumerates exactly what can be matched: phrase in title OR description, document type, state, and date. It also names the sibling it is not ('Głosowanie końcowe i etapy daje narzędzie proces'), so an agent can route without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete when-to-use guidance tied to question types ('Pytasz o ustawę? Dodaj rodzajDokumentu=...', 'tego wymagają pytania „ile ustaw…”') and routes voting/stage questions to the sibling 'proces'. It lacks explicit when-not-to-use conditions (e.g. versus szukaj_projektow or szukaj_drukow), so it stops short of a 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuine behavioral context: the stan field is limited to three registry values and 'aktywny' means only 'not withdrawn' (not 'in progress'), and that od/do refer to the receipt date, not the delivery date. That trap-avoidance is real value beyond the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

It is a single dense paragraph but front-loads the resource definition before moving to field/date caveats. Every clause carries information (who can submit, date semantics, stan/etap disambiguation, sibling routing), though the packed semicolon style makes it slightly dense for the amount of content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return format need not be described. The description covers the notable field semantics, the receipt-vs-delivery date distinction, and where to go for crossing concerns (etap, delivery). It is essentially complete for a read-only search tool, with only minor room for stating the default kadencja behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is high (83%), so the baseline is 3. The description still adds meaning beyond the schema: fraza searches in title OR description (with the note that amendment titles are identical), and it clarifies the semantic ambiguity of stan and of the od/do date range. This exceeds what the schema properties alone convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource (rejestr projektów ustaw i uchwał wniesionych do Sejmu) and enumerates the substantive content it exposes: wnioskodawca, data wpływu, numer druku, opis, consultations. An agent can tell this apart from the print-centric siblings (szukaj_drukow) and proses-centric siblings (szukaj_procesow) without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It routes the agent for adjacent needs: etap (uchwalony/opublikowany) via the proces tool by numer druku, and date-of-delivery via szukaj_drukow. That gives clear context, but there is no explicit statement of when to prefer this tool over szukaj_drukow or szukaj_procesow for the core search itself.

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

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

Opis wnosi bogaty kontekst poza adnotacjami: plik pobierany z api.sejm.gov.pl raz i trzymany na dysku, próg 20 MB bez pytania i większy za zgodą, skany oznaczane, OCR jako odczyt maszynowy oraz konieczność podania cytowania.url. Adnotacje dają tylko profil bezpieczeństwa (readOnly/openWorld/idempotent), a opis dodaje zachowanie cache, limity i przepływ zgody, co jest realną wartością.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Treść jest gęsta, ale front-loadowana od tego, czym jest narzędzie, i każdy fragment (porcjowanie, limity, OCR, reguły cytowania) ma zastosowanie. Nieco rozwlekła i łączy opis techniczny z instrukcjami redakcyjnymi, stąd nie 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Przy istniejącym output schema opis nie musi omawiać zwracanych wartości, a mimo to pokrywa workflow porcjowania, limity rozmiaru, przepływ zgody, obsługę skanów/OCR i wymogi cytowania. Dla 9-parametrowego narzędzia jest kompletny.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Przy 100% pokryciu schematu parametry są już udokumentowane, więc bazowy poziom to 3. Opis podnosi to, pokazując semantykę międzyparametrową: sposób łączenia stron/artykul przy porcjowaniu oraz zależność zgoda–potrzebnaZgoda (zgoda tylko po wcześniejszym pytaniu).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Stany jednoznacznie czasownik+zasób: pełny tekst druku sejmowego, strona po stronie, z PDF/DOCX/DOC, ze spisem treści i numerami stron. Wyraźnie odróżnia się od sąsiadów typu druk (metadane) i szukaj_drukow (wyszukiwanie), bo opisuje pobranie i odczyt treści dokumentu.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Daje konkretny kontekst użycia: duże druki pokazywane porcjami (najpierw spis i pierwsze strony, potem strony="11-20" albo artykul="52") oraz reguły cytowania i parafrazowania. Nie wymienia jednak wprost alternatyw ani warunków 'kiedy nie używać' względem rodzeństwa, więc brakuje pełnej 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered structurally. The description adds that results include player links and clarifies the available query modes, but says nothing about pagination behavior or result ordering beyond what the schema implies.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two tight sentences front-load the resource and enumerate the query modes efficiently. Nothing feels padded, though the enumeration reads as a list rather than a prioritized summary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 9 optional parameters all documented, a full output schema, and annotations covering the safety profile, the description needs only to orient the caller, which it does. Minor gaps remain around sibling differentiation and pagination, but the tool is callable as described.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter (including data, od/do, komisja, fraza, dzis) is fully documented in the schema. The description names the same query axes (single day, range, committee code, title word, today) but adds no syntax or behavioral detail beyond the schema, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (recordings and broadcasts of Sejm sessions, committees, and events) with the concrete payoff of player links, which distinguishes it from session/general tools. It does not, however, explicitly differentiate itself from close siblings like lista_posiedzen or posiedzenia_komisji, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It implicitly tells the agent which query modes are available (single day, date range, committee code, title word, today's broadcasts), which is useful. But there is no explicit when-to-use guidance versus alternatives and no exclusions, leaving the agent to infer the choice among overlapping sibling tools.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safe-read profile is covered. The description adds one genuinely useful behavioral fact beyond the schema: output is returned in ~12,000-character chunks, implying pagination. It does not say how an agent knows more content remains or that the od parameter continues the read.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

A single front-loaded sentence stating what is returned (statement text), in what form (plain text), and at what granularity (12k-character chunks). No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter read tool with an output schema, return values need not be explained. The main remaining gap is the retrieval workflow: the description mentions chunking but never tells the agent to reuse od to fetch subsequent chunks, nor points to wypowiedzi_posiedzenia for obtaining numer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 80%, so the schema already documents od, data, numer and kadencja in Polish. The description only implicitly touches the od/pagination parameter via 'w porcjach po 12 tys. znaków' and adds no format or syntax detail beyond the schema. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb+resource: fetching the full text of a single Sejm transcript statement, as plain text. The phrase 'jednej wypowiedzi' implicitly contrasts with the sibling wypowiedzi_posiedzenia (which lists statements), though that differentiation lives mainly in the schema's numer description, not in the prose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when/when-not statement or named alternative in the description; usage is only implied by 'jednej wypowiedzi' and the mention of chunking. The cross-reference to wypowiedzi_posiedzenia as the source of the numer value appears only in the parameter schema, not here.

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

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

Ujawnia istotne cechy poza adnotacjami: wolne działanie dla starszych dni (kilkanaście sekund), możliwy niepełny wynik z polem wynikCzesciowy i instrukcję powiadomienia użytkownika, ograniczenia filtrów (do 10 wypowiedzi, 40 sprawozdawców) oraz zachowanie przy braku daty.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Informacje są gęste i dobrze uporządkowane, ale tekst jest długi i miejscami wielowątkowy. Każde zdanie wnosi wartość, choć całość mogłaby być nieco bardziej zwięzła.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Przy 8 parametrach, bogatym schemacie i istniejącym output schema opis uzupełnia wszystkie krytyczne aspekty: tryby działania, filtry, ograniczenia, zachowanie przy błędach i wskazówki dla użytkownika.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema ma 88% pokrycia opisami, więc baseline to 3. Opis dodaje jednak semantykę wykraczającą poza schemat: co dokładnie filtruje mowca, jak działa zestawienie, co oznaczają null i uwaga przy braku punktu porządku obrad.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Precyzyjnie określa zasób (spis wypowiedzi z jednego dnia posiedzenia) i wyliczа zwracane pola (numer, mówca, funkcja, godziny, status sprawozdawcy). Wyraźnie odróżnia tryb domyślny od trybu zestawienie, co pozwala odróżnić narzędzie od siblingów typu glosowania_posiedzenia czy tresc_wypowiedzi.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Podaje konkretny warunek użycia zestawienie=true (pytanie „kto najczęściej zabierał głos”) oraz wskazuje tresc_wypowiedzi jako źródło treści wystąpień. Wyjaśnia też, kiedy filtr mowca jest właściwy, a kiedy mylący (szuka po nazwisku, nie temacie).

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description goes beyond them by disclosing that the response is raw with no verdicts or counting rules, and by naming resources that do NOT exist (gender, demographics, presidium list), which prevents wasted off-target queries. It does not detail pagination/rate limits, keeping it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The block is long, but it is front-loaded with purpose, then the fallback constraint, then supporting detail. For an open-ended path parameter, the resource enumeration genuinely earns its place, though the density makes it less immediately scannable than an ideal definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present (so return values need not be described) and annotations covering the safety profile, the description supplies everything else an agent needs: when to use it, which paths are valid, and what it must not be used to infer. Nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description meaningfully enriches 'sciezka' by enumerating the valid resource families (MP, clubs, committees incl. subcommittees, proceedings, votings, prints, processes, bills, videos, ELI acts/references/struct/types) rather than just the schema's single example. It adds no extra meaning for 'od' or 'parametry', so it does not reach 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: fetching arbitrary JSON from the Sejm API tree (paths under /sejm/ or /eli/), with concrete example paths. It also explicitly positions itself against siblings via 'Używaj tylko wtedy, gdy żadne inne narzędzie nie pasuje', so an agent can tell it apart from all the purpose-built tools 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit selection rule (use only as a fallback when no other tool fits), a when-not constraint (do not compute attendance or vote results from this raw output), and even routes a specific unmet need (Sejm presidium/marshal) to the alternative szukaj_glosowan with a suggested query phrase. This is near-complete routing guidance.

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

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

Goes well beyond the readOnly/idempotent/openWorld annotations: it warns that 'klub' is TODAY's affiliation not the historic one, explains the slubowaliPozniejWOkregu/wygasliWczesniejWOkregu fields for expired and mid-term mandates, and clarifies the glosowWWyborach count and sortuj='glosy' ranking. Rich disambiguation of a politically subtle data model.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Front-loads the core search purpose, then layers special-case semantics in subsequent sentences; each sentence conveys distinct information. It is dense with parenthetical fields but earns most of its length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter search tool with a high-coverage schema and an output schema, the description supplies exactly the missing behavioral context (today-vs-historic club, mandate-expiry edge cases, sort semantics) an agent needs to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds cross-parameter meaning the schema cannot convey: okreg + sortuj='glosy' yields a district ranking, and tylkoWygasle returns a count broken down by reason. It does not re-explain syntax already in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Szuka) and resource (posłów) plus the three lookup dimensions (name, club, district) and the key output (the id other tools need). An agent can immediately tell this is the roster-search entry point distinct from profil_posla.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly frames itself as the tool that yields the 'numer posła (id), którego wymagają inne narzędzia', which routes the agent to it before calling detail tools. Lacks explicit when-not-to-use or a named sibling alternative, so it stops short of a 5.

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