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 states that the tool 'returns information' but does not explicitly mention that it is read-only or has no side effects. For a query tool, this is acceptable but could be more explicit about impact (e.g., no 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 concise, with a brief summary followed by illustrative examples. The structure is clear, though the examples partially replicate the schema's parameter list, making it slightly redundant.

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 that an output schema exists, the description need not explain return values. It sufficiently covers the tool's purpose and usage context. Minor gaps: no mention of error handling or edge cases like invalid ELI formats, but these are not critical for basic usage.

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% coverage of parameter descriptions, including the valid relationship_type values and the ELI format. The tool description adds usage examples but no additional semantic detail beyond what the schema already contains.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: analyzing relationships and references between legal acts. It names the specific resource (powiązania i referencje) and provides examples of distinct relationship types, distinguishing it from sibling tools like get_act_details or search_legal_acts.

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 includes concrete examples for different relationship_type values, making the intended use implicit. However, it lacks explicit guidance on when to prefer this tool over alternatives (e.g., 'use this when you need to see amendments' or 'not for full act content').

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 behavioral disclosure burden. It discloses the default maximum of 20 results and the side effect that results are saved to result_set_id for later filtering. It does not mention permissions or edge cases, but for a read-only browse tool this is reasonable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a one-line purpose, explicit usage rules, a behavior note, and examples. The examples are numerous but each illustrates a distinct parameter combination, and the overall length is justified by the clarity 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?

The description covers purpose, when to use and avoid, return behavior, result_set_id handling, pagination, and parameter variants via examples. An output schema exists, so the return structure is already specified. Nothing critical is missing 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 coverage is 100%, so the baseline is 3. The description adds value through concrete examples showing valid publisher codes (DU/MP), detail_level values, pagination with limit/offset, and year usage. These examples clarify parameter combinations beyond the schema 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: 'Przeglądaj wszystkie akty prawne wydane przez wydawcę w danym roku' (browse all legal acts issued by a publisher in a given year). It clearly differentiates from the sibling search_legal_acts by contrasting browsing a full annual set with searching by keywords or title.

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?

Explicit 'Kiedy użyć' and 'Kiedy NIE używać' sections state exactly when to use this tool versus search_legal_acts. It also advises using filter_results when narrowing is needed, giving the agent clear routing and follow-up 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, the description carries the behavioral burden and does explain sign conventions, default base date, and parameter combinations. However, it does not disclose calendar semantics for edge cases (e.g. adding one month to Jan 31) or invalid input behavior, which are relevant for legal date calculations.

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 front-loaded with purpose and operation, followed by a compact sign convention and six non-redundant examples. Every sentence contributes to correct invocation, with no filler or repeated schema content.

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 calculator with four optional parameters and an output schema present, the description is largely complete: it states what the tool does, how offsets work, and how the base date behaves. Minor edge-case semantics are missing, but they do not block selection or correct invocation in common use cases.

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 each parameter already has an explanatory description in Polish. The tool description adds value beyond the schema by illustrating real combinations (days=14, months=6, days=15, years=-5) and clarifying base_date formats such as 'YYYY' and 'YYYY-MM'.

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 clear purpose—calculating legal dates for deadlines, effective dates, and vacatio legis—and then states the core operation: adding/subtracting days, months, and years from a base date or today. This makes its function distinct from the sibling document/search tools.

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 concrete use cases (e.g. deadlines, entry into force, vacatio legis) and shows how to express future vs past offsets with positive/negative values. It does not explicitly name alternatives or exclusion criteria, but no sibling tool performs date arithmetic, so the usage context is sufficient.

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 present, the description carries the full behavioral burden. It clearly states what the tool compares, that it identifies differences and common elements, and that it does not require prior content loading. It does not explicitly label the operation as read-only, but comparing metadata strongly implies a non-mutating action, and the output schema covers return structure.

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 well-structured: summary line, detailed scope, usage guidance, exclusions, and examples. It is front-loaded with the most important information. The five examples are somewhat repetitive, but they demonstrate diverse comparison scenarios, so they earn their place without excessive bloat.

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 two-parameter comparison tool with an output schema, the description is complete: it states purpose, inputs, scope, prerequisites, exclusions, and examples. An agent has everything needed to select and invoke this tool correctly and to avoid confusing it with content-reading 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 documents both parameters with format and examples, achieving 100% coverage. The description adds use-case examples that pair eli_a and eli_b in meaningful ways (e.g., versions, different publishers), but this is illustrative rather than necessary parameter semantics. Baseline 3 is appropriate since 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?

The description opens with a specific verb and resource: 'Porównaj metadane dwóch aktów prawnych' (compare metadata of two legal acts). It enumerates the exact metadata dimensions (titles, types, statuses, dates, keywords) and explicitly differentiates itself from content comparison via read_act_content, so the tool's role among siblings is unambiguous.

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 explicit 'Kiedy użyć' and 'Kiedy NIE używać' sections, directing the agent to read_act_content for content comparison instead. It also notes that loading content beforehand is not required, which removes a possible mistaken prerequisite.

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 correctly carries the full behavioral burden. It discloses the 100-record input limit, hard-error behavior instead of partial results, creation of a new result_set_id, the ability to chain further filters, and the no_match_is_inconclusive signal. This is unusually 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 well structured: purpose first, then core behavioral constraints, then explicit usage rules, then examples. Every section has a clear job, and the examples are dense and illustrative rather than 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 13-parameter filtering tool, the description covers the full workflow: where the result_set_id comes from, how results are stored as new sets, size limits, error semantics, and the important source_scope caveat. Since an output schema exists, not restating return values is appropriate.

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 through composed examples showing result_set_id combined with type_equals, pattern, date ranges, sort_by/limit, and regex syntax, which helps an agent see realistic parameter combinations. It does not systematically redefine parameters, but the schema already covers them 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 states a clear, specific operation: filtering and narrowing results from earlier legal-act searches. It names the upstream tools (search_legal_acts, browse_acts, track_legal_changes) and uses a grep/filter analogy, which makes its role distinct and immediately understandable.

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 an explicit 'Kiedy użyć' section naming the exact preceding tools, plus two explicit 'Kiedy NIE używać' cases: one routing to search_legal_acts when new API results are needed, and one warning against using an empty result as proof that an act does not exist when source_scope is 'page'. This gives an agent clear decision rules.

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 behavioral burden. It discloses the significant side effect: setting load_content=True loads the act's content into the Document Store, with a lifecycle (TTL 2h, expiration, reload required) that affects subsequent calls. It describes what the call returns and what it does not do (read content). For a read-oriented tool, this is strong disclosure, though it does not cover edge behaviors like error conditions or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded: purpose sentence, return-value list, prerequisite note, then usage guidance and examples. The five examples are somewhat repetitive but serve as practical invocation patterns. Nothing is wasted, though the load_content prerequisite is stated twice (once in prose, once in the guidance section), a minor redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need no further explanation; the description covers what remains: when to use it, when not to, the prerequisite side effect of loading content, and example invocations for both parameters. An agent has everything needed to select and correctly call this tool across its use cases.

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 is 3; the description adds value beyond the schema by providing five concrete usage examples with real ELI identifiers (DU/2024/1692, MP/2024/100) and by clarifying how load_content connects to downstream tools (read_act_content, search_in_act). This reinforces format understanding and invocation patterns beyond the raw 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 opens with a specific verb and resource ('Pobierz szczegółowe informacje o akcie prawnym') and enumerates exactly what is returned: metadata, title, status, dates, keywords, table of contents, and formats. It also explicitly distinguishes itself from read_act_content by clarifying that content loading is a separate prerequisite, so an agent can tell it apart from sibling tools without opening schemas.

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 contains explicit 'Kiedy użyć' and 'Kiedy NIE używać' sections, names the alternative tool (read_act_content) for the excluded case, and states the prerequisite relationship (load_content=True required before read_act_content and search_in_act). This is exactly the when/when-not/alternatives guidance that makes tool selection reliable.

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 discloses what data it returns and that results can be used for filtering, but does not mention pagination behavior, limits at the endpoint level beyond schema defaults, or any response structure beyond the existing output schema. Adequate but not rich for an unannotated 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?

Compact paragraph with a clear return summary followed by five concrete examples. No filler or repetition of schema content; the examples earn their 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?

With a rich output schema already present and all 3 parameters fully documented, the description covers the key intent and usage patterns. The only minor gap is the lack of explicit mention of when metadata-prefetching is necessary versus unnecessary, but this is a low-complexity lookup tool, so the definition is effectively 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 coverage is 100%, so the baseline is 3. The description's examples genuinely enrich 'category' by mapping each value to real content (DU, MP for publishers; Ustawa, Rozporządzenie for types), going beyond the schema text. This lifts it to 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description states a specific verb ('Pobierz') and resource ('metadane systemu aktów prawnych'), and enumerates exactly what it returns (keywords, publishers, document types, statuses, institutions). It is clearly distinct from document-oriented siblings like search_legal_acts or browse_acts, though it stops short of explicitly naming a sibling it is not.

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 examples with concrete category values (keywords, types, publishers, statuses, all) give an agent actionable when-to-use guidance for filtering and search. However, it never names an alternative tool or states when NOT to use it, leaving some inference required.

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 behavioral burden. It discloses that documents are loaded via get_act_details(eli=..., load_content=True), that they expire after 2h TTL, and that the tool returns a single page with pagination metadata (page_info). It doesn't detail the exact page_info fields, but an output schema exists to cover that.

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?

Well-structured and efficient: a brief lead sentence, essential context about loading and TTL, clear usage guidelines, and a compact example list. Every section earns its place and the description is front-loaded with the core 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?

Given the tool's low complexity (2 optional params, full schema coverage, existing output schema), the description is complete. It tells the agent what the tool does, when to use it, when not to use it, how documents get loaded, and what the response shape is (page_info). Nothing essential 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 coverage is 100% for the two parameters, so the baseline is 3. The description adds value by giving concrete usage examples with limit/offset combinations (e.g., limit=5, offset=5 for next page) and clarifies the pagination behavior, which goes beyond the schema's defaults and constraints.

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: 'Wyświetl dokumenty załadowane do pamięci (Document Store)' — clearly stating the tool lists loaded documents. It also explicitly distinguishes itself from search operations by naming search_legal_acts as the alternative, preventing confusion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description has dedicated 'Kiedy użyć' (when to use) and 'Kiedy NIE używać' (when NOT to use) sections, and it names the alternative tool ('Do wyszukiwania aktów → użyj search_legal_acts'). It also adds useful context about TTL (2h) that informs when a document needs reloading.

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 the full burden. It discloses the TTL (1h), that only active sets are shown, and that pagination metadata is included. It implies a read-only operation. This is strong, though it doesn't mention auth or error behavior, which is acceptable for a simple list 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 structured with a purpose statement, usage context, exclusions, and examples. It is slightly lengthy but well-organized and front-loaded. Every section adds value; no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with two optional params, and an output schema exists. The description explains the concept of result sets, TTL, and provides examples covering pagination. It doesn't cover edge cases like empty result sets, but that's minor. Overall complete for an agent to use 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 both parameters. The description adds examples of usage (e.g., limit=5, offset=5) that clarify practical limits, but it doesn't add meaning beyond what the schema provides. 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 clearly states the verb ('list') and the resource ('active result sets stored in memory'). It distinguishes this tool from siblings by explaining that each search/filter creates a result set and that this tool lists them, and explicitly contrasts with search_legal_acts for new searches.

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?

Provides explicit 'Kiedy użyć' (when to use) and 'Kiedy NIE używać' (when not to use) sections, naming the alternative tool. The examples illustrate common calling patterns (pagination, limits), giving clear situational 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, the description carries the behavioral burden well. It discloses the crucial precondition, the branching behavior when section is omitted or present, and flexible optional section matching (raw IDs or readable forms). It could go further by explicitly describing failure behavior when the act isn't loaded or a section isn't found, but it is still well above the minimal achievable.

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 well organized first with a clear one-sentence purpose, then decisive blocks: WYMAGANIE, Kiedy użyć, and Kiedy NIE use. The examples are compact and practical, and no sentence feels wasted.

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 that there are no annotations but the schema is rich and an output schema is present, the description is effectively complete. It covers a precondition, differentiation from siblings, return behavior, optional section semantics, and multiple invocation examples, allowing an agent to select and call the tool without 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?

Input schema description/question_complete_coverage is 100%, and the schema already explains eli format, section forms, limit/offset behavior, and section meaning. The description adds concrete examples and contextual use, but the semantic load is already primarily carried by the schema, so 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 states a specific action and resource: 'Czytaj treść załadowanego aktu prawnego po sekcjach'. It also defines the two output modes (spis treści without section, szkż section content with section), and clearly differentiates the tool from get_act_details for 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 an explicit precondition: the act must first be loaded via get_act_details(eli=..., load_content=True). It also includes explicit 'Kiedy użyć' and 'Kiedy NIE używać' guidance, naming get_act_details as the alternative for metadata retrieval.

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 disclosure burden. It discloses the return shape (one page of hits with context, pagination metadata, section info), the prerequisite load behavior, and the non-error truncation behavior for context_chars. It could additionally state what happens if the act was not previously loaded, but the prominent requirement line mitigates this 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 front-loaded: purpose statement, then requirement, then return format, then examples. Each of the five examples demonstrates a distinct parameter combination (plain search, context_chars, limit/offset, offset continuation, defaults), so none is wasted, though the example block is slightly long.

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 output schema covers return values, so the description needn't explain them. The critical precondition, pagination behavior, context truncation edge case, and parameter defaults are all documented. What's missing is routing guidance across sibling tools (when to choose search_in_act over read_act_content or search_legal_acts), but the tool is callable correctly with the information 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 description coverage is 100%, so the baseline is 3. The description adds marginal value via five examples showing concrete query values, context_chars, and limit/offset pagination combinations, but it does not explain parameters beyond what the schema already documents.

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: 'Wyszukaj termin w treści załadowanego aktu prawnego' (search a term in the content of a loaded legal act). The qualifier 'załadowanego' (loaded) meaningfully distinguishes it from sibling search_legal_acts (searching act metadata/database) and read_act_content (reading content linearly), so an agent can tell them apart.

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 an explicit, critical precondition: the act must first be loaded via get_act_details(eli=..., load_content=True), stated with a WYMAGANIE (requirement) label and repeated in the eli parameter description and examples. It provides clear usage context and pagination patterns, but does not explicitly state when-not-to-use or name alternatives like search_legal_acts or read_act_content.

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 discloses important search semantics: keywords use AND logic, OR requires separate searches, and filter_results can be used to further narrow results. It does not explicitly state defaults like publisher=DU or limit=20, but those are already in the input schema; the description adds useful behavioral context beyond the schema.

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 well-structured into a main purpose, an AND-logic warning, explicit when-to-use/when-not-to-use guidance, a follow-up filter_results pointer, and examples. Every section earns its place, and the most important scoping information is front-loaded. Despite covering many behaviors, it remains compact and scannable.

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 13 parameters and 12 siblings, but the description plus full schema coverage and output schema provide enough context for correct invocation. It explains the primary use case, the main alternative, the follow-up tool, and the critical AND/OR semantics, while examples illustrate realistic parameter combinations. Nothing essential for selecting or calling this tool 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 is 3, and the description does not need to re-explain parameters. It earns a 4 by adding illustrative multi-parameter examples that clarify intent, such as date_from/date_to for entry into force and pub_date_from/pub_date_to for publication dates. The examples map naturally to the schema properties and show how parameters combine.

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 polskie akty prawne z Dziennika Ustaw (DU) i Monitora Polskiego (MP).' It clearly distinguishes itself from browse_acts by stating that browsing whole annual volumes is a different operation, and it routes post-search narrowing to filter_results. An agent can immediately tell what this tool does and how it differs from closely related siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use the tool ('Gdy znasz słowa kluczowe, tytuł, typ lub kryteria wyszukiwania'), when not to use it ('Gdy chcesz przeglądać cały rocznik → użyj browse_acts'), and how to chain it with filter_results afterward. It also provides six concrete examples covering keyword, type, force, publisher, date, and title searches, which leaves little 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?

With no annotations provided, the description carries the full behavioral disclosure burden. It meaningfully discloses a key side effect: 'Wyniki zapisywane są do result_set_id' and explains that results can be further narrowed with filter_results. This is valuable beyond the schema. It does not mention persistence details, overwrite behavior, or rate limits, but the main stateful behavior is disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description leads with the purpose, then explains the result_set_id behavior, and then provides examples. The examples are helpful but somewhat repetitive; several illustrate similar date-only patterns. Still, the structure is front-loaded and every major sentence contributes usable information.

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 six parameters, full schema coverage, and an output schema, the description covers the essential invocation context: date range, result set storage, and post-filtering via filter_results. It could mention how to retrieve the saved results beyond filter_results, such as list_result_sets, but the provided guidance is sufficient 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 every parameter already has documented semantics in the input schema. The description's examples reinforce valid combinations such as date_from with keywords or publisher, but they do not add substantial meaning beyond what the schema already provides. 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 clearly states a specific purpose: 'Śledź zmiany prawne i nowe publikacje w zakresie dat' and 'Zwraca akty prawne opublikowane lub zmienione w podanym zakresie dat.' This identifies both the action and the resource. It does not explicitly differentiate from sibling tools like search_legal_acts, but the date-range orientation makes the tool's role reasonably distinct.

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 date-based legal change tracking and gives concrete examples of valid parameter combinations. It also directs the agent to use filter_results for narrowing result sets, which is useful downstream guidance. However, it does not explicitly state when to use this tool instead of search_legal_acts, browse_acts, or other siblings, nor does it list exclusions.

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