ezd_rejestr_case_metrics

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds minimal context about the source ('rejestr spraw EZD PUW') but does not disclose output shape, error behavior, authorization needs, or any operational constraints. Given the annotations, this is an acceptable but not rich 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?

One concise, front-loaded sentence communicates both the tool's purpose and the key prerequisite. There is no filler or repetition of schema details that are already visible in the input 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?

Given there is no output schema, the description could have explained what 'metrykę sprawy' contains or what the response looks like. It also lacks any guidance about sibling alternatives. However, the tool is a read-only metrics retrieval with a fairly self-explanatory purpose, so the description is minimally viable but not 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?

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema by stating that at least one of Rpw or ZnakSprawy is required, which is a critical constraint not encoded in the schema's required field. This clarifies how to construct a valid call. Could go higher but it does not explain precedence or exact format of those identifiers.

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 uses a specific verb ('Pobierz' / get) and a concrete resource ('metrykę sprawy z rejestru spraw EZD PUW'), so the core purpose is clear. It does not explicitly differentiate itself from sibling getter tools such as ezd_api3_get_case or ezd_api3_get_last_case_changes, so it stops short of full sibling distinction.

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 a parameter requirement ('Wymagany jest co najmniej jeden z parametrow: Rpw lub ZnakSprawy') but gives no guidance on when to prefer this tool over alternatives, nor any exclusion or fallback conditions. An agent has no help choosing between this and the many case-related siblings.

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