ezd_koszulka_update_attributes

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'update attributes' — it does not reveal whether the Atrybuty array is a partial patch or a full replacement, what happens to attributes not listed, whether permission or ownership context is required, or what side effects occur. For a mutation tool this is a significant transparency gap, though the description does at least imply a write operation.

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 sentence with zero filler words that efficiently conveys the core action and its system context. It is front-loaded and appropriately compact; the brevity is partly a symptom of under-specification, but that is penalized in other dimensions rather than here.

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 write operation with no annotations, no output schema, and multiple overlapping siblings, a one-sentence description is not complete enough. An agent cannot determine merge-vs-replace semantics for the Atrybuty array, the response format, or when to prefer this tool over ezd_koszulka_update. The 100% schema coverage mitigates parameter confusion but leaves the behavioral and selection gaps unresolved.

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%, with all five parameters documented, including the env-based defaults for IdPracownikaWlasciciela and IdStanowiskaWlasciciela and the CID auto-generation behavior. Per the high-coverage baseline, the description need not repeat parameter details, and it does not add or omit anything meaningful. The schema carries the parameter documentation weight.

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 clear verb+resource: 'Zaktualizuj atrybuty koszulki' (update folder attributes) in the EZD PUW system. It is specific and unambiguous about what the tool does, and it closely mirrors the tool name without being a pure restatement since it adds the system-scope framing. However, it does not differentiate from overlapping siblings such as ezd_koszulka_update or ezd_api1_update_case_attributes, so it stops short of 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?

There is no guidance on when to use this tool versus alternatives. With siblings like ezd_koszulka_update, ezd_koszulka_create, and ezd_api1_update_case_attributes, an agent has no criteria to decide which update-oriented tool fits. The description is a bare statement of what the tool does, with zero when/why/exclusion information.

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