Proces legislacyjny: etapy

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.