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 states the main action—creating a token—but does not disclose token validity, side effects, authorization requirements, or what the caller receives.

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, focused sentence that immediately communicates the core action and object. There is 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?

With no annotations, no output schema, and a terse description, the tool lacks behavioral and usage context needed for reliable invocation. The schema covers parameters, but the description does not explain token behavior, return value, or operational context beyond the bare action.

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 parameter documentation already explains IdDokumentu, IdZalacznika, and the defaulting owner parameters. The description adds no extra parameter-level context beyond the schema, so the baseline score of 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 clearly states the verb 'Utworz' (create), the resource ('token edycji pliku' / file edit token), and the system (EZD PUW). This also distinguishes it from siblings like ezd_addin_create_print_token by specifying the edit-purpose token.

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 by the name and description: use this tool when a file edit token is needed. However, there is no explicit guidance on when to prefer this over related token or Add-in tools, nor any mention of exclusions or 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?

No annotations are provided, so the description carries the full disclosure burden, and it only states that a token is created. It does not disclose whether the token is persisted, its validity/lifetime, whether it requires prior setup of env variables, what the caller receives back, or whether the operation has side effects. The phrase 'przez Addin w systemie EZD PUW' gives system scope but no behavioral detail.

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 Polish sentence with no filler or repetition; the verb and object are front-loaded. Every word earns its place. The terseness that hurts other dimensions is not a structure problem here — the text is appropriately compact for the information it conveys.

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 tool is part of a print-token workflow with closely related siblings, yet the description does not explain how the token is used, what the return value looks like, or how this call fits with the other addin print tools. With no output schema and no annotations, the missing return-format and workflow context leaves an agent guessing. The 100% parameter coverage mitigates but does not compensate for these 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 100%, so the input schema already documents all four parameters including sensible defaults (CID auto-generated, owner worker/position IDs falling back to environment variables). The description adds zero parameter-level meaning and does not need to. Baseline 3 applies because 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?

Description states a specific verb (Utworz — create), a specific resource (token do druku — print token), and the system scope (EZD PUW via Addin). The token type 'do druku' differentiates it from the sibling ezd_addin_create_file_edit_token, though it does not name any sibling explicitly. Clear enough for an agent to know what the tool produces.

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 given on when to use this tool versus alternatives such as ezd_addin_create_file_edit_token or the other print-workflow siblings (ezd_addin_get_attachment_for_print, ezd_addin_get_doc_ids_for_print). There is no mention of prerequisites, the expected print workflow, or exclusions. Usage context must be inferred entirely from the tool name and parameter schema.

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 readOnlyHint annotation already indicates this is a safe read operation, and the description adds little behavioral context beyond that. It does not disclose output format, token requirements beyond the schema, or any side effects, and it relies almost entirely on the annotation for safety understanding.

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 compact sentence with no filler or redundancy. It is appropriately front-loaded and easy to parse, though it lacks any structural breakdown such as usage context or workflow hints; still, it earns high marks 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?

For a tool with no output schema and a required authorization token, the description omits important operational context. It does not explain what the tool returns, how the PrintToken should be obtained, or that this tool is part of a multi-step printing flow together with related Addin tools.

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 each parameter having a meaningful Polish description. The tool description itself adds no parameter-level detail, so the schema carries the full burden, which aligns with the baseline of 3.

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 action ('Pobierz' / download), the resource (attachment for printing), and the system context (EZD PUW via Addin). It does not explicitly differentiate itself from sibling tools like ezd_addin_get_doc_ids_for_print or ezd_addin_create_print_token, 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?

There is no guidance about when to use this tool versus alternatives. It does not mention that a PrintToken must first be created via ezd_addin_create_print_token, nor how it relates to ezd_addin_get_doc_ids_for_print, leaving the agent to infer the workflow.

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 readOnlyHint annotation already communicates that this is a safe read operation, and the description adds no behavioral detail beyond that. It does not describe the return format, whether a list of IDs is returned, or anything about the token lifecycle or side effects.

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 no filler or redundancy; the key operation and object are front-loaded. It is concise without losing clarity for this simple read-only tool.

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 definition is minimally viable because the schema covers parameter semantics and the annotation covers safety. However, with no output schema, the return shape is not specified, and the description does not situate the tool within the print token/attachment workflow.

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 already has a meaningful description in the input schema. The tool description itself contributes no additional parameter context, which is acceptable under the high-coverage baseline.

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 operation ('Pobierz' — fetch) and a concrete resource ('identyfikatory dokumentow do druku' — document identifiers for printing), scoped to the Addin/EZD PUW context. It is clear, though it does not explicitly differentiate itself from siblings like ezd_addin_get_attachment_for_print or ezd_addin_create_print_token.

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 about when to call this tool, whether a PrintToken must first be obtained via ezd_addin_create_print_token, or which sibling to prefer in different scenarios. The phrase 'przez Addin' only establishes context, not selection criteria.

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 are absent, so the description carries the full behavioral burden. It states only that a form is created, but it does not disclose side effects, preconditions, permission requirements, defaulting behavior, or reversibility. 'Utworz' suggests mutation but adds little beyond the tool name.

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 filler and the action is front-loaded. It is compact, though so terse that it leaves behavioral and contextual details unstated.

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 mutation tool with no annotations and no output schema, one sentence is insufficient. It leaves unclear what entity the created form attaches to, what the API returns, and what preconditions apply (e.g., that the case cover must already exist).

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%, and each parameter has a description in the input schema, so the baseline is 3. The description adds no additional parameter-level meaning; all relevant semantics are already present 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?

The description uses a clear verb ('Utworz'/'create') and identifies a specific resource ('formularz koszulki sprawy' — case cover form) plus the API context ('przez API1'). However, it does not differentiate from the sibling tool ezd_formularz_create_case_form or other related create/update tools, so it doesn't full reach 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?

No when-to-use or when-not-to-use guidance is provided. It does not mention prerequisites (e.g., an existing IdKoszulki) nor contrast with the sibling ezd_formularz_create_case_form, leaving the agent to infer the appropriate context from the name.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool creates a worker; it does not mention authentication requirements, side effects, whether existing data is overwritten, or what response to expect. For a mutation tool, this is a significant transparency gap.

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 short sentence with no filler or repetition. It is efficiently worded and front-loaded with the action, though it is too sparse to provide broader operational context.

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 tool with 11 parameters, no output schema, and no annotations, the description is inadequate. It fails to explain which parameters are essential for a meaningful create operation, what the tool returns, or how API1 creation differs from other employee-creation tools in the sibling list.

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 all 11 parameters are already described with meaningful Polish labels. The description itself adds no parameter-level information, but the schema does the heavy lifting, meeting the baseline of 3.

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 a specific action and resource: 'Utwórz nowego pracownika' (create a new worker) through API1 in the EZD PUW system. While the verb is specific, it does not distinguish from the closely related sibling ezd_pracownik_add, which also appears to create an employee.

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 instead of the many sibling tools, particularly ezd_pracownik_add, ezd_api1_update_worker, or ezd_api1_delete_worker. No conditions, prerequisites, or exclusions 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only communicates that the tool creates something; it does not disclose permissions required, side effects, idempotency, or what happens on duplicate submissions.

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 wasted words. The phrase 'przez API1' is slightly redundant with the tool name, but the overall structure is clean and front-loaded with the core action.

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 annotations and no output schema, the one-sentence description is insufficient for an agent to fully understand the operation's context. It does not describe return values, validation behavior, ownership defaults beyond the schema, or how this creation interacts with existing workflow templates.

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 each parameter already documented, including the default behavior for IdPracownikaWlasciciela and IdStanowiskaWlasciciela. The tool description adds no additional parameter-level meaning, so the baseline score of 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 clearly states a specific action: 'Utworz szablon obiegu pracownika' (create an employee workflow template) via API1. The create verb distinguishes it from sibling tools like ezd_api1_update_workflow_template and ezd_api1_delete_workflow_template, though it does not explicitly name those alternatives.

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 gives no guidance on when to use this tool instead of the related update/delete/get workflow template tools. It also does not mention prerequisites, such as whether the employee must already exist or what distinguishes a workflow template from a transfer-by-template operation.

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 destructiveHint annotation already signals destructive behavior, and the description confirms the target is a worker. However, it does not disclose irreversibility, cascading effects, or permission requirements beyond what the annotation 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?

