strajkpolski-mcp

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

Annotations already indicate readOnlyHint=true and openWorldHint=true, so the description does not need to repeat that. It adds value by stating the return type ('fragmenty z oceną podobieństwa'), which is behavioral context beyond the annotations. However, it does not disclose any side effects, data freshness, or error behavior.

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 sentence, which is highly concise and front-loaded. It efficiently conveys the core functionality and return value without extraneous text.

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 3 parameters, 0% schema coverage, no output schema, and a specific domain (Strażku Polskiego knowledge corpus), the description lacks completeness. It does not explain the 'source' parameter or default behavior of 'limit', and the return structure is only vaguely described as fragments with scores. More details are needed for proper invocation.

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 input schema has 0% description coverage, and the description provides no information about the parameters (limit, query, source). It only implies the purpose of 'query' through the search context. Without any explanation of 'source' or 'limit', the description fails to compensate for the schema's lack of documentation.

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 performs semantic search (semantyczny search) on the knowledge corpus of Strajku Polskiego, and returns fragments with similarity scores. This specifies the verb and resource, but does not explicitly differentiate it from sibling search tools like search_cytaty or search_poslowie, though the tool name 'ask_strajk' implies a conversational RAG interface.

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?

No guidance is provided on when to use this tool versus alternatives. The description lacks context about appropriate scenarios, prerequisites, or conditions where the tool should be avoided. Given the presence of multiple search siblings, explicit usage guidelines are missing.

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?

The description adds the behavioral context that the data is 'live' from a government source, which is beyond the readOnlyHint and openWorldHint annotations. It does not detail potential size or update frequency, but for a simple read tool this is adequate.

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 sentence that is front-loaded with the core purpose. Every word contributes value, with no redundancy or 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?

Given the tool has no parameters, no output schema, and annotations already cover safety, the description is mostly complete. It conveys the content (full budget table with categories) and source (live gov.pl/MF). One could argue it could mention that the response might be large or how to interpret the data, but for a straightforward read operation, it suffices.

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?

There are no parameters, and the schema coverage is 100%. The description does not need to explain parameters, and it adds no unnecessary information. For a zero-parameter tool, this 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 clearly states it returns the full state budget table with expense categories from a live source (gov.pl/MF). It uses specific verb 'get' and identifies the resource, distinguishing it from siblings like get_budzet_pozycja which likely targets a specific item.

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?

No explicit guidance on when to use this tool versus alternatives is provided. The implication from the sibling list and description is that this tool is for the full budget, while get_budzet_pozycja is for a specific line item, but there is no direct statement of when to use or not use this tool.

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 and openWorldHint=true. Description adds no behavioral details beyond stating it retrieves by ID. No contradiction, but no additional transparency value beyond 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?

Single sentence, front-loaded, no wasted words. However, it is extremely terse and could benefit from slightly more structure or detail.

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 no output schema and simple input, the description is minimally adequate. It tells what the tool does but omits what the response contains. For a simple get tool, this may suffice, but completeness is limited.

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 0%, so description must compensate. It only mentions 'po id' (by ID), which adds minimal meaning beyond the parameter name. Does not specify format, source, or constraints of the ID.

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?

Description clearly states it retrieves a single budget item by ID. The name 'get_budzet_pozycja' combined with the description 'Pojedyncza pozycja budżetu po id' leaves no ambiguity. It distinguishes from sibling 'get_budzet' (likely a list) by specifying single item retrieval.

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?

No explicit guidance on when to use this tool versus alternatives. The usage is implied by the name and description (use when you have a budget item ID), but no exclusions or alternative tools are mentioned.

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?

The description adds behavioral context beyond annotations: it specifies the exact data points returned (debt amount, service cost, tempo, sources). Annotations already indicate read-only and open-world, so the description complements them well.

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 extremely concise, using a single sentence to convey key data points and sources. Every part is relevant with no redundancy.

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 tool, the description adequately explains what is returned (debt value, service, tempo, sources). There is no output schema, so the description bears the burden, and it meets it reasonably well, though it could be more explicit about the response format.

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?

There are no parameters, so the baseline is 4. The description does not add parameter info but is not required to. It appropriately focuses on the tool's output.

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 the tool provides Polish public debt information including total amount, annual service cost, rate of increase, and sources. It is specific and distinguishes it from sibling tools like get_budzet.

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 does not explicitly state when to use this tool versus alternatives. While sibling tools exist for other government data, no guidance is given on when to choose get_dlug over them.

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 and openWorldHint=true, so the description adds limited behavioral info beyond stating the return content. It does not disclose error handling, authentication, or rate limits, but the annotations cover the safety profile adequately.

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 extremely concise: two sentences that directly state the purpose and parameter format. Every word adds value with no redundancy.

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?

While the description covers the input format and basic output (single voting + club distribution), it lacks detail on the output structure. Since there is no output schema, the description should ideally describe the fields returned for the voting and clubs.

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 schema only defines id as a required string with no description (0% coverage). The description fully compensates by specifying the format 'kadencja.posiedzenie.numer' with an example, adding essential meaning beyond 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?