The description is a single, action-first sentence with no wasted words. The phrase 'przez API1' is slightly redundant with the tool name but does not significantly hurt clarity.

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 minimal and leaves ambiguity about which worker is being deleted and how this tool differs from ezd_pracownik_delete. No output schema or additional behavioral context is provided, so an agent may struggle to select it confidently among similar siblings.

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 parameters are already well documented, including auto-generation and environment defaults. The description itself adds no parameter-level meaning, which is acceptable given the schema coverage.

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 ('Usun') and resource ('pracownika') with system context ('EZD PUW'), making the core action clear. It does not explicitly differentiate from the sibling ezd_pracownik_delete, but the 'API1' reference provides some 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?

No guidance is given on when to use this tool versus ezd_pracownik_delete or other worker-related tools. There are no conditions, prerequisites, or exclusions stated.

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 destructiveHint annotation already communicates the destructive nature, and the description confirms the target object (employee workflow template). However, it does not disclose additional behavioral details such as irreversibility, cascading effects, or permission requirements.

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, front-loaded sentence that clearly communicates the core action and object. The phrase 'przez API1 z systemu EZD PUW' is somewhat redundant given the tool name, but it does not significantly bloat the description.

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 destructive tool with no output schema, the annotations and fully documented schema cover much of the operational context. Still, the description lacks guidance on deletion consequences, prerequisites, and which workflow template is selected when owner IDs are omitted, leaving some 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?

The input schema already provides 100% description coverage for all three parameters, including defaults and the auto-generated correlation ID. The tool description adds no additional parameter-level meaning, so the baseline of 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 clearly states the action ('Usun' = delete) and the specific resource ('szablon obiegu pracownika' = employee workflow template), and mentions the API path ('przez API1'). It distinguishes itself from sibling create/update/get_workflow_templates tools because it names deletion specifically.

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, no prerequisites are stated, and there is no indication of what conditions must hold before deletion. The intended use is only implied by the verb 'delete'.

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 readOnlyHint annotation already communicates that this is a read-only operation. The description adds little behavioral context beyond that: 'przez API1' and 'w systemie EZD PUW' are contextual identifiers, not disclosures about output, error behavior, or side effects.

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, direct sentence with no fluff, and the core action is front-loaded. It is efficient but perhaps too sparse to fully inform an unfamiliar agent.

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 tool is a simple read operation with three optional, fully documented parameters, and the readOnlyHint covers safety. However, there is no output schema, and the description only vaguely implies the return ('dane pracownika') while ignoring the crowded sibling context, so completeness is moderate.

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?

All three parameters are fully described in the input schema (100% coverage), so the description doesn't need to compensate. It adds no extra meaning beyond the schema, such as explaining when the environment-variable defaults apply.

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 action: 'Pobierz dane pracownika' (get employee data) via API1 in EZD PUW, which gives a specific verb and resource. However, it does not differentiate from sibling worker getters like ezd_pracownik_get, ezd_pracownik_get_by_unit, or ezd_pracownik_get_all, so an agent must infer what makes the API1 variant unique.

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 instead of the many alternative worker retrieval tools. The description offers no scenarios, prerequisites, or exclusions, leaving the selection entirely to the agent's 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?

The annotation readOnlyHint=true already communicates the safe read-only nature, and the description's 'Pobierz' agrees with that. However, the description adds little beyond the annotation: it does not mention response shape, permissions, pagination, or error behavior, though for a simple retrieval tool this is a moderate gap, not a contradiction.

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 compact sentence that conveys action, object, API, and system with no filler. It is appropriately sized for a low-complexity read-only tool and front-loads the core operation.

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 read-only listing tool with fully documented optional parameters, the description is mostly adequate. However, with no output schema and no mention of return format or pagination, plus the confusing near-duplicate sibling ezd_pracownik_get_workflow_templates, the definition leaves some contextual 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?

All three parameters are fully described in the input schema, including auto-generation of CID and defaulting of worker/position IDs to environment variables. The description itself adds no parameter-specific meaning, so the baseline of 3 applies because the schema carries the semantic burden.

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 ('Pobierz' = get), a clear resource ('szablony obiegu pracownika' = employee workflow templates), and the API context ('przez API1' in EZD PUW), so an agent can identify this as a retrieval operation. It does not distinguish itself from the sibling tool ezd_pracownik_get_workflow_templates, which appears to target the same resource.

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 about when to use this tool versus ezd_pracownik_get_workflow_templates or the related API1 workflow-template creation/update/delete tools. The description only mentions 'API1' as context but does not explain selection criteria 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?

There are no annotations, so the description bears the full burden. 'Ustaw' implies a state-changing operation, but the description does not disclose side effects, persistence, permissions, or what happens to the previous view, and no output schema exists to clarify the result.

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 with no filler, and the action 'Ustaw widok formularza' is front-loaded. It loses one point for being too terse to carry the behavioral and usage context the tool needs.

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 mutation tool with no annotations and no output schema, and with a direct sibling that has almost the identical name, this one-sentence description is insufficient. The agent cannot determine when to invoke it, what the API1 distinction means, or what the call will return or change.

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 applies: the properties already document themselves. The description adds context that this is a form-view setter, but it adds no detail beyond the schema's parameter descriptions.

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 a specific action and resource: setting the form view via API1 in the EZD PUW system. However, it does not differentiate this tool from the near-identical sibling ezd_formularz_set_view, so it falls one point short of full clarity.

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 given about when to choose this tool over its alternatives. The phrase 'przez API1' hints at one implementation path, but there is no mention of ezd_formularz_set_view or of criteria such as API version or required worker context.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that a view is set; it does not mention side effects, permissions, reversibility, or what the API returns. Because the description implies a state-changing operation without any behavioral detail, it is only minimally transparent.

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 short sentence with no wasted words, but it is under-specified rather than meaningfully concise. Repeating 'przez API1' adds no value since the tool name already contains API1, and the sentence does not elaborate on the operation. It is readable but not optimally informative.

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?

This is a complex tool with 11 parameters, 4 required fields, no output schema, and no annotations, yet the description provides only a one-line statement. It does not explain the transfer-view concept, the role of the many optional worker/position IDs, or what happens after the view is set. The description is substantially inadequate for an agent to invoke 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 description coverage is 100%, so the schema already documents all 11 parameters and their basic meanings. The description adds no additional semantic context, such as how the required parameters (IdKoszulki, IdFormularza, IdDokumentu, Widok) relate to each other or what 'Widok' actually controls. Baseline 3 is appropriate because the schema does most of 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?

The description uses a specific verb ('Ustaw' / set) and names a resource ('widok przekazania koszulki'), so it does indicate the basic action. However, 'widok przekazania' is a domain-specific term that is not explained, and the description does not distinguish this tool from siblings like ezd_api1_set_form_view or ezd_koszulka_transfer. The phrase 'przez API1' is also redundant with the tool name.

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 gives no guidance on when to use this tool versus the many related siblings, such as ezd_koszulka_transfer, ezd_api1_transfer_case, or ezd_api1_set_form_view. There are no prerequisites, no exclusions, and no mention of what scenario this transfer-view operation is intended for.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It identifies the operation as a transfer but does not disclose side effects, what happens to the source assignment, required authorities, reversibility, or any post-transfer state changes.

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 the core action front-loaded. The tail 'przez API1 w EZD PUW' is somewhat redundant given the tool name, but it does not materially hurt clarity.

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?