The description clearly states the tool returns a single voting with its club distribution, using the verb 'pojedyncze głosowanie + rozkład po klubach'. This distinguishes it from siblings like get_glosowanie_razem (likely aggregated) and search_glosowania (search).

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 the exact format for the id parameter with an example, which helps in constructing the request. However, it does not explicitly state when to use this tool versus its siblings, though the distinction is implied by the sibling names.

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 and openWorldHint. The description adds minimal behavioral context beyond the computed metrics. No contradictions.

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, concise sentence. It is front-loaded and free of fluff, though it sacrifices completeness for brevity.

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 no parameter descriptions, no output schema, and only a hint of return fields, the description fails to provide enough context for an agent to fully understand usage and expected results.

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 0% and the description does not explain what posel_a and posel_b represent (e.g., deputy IDs). The overall context hints they are deputies, but no explicit parameter semantics.

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 the tool computes voting consistency of two deputies and lists output fields (agreed_pct, common_votes). It distinguishes from siblings like get_glosowanie by focusing on pairwise comparison.

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?

No guidance on when to use this tool vs alternatives such as get_glosowanie or search_glosowania. The description does not mention prerequisites or when not to use 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 readOnlyHint=true and openWorldHint=true, covering safety and data volatility. The description adds that the tool retrieves a specific metric (annual salary cost), which aligns with the read-only nature. No contradiction or missing behavioral context.

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, well-structured sentence that conveys the essential information without any extraneous words. It is front-loaded with the key concept ('annual cost of salaries').

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 read-only tool with annotations, the description is fully adequate. It tells the agent exactly what data is returned, and the sibling tools provide context for differentiation. No additional details are necessary.

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 has zero parameters, and the schema coverage is 100%. The description clarifies that no parameters are needed and that it returns a specific aggregate value. This satisfies the baseline expectation for parameterless tools.

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 explicitly states the tool returns the total annual cost of government salaries. It uses a specific verb ('get') and clear resource ('cost of salaries'), distinguishing it from sibling tools like get_budzet (budget) and get_dlug (debt).

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 no guidance on when to use this tool versus alternatives. It does not mention scenarios where other tools (e.g., get_budzet) would be more appropriate, nor does it specify any prerequisites or limitations.

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 provide readOnlyHint and openWorldHint, but the description adds no behavioral details (e.g., whether results are static, authentication needs, or format). It carries no extra 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?