This is a mutation tool with 10 parameters, 5 required, no annotations, and no output schema, yet the description provides only the basic action. It omits guidance on required source/destination IDs, expected outcome, and behavioral consequences, leaving the agent under-informed.

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 of 3 applies. The description adds no extra meaning beyond the schema-provided parameter names and labels; it does not explain relationships between source and destination parameters or default owner behavior.

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 ('Przekaz' — transfer), a resource ('koszulke sprawy' — case cover), and a destination ('do innego pracownika/stanowiska'). It is clear but does not distinguish itself from the similarly named sibling ezd_koszulka_transfer or the template-based transfer variants.

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 about when to use this tool versus alternatives such as ezd_koszulka_transfer, ezd_api1_transfer_case_by_template, or ezd_koszulka_transfer_by_template. The description only restates the action without explaining selection criteria 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'Przekaz' implies a mutating state change, but the description does not disclose prerequisites (e.g., whether the source worker must own the case, whether the template must be active), side effects (the case leaves the source worker's scope and moves to the target position), or reversibility. The template mechanic is named but its behavioral implications are not explained.

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 tight sentence with no filler and the primary verb front-loaded. It earns a 4 rather than 5 because the brevity comes at the expense of routing and behavioral detail that a 9-parameter mutating operation with near-identical siblings needs.

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 mutating tool with no annotations, no output schema, 9 parameters, and a near-duplicate sibling, a one-line description is insufficient. The agent cannot determine what a template-based transfer changes, what conditions must hold, or how to choose between this and ezd_koszulka_transfer_by_template. Critical context 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 the baseline of 3 applies; the schema already documents all 9 parameters with adequate descriptions. The tool description itself names no parameters and adds no meaning beyond the schema, which is acceptable at this baseline but not a value-add.

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 ('Przekaz' = transfer), resource ('koszulke sprawy' = case card), and mechanism ('wedlug szablonu obiegu' = via workflow template, 'przez API1'). This clearly separates it from plain-transfer siblings like ezd_api1_transfer_case and ezd_koszulka_transfer. However, the sibling ezd_koszulka_transfer_by_template appears to perform the nearly identical operation, and the description offers nothing to differentiate the two.

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 given on when to use this tool versus alternatives. Given the existence of ezd_api1_transfer_case, ezd_koszulka_transfer, and the near-twin ezd_koszulka_transfer_by_template, an agent has no signal about which transfer tool fits a given scenario (e.g., whether a template is required, or which API version to prefer).

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely says 'update attributes' without explaining whether the update replaces the whole attribute set, merges with existing attributes, or triggers side effects. Important operational details like idempotency and authorization requirements are missing.

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 or repetition. It is front-loaded with the action and resource, though it sacrifices valuable behavioral detail 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 five parameters, no annotations, and no output schema, the one-line description is insufficient. It does not explain the update semantics, return value, required permissions, or how this tool relates to sibling update tools. An agent would need more context to use this tool reliably.

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 schema already provides basic descriptions for parameters such as Atrybuty, IdKoszulki, and the optional owner IDs. The tool description itself adds no parameter 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 a specific verb ('Zaktualizuj') and resource ('atrybuty koszulki sprawy') in the EZD PUW system, so an agent can infer the operation. However, it does not distinguish this tool from the similarly named sibling ezd_koszulka_update_attributes, which appears to target the same attributes.

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 the many related case/update tools. A nearly identical sibling, ezd_koszulka_update_attributes, exists, and the description gives no criteria for choosing between 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'update' and gives no information about side effects, partial versus full replacement semantics, required identifiers, permissions, idempotency, or response behavior. This is a significant transparency gap for a mutation tool.

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 filler or repetition. The action and resource are front-loaded, and every word contributes to identifying the tool's purpose.

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 11 optional parameters, no output schema, and no annotations, this one-line description is insufficient. It does not explain how the worker to update is identified, whether fields are merged or replaced, or what happens when optional fields are omitted. Important operational context 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 the input schema already documents all 11 parameters. The description adds no parameter-level meaning beyond the schema, so the baseline score of 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 states a clear verb and resource: 'Zaktualizuj dane pracownika' ('update employee data') and adds 'przez API1' to indicate the API family, distinguishing it from non-API1 worker tools like ezd_pracownik_update. However, it does not explicitly name alternatives or scope exactly which employee fields can be updated.

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 about when to use this tool versus sibling tools such as ezd_pracownik_update, ezd_api1_create_worker, or ezd_api1_get_worker. The description only states what the tool does, not when it should be selected or what prerequisites apply.

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?

No behavioral traits beyond the basic 'update' operation are disclosed, and no annotations are provided to fill the gap. The description does not state what happens to existing data, whether the update is partial or full, what permissions are required, or whether the operation is reversible.

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 wasted words. It loses a point because it mostly restates the tool name and API context, adding limited new information for an agent.

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 mutation tool with no annotations and no output schema, this is too thin. It lacks information about return values, errors, prerequisites, and the exact effect of the update. The schema helps with parameters, but not with update semantics or expected 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?

The input schema has 100% description coverage, so each parameter is already self-documenting. The description adds no additional meaning about how parameters relate to the update operation, but the schema carries the load.

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 action ('Zaktualizuj' = update) and the resource ('szablon obiegu pracownika' = employee workflow template), and identifies the API variant ('przez API1 w systemie EZD PUW'). This disambiguates it from sibling tools like create, delete, and get workflow templates.

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 gives no guidance on when to use this tool versus alternatives. It does not mention that creation should be done with ezd_api1_create_workflow_template, deletion with ezd_api1_delete_workflow_template, or retrieval with get variants. Usage context is only weakly implied by the word 'update'.

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?

No annotations are provided, so the description carries the full burden. It clearly indicates a create/write operation, but does not disclose expected side effects, required permissions, validation behavior based on Typ, idempotency, or what the operation returns.

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 one concise sentence, front-loaded with the operation and system name. The second clause about Typ adds relevant selection information without redundancy or wasted 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?

The tool has 10 parameters but all are covered by schema descriptions, and the single required parameter is clear. Still, with no annotations and no output schema, the description does not explain what the tool returns after creation or how attributes should vary by Typ, making it minimally viable rather than 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 schema already documents all parameters. The description adds little beyond the schema except emphasizing that Typ determines the addressee form, which the schema already states. 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 uses a clear verb-resource pair: 'Dodaj nowego adresata' (add a new addressee) in the EZD PUW system. It also distinguishes this create operation from sibling read/search tools like ezd_api3_get_addressee and ezd_api3_search_addressees by signaling creation of a new record.

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 usage context is implied by the verb 'Dodaj nowego adresata': use this tool when creating an addressee. However, it does not explicitly name alternative addressee tools or state when not to use this, such as when looking up existing addressees.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says the tool adds a party to a letter, but does not mention side effects, permission requirements, duplicate-handling behavior, or whether the operation is reversible. For a mutation-like action, this is thin.

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, front-loaded sentence that communicates the action, target resource, and role options without unnecessary words. It is appropriately sized for the information it provides.

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 10 parameters, no annotations, and no output schema, the description leaves important invocation details unstated, such as which parameter identifies the party being added and how role selection affects required fields. An agent would need to infer too much about the data model to invoke this tool confidently.

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 parameters are already individually documented. The description adds only the role context (Nadawca, Adresat, other role), which is useful but modest; it does not clarify how the parameters combine to define a party.

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 action and resource: adding a party (podmiot) to a letter in EZD PUW, and enumerates possible roles such as Nadawca, Adresat, or other role. This makes the tool's scope reasonably clear and distinguishes it from the more specific sibling ezd_api3_add_addressee, though it does not explicitly name that 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?

No guidance is given about when to use this tool versus alternatives like ezd_api3_add_addressee or when a different tool would be more appropriate. An agent cannot determine whether this tool is the general-purpose version of add_addressee or if they have overlapping responsibilities.

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 no annotations provided, the description carries full responsibility for behavioral disclosure. It truthfully says the tool changes status and lists valid status values, but it does not disclose side effects, transition restrictions, reversibility, ownership requirements, or whether status 3=USUNIETA performs a soft deletion. For a state-mutating tool, this is a notable transparency gap.

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 and front-loaded with the main purpose, followed by a compact status reference. Some redundancy with the schema's Status description exists, but the description remains easy to scan and does not waste much space.

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 schema covers the paramters well, but this is a mutation tool with no annotations and no output schema, so the description should add behavioral and workflow context. It does not explain transition rules, side effects, how to obtain the outgoing correspondence identifier, or what the response might indicate. An agent can make a syntactically valid call but lacks enough context to reason about consequences.

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%, and the Status parameter description already contains the full status-code mapping; the tool description largely repeats this mapping. It adds no meaning about how IdentyfikatorKW relates to outgoing correspondence or how the default worker/position parameters behave. The baseline of 3 applies because the schema handles parameter documentation well.

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 action with a specific verb ('Zmien') and a specific resource ('status korespondencji wychodzacej'), so an agent can tell this tool mutates the status of an outgoing correspondence item. It does not explicitly distinguish itself from the sibling ezd_api3_correspondence_status, but the change-vs-read distinction is reasonably inferable.

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 gives no guidance about when to use this tool versus alternatives such as ezd_api3_correspondence_status, ezd_api3_register_correspondence, or the search tools. It does not mention workflow stages, prerequisites, or scenarios like marking correspondence as sent, cancelled, or received. An agent must rely on the tool name and schema rather than on explicit usage 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 no annotations provided, the description carries the full burden of behavioral disclosure. It states that a case is closed but does not mention irreversibility, permission requirements, side effects on related documents, or any audit/blockchain implications. Minimal transparency beyond the bare 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 concise sentence with the action front-loaded and the required inputs listed. No filler, no redundancy, and appropriately sized for the operation.

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 high schema coverage, the tool has no annotations and no output schema. The description lacks behavioral context (side effects, reversibility), usage boundaries versus sibling tools, and any indication of the response format. For an agent choosing among many close/update/delete siblings, this is incomplete.

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 repeats that IdPracownika, IdKoszulki, and optional Uwagi are needed, but adds no extra semantic meaning such as formats, constraints, or relationships. It also omits the optional CID parameter.

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 ('Zakoncz' = close/finish) and a clear resource ('sprawe' = case) in the EZD PUW system, making the action unambiguous. It does not explicitly distinguish this from sibling tools like ezd_koszulka_close, but the name and action are clear enough.

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 gives no guidance on when to use this tool versus alternatives such as ezd_koszulka_close or ezd_api3_update_case. It only lists required inputs without stating conditions, prerequisites, 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?

The readOnlyHint annotation already establishes the read-only nature, and the description simply aligns by saying 'check' without adding behavioral depth. It doesn't disclose response format, pagination, scoping limits, or authorization requirements. The filter list merely restates what the schema already documents.

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, front-loaded sentence that names the operation and key filter categories, with no redundant words. It is appropriately compact for a tool that a query tool with optional 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?

With 10 optional parameters and no output schema, the description conveys the core purpose but leaves gaps: the agent gets no guidance on response structure, default behaviors (e.g., auto-generated CID, env-based defaults), or how filter combinations are applied. It's adequate for a basic status check but not fully rich.

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 all 10 parameters are already documented in the input schema. The description's mention of filtering by identifier, date, status, or type adds no meaning beyond the schema's per-parameter descriptions, putting this at the baseline for high schema coverage.

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 action ('Sprawdz status' = check status) and the resource ('korespondencji wychodzacej' = outgoing correspondence), and lists the main filter dimensions. It doesn't explicitly differentiate from sibling tools, but the verb 'check' makes it obvious this is a read operation versus the 'change' counterpart.

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 this is for querying and checking status, and gives filtering options, but it doesn't explicitly state when to use this tool over alternatives or when not to use it. The readOnlyHint annotation and sibling name 'ezd_api3_change_correspondence_status' provide implicit context, yet the description itself lacks explicit 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a state-changing, non-idempotent sequential allocation by saying 'next number,' but it does not disclose side effects, persistence behavior, reversibility, permissions, or error conditions. This is a mutation tool and the behavioral context is thin.

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, efficient sentence with zero wasted words. The verb and resource are front-loaded, and the scoping inputs are packed into a short closing clause. Every word earns its place.

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?

Parameters are fully documented in the schema and the tool is simple (flat object, no output schema), so the description does not need to explain parameters or return values. However, for a state-changing create operation with no annotations, the lack of any behavioral or usage context leaves the definition only moderately 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 schema already documents all seven parameters. The description adds only marginal value by mapping its three key concepts (unit, year, symbol) to the required parameters, which meets the baseline 3 but does not exceed it.

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 (Utworz — create) and a specific resource (kolejny numer teczki RWA — next RWA folder number), and states the scoping inputs (jednostki, rocznika i symbolu RWA — unit, year, RWA symbol). This inherently distinguishes it from the sibling get_rwa_folder_number and delete_rwa_folder_number tools via the create action.

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 given on when to use this tool versus the closely related ezd_api3_get_rwa_folder_number or ezd_api3_delete_rwa_folder_number siblings. There is no stated precondition (e.g., unit must exist) or indication that this is the tool to call when a new sequential number is needed.

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 restates the destructive nature already signalled by destructiveHint=true, but additionally discloses that a deletion reason is required and identifies the target object ('sprawe'). This goes slightly beyond the annotation by specifying the required justification.

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 short sentences, front-loaded with the action and followed by a necessary warning. No redundant phrasing or filler; every sentence earns its place.

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 covers the core action and the key precondition (reason for deletion), and the schema covers all parameters. However, there is no mention of post-conditions, irreversibility beyond the 'destructive' label, or how this relates to close/update alternatives, which matters in an ecosystem with many case-related siblings.

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 already describes all 7 parameters with 100% coverage, including PowodUsuniecia and IdKoszulki. The description adds no parameter-level detail beyond noting that the reason is required, which is already visible in the required array.

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 states a specific verb and resource: 'Usun sprawe z systemu EZD PUW' (delete case from EZD PUW system). This clearly identifies the operation and the target entity, distinguishing it from close/update operations at a basic level.

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 like ezd_api3_close_case or ezd_api3_update_case. The destructive warning implies it should be used only for actual deletion, but there is no exclusion or comparison to 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?

The destructiveHint annotation already marks this as destructive, and the description reinforces it with 'Operacja destrukcyjna — usuwa przydzielony numer.' This adds context that the action is irreversible. However, it does not disclose consequences for related records, whether confirmation is required, or any authorization prerequisites beyond the annotation.

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 short sentences with no redundant content. The core action and destructive warning are front-loaded, and the description does not repeat what the schema already documents.

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 destructive tool with no output schema and no required parameters, the description is minimally sufficient: it conveys the action and risk. However, it does not state what happens to the folder number after deletion, whether related records are affected, or whether there is any rollback. Given the 100% schema coverage, the missing operational detail is a moderate gap.

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 all 9 parameters have individual descriptions in the schema. The tool description adds no parameter-level meaning beyond noting the operation deletes an assigned number. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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 action and resource: 'Usun numer teczki RWA z systemu EZD PUW' (Delete RWA folder number from EZD PUW system). It clearly identifies this as the deletion counterpart to the sibling creation and retrieval tools. However, it does not explicitly differentiate from other delete tools like ezd_pracownik_delete or ezd_api3_delete_case, so siblings are not fully distinguished.

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 deleting assigned RWA folder numbers and explicitly warns that the operation is destructive. It does not state when to prefer this tool over alternatives such as ezd_api3_get_rwa_folder_number or ezd_api3_create_rwa_folder_number. Context is implied by the verb 'delete' but no explicit when-to-use or when-not-to-use guidance is given.

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 readOnlyHint annotation already signals a safe read operation, and the description is consistent with it. The description adds no further behavioral details beyond the lookup key, such as response shape, error conditions, or whether both IDs are required or mutually exclusive, but the annotation lowers the burden here.

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 entire description is a single, efficient sentence with no filler or repetition. It front-loads the core information: what is retrieved, from where, and by what criterion.

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 read-only get-by-identifier operation with fully described parameters and a readOnlyHint annotation, the description is nearly sufficient. The only mild gap is not explaining which identifier is required given that all parameters are optional in the schema, but the description still conveys the intended invocation pattern well enough.

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 schema already documents all five parameters. The description's mention of 'ID adresata lub adresu' adds slight semantic value by highlighting the two primary lookup modes, but it does not clarify deterministic parameter behavior or whether exactly one of them must be supplied.

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 ('Pobierz' = retrieve), a concrete resource ('dane adresata' = addressee data), the system ('EZD PUW'), and the lookup criterion (ID or address). This makes the tool's function unmistakable and inherently distinguishes it from search/add-addressee siblings without needing to name them.

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 phrase 'na podstawie ID adresata lub adresu' implies the tool should be used when the caller already has addressee or address identifiers. However, it does not explicitly state when not to use it, nor does it point to alternative tools such as ezd_api3_search_addressees for identifier-less lookups.

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 readOnlyHint annotation already establishes that this is a safe read operation, and the description aligns with it without contradiction. The description adds no extra behavioral context such as auth requirements, error behavior, or return format limitations, but for a simple read-only fetch the annotation largely covers the safety profile.

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 short, front-loaded sentence delivers the essential information with no filler. It is concise and easy to parse.

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 read-only tool with fully documented parameters and a readOnlyHint annotation, the description is largely complete: it states the resource, the system, and the lookup key. It could be stronger by naming sibling tools or describing the response shape, but the absence of an output schema is mitigated by 'szczegoly sprawy' indicating returned case details.

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 input schema fully documents all three parameters. The description mentions CID but does not add new meaning beyond the schema; this meets the baseline for fully covered 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 uses a specific verb ('Pobierz' / get), names the resource (case details from EZD PUW), and identifies the lookup key (CID). It is clear enough to separate from list-oriented or mutation siblings, 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?

The phrase 'na podstawie CID' implies the tool should be used when a correlation ID is available and case details are needed. However, it does not mention when not to use it or point to alternatives such as ezd_api3_list_cases or ezd_api3_get_last_case_changes.

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, covering safety. The description adds minimal behavioral context: it is a list operation with optional date-range filtering. It does not mention pagination, limits, ordering, auth requirements, or return format, but the read-only annotation lowers the expected burden.

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 short, focused sentences with zero filler. The action and resource are front-loaded, followed by the filtering instruction. Every word contributes.

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 read-only list tool with all optional parameters and no output schema, the description is largely complete. It names the resource and the primary filter. A note about alternatives or result shape would improve it, but nothing essential is missing for invoking 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 description coverage is 100%, so each parameter is already documented. The description adds a general 'filter by registration date range' concept, which loosely maps to DataRejestracjiOd/Do, but provides no additional 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?

Description clearly states the action (pobierz listę = get list), the resource (wpływów/przesyłek przychodzących = inboming shipments), and the source system (EZD PUW). It does not explicitly distinguish from siblings like ezdi_api3_search_eppuap_inflow or ezdi_api3_register_inflow, so not a full 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?

The description implies the main use case — retrieving a list of inflows — and provides a filtering instruction by registration date range. However, it gives no explicit guidance about when to prefer this tool over alternatives such as search_epuap_inflow or search_inflow_addressee.

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 annotations declare readOnlyHint=true and the description is consistent with that, but the description adds almost no behavioral detail. It does not disclose what counts as a 'change', result limits, pagination, ordering, or default time window.

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 two concise sentences with no filler, and the core action is front-loaded. Every phrase contributes to understanding the tool.

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?

There is no output schema, yet the description never explains what the returned changes look like or how 'last' is determined. An agent cannot confidently predict the result shape or understand default behavior when no filters are provided.

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 all six optional parameters are already documented in the input schema. The description adds that date, IdPisma, and CID act as filters, but it does not clarify whether these filters combine or are mutually exclusive, adding only marginal value.

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') and a specific resource ('ostatnie zmiany w sprawach z EZD PUW'), making the tool's purpose clear. It is distinct from sibling tools like ezd_api3_get_case or ezd_api3_list_cases, 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?

No guidance is given on when to use this tool versus related case or change-focused siblings. The description lists filter options but provides no context, exclusions, or alternative recommendations.

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 readOnlyHint annotation already covers the safety profile, and the description's 'Pobierz' aligns with that. The description adds contextual scope (what is fetched and via which identifiers) but does not disclose return format, pagination, error behavior, or what happens when neither identifier is provided. With annotations covering the main behavioral trait, this is adequate but not rich.

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 that front-loads the verb and resource, then states the lookup criteria. No filler, no repetition of schema details, and no unnecessary context.

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 read-only fetch tool with five documented parameters and no output schema, the description is mostly complete: it names the return concept (podmioty/strony), the input identifiers, and the system context. It could be more explicit about needing at least one of IdPisma/ZnakSprawy and about the response shape, but the schema and annotation cover most operational needs.

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 value by expressing that IdPisma and ZnakSprawy are alternative lookup keys ('po ID pisma lub znaku sprawy'), a relationship not explicit in the individual schema entries. This goes beyond what the schema alone states.

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 ('Pobierz' = fetch) and a clearly defined resource: entities/parties associated with a letter in EZD PUW. It also specifies the two lookup paths (letter ID or case reference), and the name/description distinguish it from the sibling add_letter_subject tool.

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 when to use the tool — when you need subjects/parties for a letter and have either IdPisma or ZnakSprawy. However, it does not explicitly contrast this with alternatives like ezd_api3_get_addressee or ezd_api3_add_letter_subject, leaving the routing partially 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?

The readOnlyHint=true annotation covers the safety profile, and the description adds useful scope context (unit and year binding). However, 'kolejny' (next) raises an unresolved question of whether retrieving the number advances a sequence; the description does not address counter semantics or what the returned value represents.

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 compact sentence that front-loads the verb and resource, with zero filler. The unit/year scoping is placed at the end without bloating the sentence.

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?

Adequate for a read-only getter whose 9 parameters are all schema-documented, but with no output schema the description leaves the return format implied, and it never explains why ownership parameters (IdPracownikaWlasciciela, etc.) are relevant to fetching the next number or how this relates to the create/delete RWA siblings.

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 is already documented. The description only loosely maps to Rocznik and JednostkaIdOryginal via 'dla danej jednostki i rocznika' and adds no format or relationship details beyond the schema, so it stays at the baseline.

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: 'Pobierz kolejny numer teczki RWA' (get the next RWA folder number) with scoping context ('dla danej jednostki i rocznika' — for a given unit and year). The read verb naturally distinguishes it from mutation siblings ezd_api3_create_rwa_folder_number and ezd_api3_delete_rwa_folder_number.

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 when-to-use guidance or exclusions are provided. The directly adjacent sibling ezd_api3_create_rwa_folder_number exists, and the description never clarifies that this tool only fetches a suggested number rather than creating a folder, so an agent could plausibly pick the wrong RWA 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?

Annotation readOnlyHint=true already signals a safe read operation. The description adds that this is a list retrieveal from EZD PUW with filters, but does not disclose pagination, result ordering, or default ownership behavior beyond what the schema already notes.

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 short, front-loaded sentences: the first states the action, the second lists filters. Every word earns its place and there is no redundant 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 read-only list tool with all-optional parameters and no output schema, the description gives the core purpose and filter surface. It is slightly incomplete because it does not mention pagination or explicitly route an agent toward a single-case tool when a specific case is needed.

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 schema already documents all seven parameters. The description adds a concise natural-language mapping of the main filters (Wlasne, IdJednostki, Rocznik, SymbolRWA), but this adds only lightweight meaning beyond the existing param descriptions.

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 specifies a concrete action ('Pobierz liste spraw'), a resource ('z EZD PUW'), and the main filter dimensions. This clearly distinguishes the list operation from sibling tools like ezd_api3_get_case or ezd_api3_register_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?

The description implies usage by saying this tool lists cases and filters by own cases, unit, year, or RWA symbol, but it does not state when to prefer this over alternatives such as ezd_api3_get_case or ezd_koszulka_list.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'register a new case' but does not disclose side effects, whether existing records are modified, permissions needed, idempotency, failure behavior, or what happens after successful registration. For a creation/mutation tool this is a significant gap.

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 two short sentences with no wasted words. The action and target resource are front-loaded, and the essential input categories are listed clearly. The slight lack of Polish diacritics is a minor style issue and does not hurt clarity.

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 11 parameters, no annotations, and no output schema, the description is too thin to fully support correct invocation. It does not clarify which parameters are actually required at runtime, what prerequisites must exist (e.g., koszulka, RWA folder, employees), what defaults apply, or what the response will look like. The tool is a complex creation operation and needs more behavioral and prerequisite context.

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 descriptions cover 100% of the 11 parameters, so the baseline is 3. The description adds a helpful natural-language grouping of the key inputs (numer kolejny, koszulke, rok, teczke RWA, pracownikow), but it does not explain relationships, validation rules, or defaults, and it omits several parameters entirely. It adds modest value over 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 states a concrete action ('Zarejestruj' / register) and a specific resource ('nowa sprawe w EZD PUW' / new case in EZD PUW). The word 'nowa' clearly distinguishes it from update/get/list operations on existing cases, and the list of required items (numer kolejny, koszulke, rok, teczke RWA, pracownikow) adds clear scope.

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 gives clear context: use this tool to register a brand-new case, and the fields to provide. It does not explicitly name alternatives or state when not to use it, but the emphasis on 'nowa' and the verb 'register' make the primary use case 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?

No annotations are provided, so the description carrie the full burden of disclosing side effects. It only says correspondence will be registered; it does not explain permissions, reversibility, return behavior, ID auto-generation, or whether any downstream approvals/processes are triggered.

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 very short, front-loaded, and easy to parse. A small deduction is warranted because the Typ/Strefa detail duplicates already-structured schema information, so the limited prose space could have delivered more net-new context.

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 schema covers all eight parameters at 100%, so the description can stay focused on intent. It provides that intent and the allowed core values, but with no annotations and no output schema, it leaves side effects and sibling-tool routing mostly implicit — minimum viable, but not 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?

Schema description coverage is 100%, so the baseline is 3. The description repeats Typ and Strefa, but those values are already documented in the schema; it adds no new parameter meaning beyond the structured definitions.

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 concrete action ('register') and a distinct resource ('outgoing correspondence in EZD PUW'), with the core typ/zone constraints also made explicit. The word 'wychodząca' clearly separates this from incoming/inflow tools, though it does not name sibling tools directly.

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 alternatives are named and there is no explicit when-to-use/when-not-to-use statement. The restriction to KOPERTA, MAIL, or FAX plus 'wychodzaca' implies this is for outgoing paper/mail/fax rather than incoming, EPUAP, or e-Doreczenia registration, but the agent has to infer that.

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?

No annotations are provided, so the description must carry the behavioral burden. It discloses that the tool registers a document and accepts an attribute array, but it does not mention permissions, side effects, defaults for owner IDs, idempotence, or what the response contains.

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 two short sentences with the primary action front-loaded. It contains no filler or redundant explanation, making it easy for an agent to scan and act on.

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 a nested object and four parameters, there is no output schema and no annotations. The description omits important context such as CID behavior, owner ID defaults, and expected return values, leaving the agent with limited guidance for correct 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?

Schema description coverage is 100%, so the structured schema already documents the parameters. The description adds a brief restatement of the attribute array shape ({Klucz, Typ, Wartosc}), which reinforces but does not materially extend the schema's meaning.

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 action ('Zarejestruj nowy dokument w EZD PUW') and identifies the resource and the attribute structure. It does not, however, differentiate this tool from similar siblings like ezd_dokument_register or ezd_dokument_add, which may overlap in purpose.

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 such as ezd_dokument_register, ezd_dokument_add, or ezd_api3_register_inflow. The description tells how to pass attributes but does not state prerequisites, exclusions, or selection criteria.

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?

No annotations are provided, so the description carries the full disclosure burden, yet it only states that a shipment is registered and lists two modes. It does not explain what registration entails — whether the delivery is actually dispatched to the public/private register, whether the operation has legal effect, whether it is idempotent, or what side effects occur. The PURDE/PUH distinction is already present in the schema's TrybWysylki description, so nearly no new behavioral context is added.

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 short sentences with no filler, and the core purpose is front-loaded. However, at this length the description is under-sized for an 11-parameter mutation-type tool with no annotations — the brevity is a virtue, but the description is not fully appropriately sized to the tool's complexity.

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 mutation tool with no annotations and no output schema, this is insufficient. It does not say what happens upon registration, how the two modes affect behavior, or how this tool relates to register_epuap and register_correspondence. An agent would still need to infer the workflow and pick among siblings without any 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 description coverage is 100%, so the baseline is 3. The description's mode sentence marginally reinforces the allowed TrybWysylki values (PURDE=publiczny rejestr, PUH=prywatny), which is slightly useful given no enum constraint exists, but it essentially paraphrases the schema text and adds nothing about the other nine 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 names a specific action and resource — 'Zarejestruj wysylke przez e-Doreczenia w EZD PUW' (register an e-Doreczenia shipment in EZD PUW) — and clarifies the two sending modes (PURDE public register, PUH private). It is clear what the tool does, but it does not differentiate itself from closely related registration siblings such as ezd_api3_register_epuap, ezd_api3_register_correspondence, or ezd_api3_register_inflow.

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 given on when to use this tool versus the many registration siblings (register_epuap, register_correspondence, register_inflow, register_document). The PURDE/PUH line is parameter-level advice, not tool-selection guidance. No prerequisites, exclusions, or alternative conditions 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?

There are no annotations, so the description carries the full burden of disclosing side effects. 'Zarejestruj' implies a state-changing registration, but the description does not clarify whether the shipment is actually transmitted via ePUAP, what records are created or updated, or what response to expect. The stated requirements are preconditions, not behavioral outcomes.

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 one front-loaded action sentence plus a terse requirement clause, with no filler. It efficiently communicates the core action and prerequisites, though it sacrifices some behavioral context 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 eight parameters, no annotations, and no output schema, this description is too sparse to fully orient an agent. It omits the required IdPracownika from its prose prerequisites and does not clarify the registration's effects or how it differs from neighboring ePUAP/e-delivery tools.

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 applies. The description maps three conceptual prerequisites (adresat, skrytka ePUAP, dokument pisma) to core parameters, but adds no format, default, or relationship information 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 uses a specific verb ('Zarejestruj') and a clear resource ('wysylke przez ePUAP') with system scope ('w EZD PUW'). It distinguishes itself by naming the ePUAP shipment registration action, though it does not explicitly contrast with sibling registration tools like ezd_api3_register_edoreczenia.

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 phrase 'Wymaga adresata, skrytki ePUAP i dokumentu pisma' gives concrete prerequisites for using the tool. However, it does not explain when this tool should be preferred over alternatives such as ezd_api3_register_edoreczenia or ezd_api3_register_correspondence; usage is implied rather than explicit.

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?

No annotations are present, so the description carries the full behavioral burden. It states the registration action but does not disclose creation side effects, defaulted fields such as IdPracownikaWlasciciela/IdStanowiskaWlasciciela, expected output, or any constraints. It is not misleading, but it is minimal.

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 short, front-loaded sentence with no filler; every clause conveys the purpose and the data domain. It is efficient for the reader.

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 12-parameter creation tool with no required parameters, no output schema, and no annotations, the two-sentence description is insufficient. It does not say what the call returns, what minimal data is needed, what validation applies, or how it differs from the many similar registration siblings.

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 100% description coverage, so the schema already documents all 12 parameters, setting the baseline at 3. The instruction 'Podaj dane adresata/nadawcy' merely groups them as recipient/sender data and adds no format, required-combination, or semantic detail 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?

Description uses a specific verb-resource pair ('Zarejestruj nowy wplyw' = register new inflow) and identifies the system (EZD PUW), which clearly differentiates it from read/list siblings like ezd_api3_get_inflows and update siblings like ezd_api3_update_inflow_metadata.

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 when-to-use or alternative-selection guidance is provided. Despite many related registration tools among siblings (register_epuap, register_edoreczenia, register_correspondence), the description only states the action and mentions recipient/sender data, never explaining when to choose this tool over those 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?

The readOnlyHint annotation already covers the safety profile, and 'Wyszukaj' is consistent with that. The description adds no extra behavioral details such as result format, pagination, limits, or required-at-least-one filter behavior, but for a read-only search the annotation lowers the burden.

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 well-formed sentence that front-loads the verb and resource, then enumerates all search criteria. There is no filler or redundant restating of the parameter 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?

For an 11-parameter search tool with no output schema, the description could usefully state whether criteria combine as AND/OR, whether at least one is required, and what a successful response contains. The current description is minimally sufficient because the schema covers parameter meaning and the read-only annotation covers safety, but it leaves these operational questions open.

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 schema already documents every parameter. The description's grouping of criteria roughly maps to AdresatTyp, AdresatAdresElektronicznyDoreczen, the address fields, and ePUAP, but it adds no constraints or combination rules beyond what the schema provides.

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 ('Wyszukaj'), the resource ('adresatow w systemie EZD PUW'), and the available search dimensions (type, e-delivery address, address data, ePUAP). However, it does not distinguish this tool from the sibling ezd_api3_search_inflow_addressee, so it misses the top tier.

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 the tool is for locating addressees by the listed criteria, but it never states when to prefer this over ezd_api3_search_inflow_addressee or ezd_api3_get_addressee. No explicit when-to-use or alternatives are provided.

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 readOnlyHint annotation already signals a no-side-effect operation, and 'Wyszukaj' is consistent with that. The description adds scope (ePUAP inflows in EZD PUW) but discloses no additional behavioral details such as empty-result behavior, pagination, or permissions; it is adequate but not rich.

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 focused sentence in Polish carries the verb, object, scope, and lookup criteria with no filler. The key distinguishing information ('przesylki przychodzace', 'z ePUAP') 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?

For a simple read-only lookup with a fully parameter-documented schema, the description plus annotations are minimally sufficient. Still, because there is no output schema and the description does not clarify which of the two CID-like parameters (CID vs IdentyfikatorKorelacjiCID) is intended for search, an agent may need additional domain knowledge to invoke it optimally.

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 all five parameters are individually documented. The description's mention of 'identyfikatorze dokumentu lub korelacji CID' maps to IdentyfikatorDokumentu and the CID-related parameters, but it does not add meaning beyond the schema's field descriptions.

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 opens with a specific verb and resource: 'Wyszukaj wplywy (przesylki przychodzace) z ePUAP w EZD PUW' and narrows the operation by criteria 'po identyfikatorze dokumentu lub korelacji CID.' This clearly distinguishes it from lookups like ezd_api3_get_inflows and from the sibling ezd_api3_search_epuap_outflow via 'przychodzace' (incoming) and the ePUAP source.

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 the appropriate use case: finding an incoming ePUAP shipment when a document identifier or CID is known. However, it never states when to prefer this over ezd_api3_get_inflows or ezd_api3_search_epuap_outflow, nor what not to use it for, so the guidance is only 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?

The annotation readOnlyHint=true already marks the tool as read-only, and the verb 'Wyszukaj' is consistent with a non-mutating lookup. The description adds no further behavioral detail such as auth requirements, result ordering, or rate limits, so it is adequate but not rich.

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 the verb and resource front-loaded, followed by the search criteria. There is no filler, no repetition, and each part contributes to understanding the tool.

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 7 optional parameters and no output schema, the description states the searchable keys but does not clarify whether at least one criterion is expected, how multiple criteria combine, or what the result shape is. Parameter meanings are covered by the schema, but the tool-level invocation contract has 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?

The input schema has 100% description coverage, including defaults and auto-generation for CID. The description only summarizes the grouping of criteria and does not add meaning beyond the schema, so the baseline of 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 opens with 'Wyszukaj' (search), names the resource (ePUAP outflows/outgoing shipments), and lists the search keys (document identifier, correlation, correspondence, koszulka). This also distinguishes it from siblings like ezd_api3_search_epuap_inflow and ezd_api3_search_paper_outflow.

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 clear context: use this when you need to find ePUAP outflows by document, correlation, correspondence, or case identifiers. It does not explicitly name alternatives or exclusion conditions, 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?

The readOnlyHint annotation already signals a safe read operation, and the description's 'search' verb aligns with that. The description adds the specific search scope and criteria but discloses no additional behavioral details such as pagination, result limits, or authentication requirements. Given the annotation coverage, this is adequate but not richly transparent.

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 filler. The verb and target object come first, followed directly by the supported filter dimensions. Every word contributes to understanding the tool's purpose.

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 11 optional, fully documented parameters and no output schema, the description captures the essential search dimensions and the system context (EZD PUW). It does not explicitly state that no parameters are required or what happens with an empty search, but the schema already conveys optionality, so nothing critical 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?

The schema provides 100% parameter descriptions, so the baseline is 3. The description adds value by grouping parameters into meaningful search categories: address data (Lokal, Budynek, KodPocztowy, Miejscowosc), registration date (DataRejestracjiOd/Do), and email (Email). This semantic grouping helps the agent select the right filter parameters more easily than reading each schema description in isolation.

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 opens with the imperative 'Wyszukaj' (search) and clearly identifies the resource: 'adresata/nadawce wplywu' (addressee/sender of an inflow) in EZD PUW. It also enumerates the search criteria (address data, registration date, email), which distinguishes it from sibling tools like ezd_api3_get_addressee and ezd_api3_search_addressees via the specific 'inflow' scope.

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 the use case: search for an inflow addressee/sender when you have address data, a registration date, or an email. It does not explicitly name alternatives or state when not to use this tool, but the 'inflow' qualifier provides clear context that differentiates it from generic addressee search 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?

The readOnlyHint annotation already discloses that this is a read-only operation, and the description's 'Wyszukaj' is consistent with that. The description adds little behavioral context beyond the search scope, such as pagination, result limits, or authentication needs. With annotations covering the safety profile, a mid-range score 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?

The description is a single, front-loaded sentence with no redundancy. It states the action, the object, the system, and the key search criteria efficiently.

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 minimally adequate for a read-only search tool: it names the resource and the search keys. However, with no output schema and all parameters optional, it leaves the agent without clear guidance on the expected return shape or whether at least one ID parameter must be supplied.

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 already documents all five parameters with 100% description coverage, so the baseline is 3. The description reinforces that search is by return-document ID or correspondence ID, but it does not clarify whether one ID is required, whether both can be combined, or how the optional owner/CID parameters affect behavior.

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 the specific verb 'Wyszukaj' and identifies the resource as paper outflows / traditional outgoing correspondence in EZD PUW. It also specifies the search keys (return document ID or correspondence ID), making the purpose unambiguous. This clearly distinguishes it from the sibling ezd_api3_search_epuap_outflow, which targets EPUAP outflows.

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 gives clear context that this is for paper/traditional outgoing correspondence, which implicitly excludes EPUAP/electronic flows. However, it does not explicitly mention alternatives, when-not-to-use conditions, or advise which parameter combination is appropriate for a given 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'update' and asks the caller to pass an object with required fields; it does not explain partial vs. full update semantics, validation effects, permissions, or what happens on success/failure.

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 and non-redundant, containing one instruction about the action and one about the needed input. It is appropriately sized, though its brevity leaves key details unstated.

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 tool has a required nested object with undocumented fields, no output schema, and no usage guidance. An agent cannot reliably construct the 'koszulka' payload or understand the update's side effects, so the description is incomplete for a real 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 schema already provides descriptions for all parameters, including defaults for owner/position IDs, so the baseline is 3. The description adds only the vague phrase 'z wymaganymi polami' without specifying which fields of the nested 'koszulka' object are required, so it does not meaningfully compensate for the opaque nested object.

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 clear imperative verb ('Zaktualizuj') with a specific resource ('koszulke (sprawe)') and system ('EZD PUW'), so an agent can tell it performs case updates. However, it does not differentiate itself from sibling tools like ezd_koszulka_update or ezd_koszulka_update_attributes.

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. Other sibling tools exist for updating koszulka attributes or documents, but the description gives no condition or context that would help an agent choose this one.

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 no annotations provided, the description carries the full burden of behavioral disclosure, but it only repeats the update action and the attribute payload format. It does not explain whether attributes are replaced or merged, whether the document must already exist, what permissions are needed, or what side effects occur.

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, front-loaded sentence with no filler or redundant text. It is under-specified in content, but as a structural matter it is efficient and easy to scan.

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?

This is a mutation tool with no annotations and no output schema, yet the description omits critical context such as how the target document is identified, whether updates are incremental or full replacements, error behavior, and any prerequisites. The description is too thin to support correct invocation in an agentic context.

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 schema already explains CID, Dokument, and the owner IDs. The description adds no meaningful parameter semantics beyond restating the attribute array shape already present in the schema, so the baseline score of 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 clearly states the action ('Zaktualizuj dokument') and the target system ('EZD PUW'), making the basic purpose unambiguous. However, it does not differentiate this tool from sibling tools with similar purposes such as ezd_dokument_update, ezd_api3_register_document, or ezd_api3_update_inflow_metadata.

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 the many sibling tools that also update or register documents. It neither mentions specific use cases, prerequisites, nor excludes alternatives, leaving the agent to guess which tool fits a given situation.

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 no annotations, the description carries full burden for behavioral disclosure. It discloses only that metadata gets updated, but not how the target inflow is selected (no inflow ID parameter exists), whether the update is partial or full replacement, what role the filter-style parameters (DataRejestracjiOd, NadawcaNie) play, or what the operation returns. For a mutation tool this is a substantial gap.

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 with no wasted words — verb and resource come first, followed by a compact em-dash list of scope. It is efficient, though it achieves brevity by omitting the behavioral context this tool needs.

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?

A 12-parameter mutation tool with no required parameters, no output schema, and no annotations receives only one short sentence. The most important context is missing: how the inflow to update is identified (no ID parameter), what a no-argument call does, and how date/sender filter parameters behave inside an update operation. Incomplete for safe 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?

Schema description coverage is 100%, so the baseline is 3; the schema already documents all 12 parameters individually. The description adds only a high-level grouping (addressee, registration data, address) that loosely maps to the parameters. It does not clarify the critical ambiguity of which parameters act as selection filters versus values to set.

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 ('Zaktualizuj' = update) and resource ('metadane wplywu' = inflow metadata), and lists the field groups touched (adresat, dane rejestracji, adres). This distinguishes it from siblings like ezd_api3_register_inflow or ezd_api3_get_inflows, though it does not explicitly name any 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?

No guidance is given on when to use this tool versus alternatives. The context — that the inflow must already exist and this is a follow-up to registration — is only implied by the verb 'update'. Siblings such as ezd_api3_register_inflow and ezd_api3_update_case are not referenced.

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 annotation readOnlyHint=true already covers the read-only safety profile. However, the description adds no behavioral context beyond the basic purpose: it does not explain how 'last' is determined, whether scoping by worker/position applies, or what the response represents.

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, direct sentence with no filler. The key scoping term 'ostatnie' appears immediately after the verb, and every word contributes to the basic meaning.

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?

Although the tool is simple and read-only, the description does not clarify what 'utrwalenie' means, whether the result is scoped to the worker/position context, or what an agent should expect as output. With no output schema and no discussion of alternatives, these gaps make the description incomplete for confident invocation and interpretation.

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 all three parameters (CID, IdPracownikaWlasciciela, IdStanowiskaWlasciciela) are already documented with their defaults. The description adds no parameter-level information, so the baseline of 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 Polish description uses a specific verb 'Pobierz' (fetch) and a clear resource, 'ostatnie utrwalenie z blockchain' (last blockchain record) in the EZD PUW system. The word 'ostatnie' differentiates it from sibling ezd_blockchain_get_record, though it does not explicitly name that 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?

No guidance is given about when to use this tool instead of ezd_blockchain_get_record or ezd_blockchain_order_immutability. There are no conditions, exclusions, or alternatives mentioned, so an agent must infer usage from the tool name alone.

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 convey readOnlyHint=true, and the description aligns with that by saying 'Pobierz' rather than implying mutation. It adds some scope context by specifying the lookup by order identifier, but it does not disclose response behavior, error cases, or whether multiple records can match.

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 focused sentence with no filler. It is front-loaded with the action and resource, and every word contributes to identifying the tool's purpose.

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 read-only lookup, the description provides the essential purpose and key input. However, with no output schema, the description does not explain what the returned 'utrwalenie' contains or how the caller should interpret the result, leaving a moderate gap.

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 applies. The description reinforces that IdZlecenia is the lookup key, but it does not add detail beyond what the schema already provides for each parameter.

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' / retrieve), a clear resource ('utrwalenie z blockchain'), and a precise lookup key ('po identyfikatorze zlecenia'). This distinguishes it from the sibling ezd_blockchain_get_last_record, which targets a different record selection.

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 this tool is for fetching a blockchain record by an order identifier, but it gives no comparison to ezd_blockchain_get_last_record or ezd_blockchain_order_immutability. It offers no explicit when-to-use or when-not-to-use 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says data will be ordered for blockchain persistence; it does not disclose whether this is asynchronous, whether the operation is irreversible, what authorization is required, or what happens on duplicate sequence numbers. This is a meaningful gap for a mutation-like tool.

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, focused sentence with no redundant wording. It is appropriately front-loaded with the action and resource, making it easy to parse quickly. It is concise, though it sacrifices some behavioral context 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?

Given there is no output schema and no annotations, the description should explain what calling this tool returns or whether it is a fire-and-forget request. The description also omits any relationship to the blockchain read siblings. For a 5-parameter tool with required inputs and no return-value documentation, this is incomplete.

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 input schema already documents all five parameters, including base64 encoding for Dane and the long type for NumerSekwencyjny. The description itself adds no parameter-level detail beyond what the schema provides, so the baseline of 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 states a specific action and resource: 'Zlec utrwalenie danych w blockchain' (order data to be persisted in the blockchain). This clearly signals a write/order operation and is distinguishable from sibling read tools like ezd_blockchain_get_record. However, it does not explicitly contrast itself with those sibling read tools, so it falls just 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?

There is no guidance on when to use this tool versus ezd_blockchain_get_record or ezd_blockchain_get_last_record. The verb 'Zlec' implies it is the write counterpart to the read tools, but the description never states this or any conditions or prerequisites. An agent must infer usage entirely from the tool name and sibling context.

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?

There are no annotations, so the description carries the full responsibility for disclosing side effects. It simply says 'accept document' without explaining what changes occur, whether the action is reversible, whether it requires specific privileges, or what the result is. This is a significant transparency gap for a state-changing action.

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 clear sentence with no filler words or redundant phrasing. It is concise and front-loads the action and resource, though it is so short that it provides little beyond the tool name.

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 output schema, no annotations, and a large family of sibling tools, the description is not complete enough. It fails to explain the acceptance workflow, required or optional identifiers, default behavior of the owner/position parameters, or the expected outcome. An agent cannot reliably determine when or how to invoke 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?

The input schema already provides descriptions for all four parameters, including the nested Dokument object, so the schema coverage is complete. The description adds no additional meaning about how parameters should be used, which keeps this at the baseline score.

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: 'Akceptuj dokument' (accept document) in the EZD PUW system. This is clear and distinctively names an accept action, though it does not explicitly differentiate it from sibling document tools like ezd_dokument_register or ezd_dokument_update.

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?