The description is a single sentence with no redundancy. It is front-loaded and efficient, though note the language is Polish.

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 no output schema and no parameter complexity, the description should at least hint at the return format. It does not; the purpose is vaguely clear but incomplete (e.g., does it return plain text or 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?

There are no parameters, and schema coverage is 100%, so the description need not explain parameters. Per guidelines, 0 parameters yields a baseline of 4.

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 it returns '9 postulatów Ogólnopolskiego Strajku Narodowego', clearly identifying the resource (specific manifest). However, it does not specify whether it returns the full text or a list, and it is in Polish, which may reduce clarity for non-Polish agents.

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?

No guidance is provided about when to use this tool versus sibling tools like get_budzet or search_poslowie. The description lacks context on prerequisites or 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 readOnlyHint=true (safe read) and openWorldHint=true (dynamic data). The description adds specific fields returned, which is useful beyond annotations. No mention of authentication or rate limits, but for a read-only tool this is reasonable.

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?

Single sentence with parenthetical list. Concise and front-loaded with the core action. Could be slightly improved by structuring the list, but no unnecessary words.

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 simple get-by-id tool with one parameter and no output schema, the description is fairly complete: it names the resource and lists return fields. Annotations provide safety context. Missing details on data update frequency or edge cases, but overall adequate.

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 input schema has one parameter 'id' with no description (0% coverage). The description only says 'po id' (by id) without elaborating on the type or format of the ID. For a single-parameter tool, more context would help, such as 'numeric deputy ID'.

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 deputy by ID and lists the data fields (attendance, votes, salary+allowance, email, club). This distinguishes it from sibling tool 'search_poslowie' which searches for multiple deputies.

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?

Implied usage: use when you have a deputy ID and need details. No explicit when-not or alternatives mentioned, though sibling 'search_poslowie' is a natural alternative for searching by name. Minimal guidance but adequate for a simple tool.

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?

The description mentions bilingual content but does not clarify behavior beyond the annotations (readOnlyHint, openWorldHint). It adds minimal value.

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 short but poorly structured, mixing languages and unclear terms. It is not effectively concise.

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?

The description is entirely inadequate for a tool with no parameters or output schema. It does not tell the agent what 'skills' are or how the tool can be used.

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 zero parameters, the description should explain what the tool returns. Instead, it offers only a cryptic phrase, failing to compensate for the lack of schema detail.

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 '44 skille bilingual PL+EN (fact-packi o polskim państwie)' is garbled and unclear. It suggests skills but doesn't specify what the tool retrieves or how it differs from siblings.

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?

No guidance on when to use this tool instead of siblings like get_posel or get_manifest. The description provides no context for selection.

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 provide readOnlyHint=true and openWorldHint=true, covering safe read and dynamic data. The description adds 'Live' but does not disclose additional traits such as caching, rate limits, or response format. It adds minimal value beyond 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?

The description is a single sentence with no unnecessary words. It is appropriately concise and 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?

Given no parameters and good annotations, the description is largely complete, but it lacks information about the output format (e.g., JSON structure). With no output schema, the agent cannot anticipate the response shape. Minimal but adequate for a simple counter.

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?

No parameters exist (schema is empty), so baseline 4 applies. The description and schema fully cover parameter information as there are none to document.

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 provides a live counter of participants of a specific strike (Strajk Polski). The verb 'get' and resource 'strajkujacy' are specific. However, the title is missing and the description is in Polish, which may reduce clarity for non-Polish agents. It distinguishes from siblings since others cover budgets, deputies, etc.

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?

No guidance on when to use this tool versus alternatives. No context about prerequisites, limitations, or when not to use. The description only states what it does, offering no usage direction.

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 and openWorldHint. The description adds scale information (350 positions, 54 institutions) and filter options, but does not disclose pagination, default ordering, or response structure beyond the listed 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?

The description is a single concise sentence with no fluff, efficiently conveying the tool's purpose and key filters.

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?

Despite having annotations and sibling context, the description lacks details on return format, field semantics, and parameter constraints. With no output schema, an agent cannot reliably 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?

With 0% schema description coverage, the description must compensate. It names two filters (role_type, entity) but does not explain their values, format, or usage. The 'limit' parameter is not mentioned at all.

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 is a 'map of government' with ~350 positions and 54 institutions, listing fields like role, club, salary. It distinguishes from sibling search tools (e.g., search_poslowie, search_glosowania) which target different entities.

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 implies usage for administrative positions and mentions available filters, but does not provide explicit guidance on when to use this tool over alternatives or specify prerequisites.

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 and openWorldHint=true, so the safety profile is clear. The description adds context that the tool searches political quotes from interpellations/speeches, but no further behavioral traits (e.g., pagination, result format) are disclosed.

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 short but inefficiently structured: a single sentence followed by a bare list of parameter names. It lacks sections or formatting that would improve 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 six optional parameters, no output schema, and multiple sibling tools, the description is inadequate. It does not explain return values, filter combination logic, or pagination, leaving significant gaps for an agent.

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 0% schema description coverage, the description must compensate but only lists parameter names (query, topic, klub, category, posel_id) without explaining their semantics or value ranges. For example, 'klub' likely means political club but is not defined.

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 searches quotes of politicians (interpellations/speeches), which is specific and not a tautology. However, it does not explicitly differentiate from sibling search tools like search_poslowie or search_glosowania, leaving room for confusion.

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?

No guidance is provided on when to use this tool versus alternatives. The description only lists filters without any context about suitable use cases or exclusions.

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 and openWorldHint=true, so the description adds limited extra behavior context. It mentions the return fields (title, topic, vote distribution) but omits details on pagination, rate limits, or whether results are sorted. The description is adequate but not enriched beyond 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?

The description is a single, efficient sentence that front-loads key information (entity and count). It lists filters succinctly. However, it lacks a verb and could be more structured, but it earns its place with no redundant words.

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 lack of output schema, 4 parameters (none required), and the high item count, the description should provide more context about result ordering, pagination, or how 'limit' affects output. The basics are there but significant gaps remain for an AI agent to invoke the tool correctly without additional speculation.

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 0% schema description coverage, the description must clarify parameters. It names three filters (query, topic, term) but omits 'limit', and does not specify data types or formats. For instance, 'query' could mean full-text search, 'topic' might be a category, and 'term' likely refers to legislative term number. The explanation is incomplete, leaving ambiguity.

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 the tool searches Polish parliamentary votes (Głosowania Sejmu) and specifies the data fields (title, topic, vote breakdown). It differentiates from siblings like 'get_glosowanie' by the 'search' prefix and mentions the scale (3400+ entries).

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?

While the tool name 'search' implies it is for broad queries, the description provides no explicit guidance on when to use it versus siblings like 'get_glosowanie' or 'get_glosowanie_razem'. The context of use is implied but not clearly defined.

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 and openWorldHint=true, so the safety profile is clear. The description adds value by specifying the returned fields (attendance, salary, email), but it does not mention pagination behavior or other constraints like result ordering.

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, concise sentence that front-loads the key information (460 MPs, filters). It could be improved by structuring the parameter details separately, but it is efficient and avoids fluff.

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 search tool with four optional parameters and no output schema, the description should more thoroughly explain return format and filter options. It mentions three return fields but not the full shape. The contexual completeness is adequate for basic use but has clear gaps.

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 0%, so the description must compensate. It only explains two of the four parameters (klub, woj) via the filter mention, leaving limit and offset unexplained. No valid values or formats are given for the filter parameters.

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 the tool searches for 460 members of the Polish Sejm with filters by club and voivodeship. It mentions specific return fields (attendance, salary, email). This distinguishes it from sibling search tools like search_administracja and search_cytaty.

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 implies usage when filtering MPs by club or voivodeship, but it does not explicitly state when to use this tool versus alternatives like get_posel (for a single MP) or other search tools. No when-not or alternative guidance is provided.

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