TAAP MCP

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

Annotations already cover read-only, idempotent, non-destructive and open-world, so the bar is lower; the description still adds real behavior: what citation forms are matched, that validation is against TAR, and that constitutional-ruling matching is title-only with no outcome data. It doesn't mention cost/rate characteristics of up to 300 external checks, which is the main remaining 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?

Front-loaded with the one-sentence purpose, followed by a compact catalogue of recognised citation forms with Lithuanian examples — every element earns its place. Slightly long, and the examples could be trimmed without losing 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?

With an output schema present, return-value explanation is rightly omitted, and all four parameters are covered by the schema. Usage relative to the near-duplicate lt_resolve_reference is the one thing an agent still has to guess.

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 schema already explains text, as_of, max_references and include_constitutional_rulings in detail. The description adds meaning only indirectly, through the enumeration of citation patterns it will find; it adds no format or limit guidance beyond the schema. Baseline 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?

States a specific verb and resource: extract every cited act/provision from a document and validate each against TAR. The scope is unambiguous, but the closest sibling (lt_resolve_reference, which resolves a single reference) is never named, so an agent must infer the bulk-vs-single 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?

Gives clear context for when the tool fits (documents that cite other acts by number/date, name, defined short name, or provision) and explicitly routes one sub-case away: 'no outcomes - use lt_find_rulings_on_act for those'. No exclusion against lt_resolve_reference or lt_search, so not a full 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?

Annotations already mark the tool read-only, idempotent, and open-world; the description adds meaningful context about sourcing, known gaps, and the fact that empty results may reflect connector gaps rather than the law. No contradiction with annotations.

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?

Three compact blocks: what it does, when to call it, and what it returns. Every sentence earns its place and the usage trigger is front-loaded before the return format.

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 zero-parameter tool with rich annotations and an output schema, the description covers purpose, timing, gap behavior, fallback, and return shape. Nothing essential is missing for an agent to select and invoke 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?

The tool has zero parameters and the schema is fully covered, so there are no parameter semantics to explain. The description's references to families, as-of note, and gaps are return-value details, not parameters. Baseline 4 for a 0-param tool.

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 purpose: declare what the connector covers, how it is sourced, and what it does not cover. It distinguishes itself from sibling search/retrieval tools by focusing on coverage gaps and fallbacks, not legal content.

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 explicit when-to-use guidance: call before telling a user the law 'does not contain' something and whenever a search comes back empty. It does not name sibling alternatives or explicit when-not-to-use 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds the useful domain detail that the two dates correspond to consolidated editions, but says nothing about behavior when an edition doesn't exist for a date, or how the diff is presented.

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 that carries the verb, scope and the edition semantics with zero filler. Nothing could be removed without losing 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?

With an output schema present and full parameter documentation, most structural information is elsewhere, so the description doesn't need to explain return values. However, for a diff tool it leaves open edge-case behavior (identical dates, missing editions) that an agent might need before calling.

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 (including the to_date default of today). The description only reinforces that the two dates denote consolidated editions, which adds marginal meaning beyond the schema — baseline 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?

States a specific verb ("Compare") and resource ("the provisions of an act") with a clear scope ("between two dates"). It is readily distinguishable from siblings such as lt_get_edition_text or lt_list_editions, though it never names an alternative explicitly.

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 comparative framing implies when the tool is appropriate (you want a before/after view across two editions), but there is no explicit when-to-use, when-not-to-use, or named alternative. The agent must infer that a single-edition read should use lt_get_edition_text instead.

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 readOnly/idempotent/non-destructive/open-world, so the safety profile is covered. The description adds genuinely non-obvious behavior: how KT titles are matched (current and former act titles, or date+number for subordinate acts) and that include_outcomes fetches full texts and parses the operative part. It stops short of saying what happens on zero matches or how results are ordered.

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 lead sentence front-loads what the tool returns, and the second paragraph carries the matching/outcome detail. It is dense with domain shorthand ('KT titles', 'operative part') that assumes Lithuanian constitutional-law familiarity, but no sentence is 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?

With an output schema present, return values need not be spelled out, and the description still explains what 'outcome' contains. The matching heuristic and the slower-path flag are covered. Remaining gaps (empty-result behavior, ordering, limit interaction) are minor for a read-only lookup tool.

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 earns an increment by explaining that provision narrows to a single article and that include_outcomes causes the operative part to be read into 'outcome' plus the mentioning items. The matching rule for tar_kodas (date and number for subordinate acts) also adds meaning beyond the example value 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?

States a specific verb+resource: find Constitutional Court rulings concerning a given act, optionally narrowed to one provision, and return their outcome. The parenthetical about KT title matching further pins down the resource being matched. It does not, however, explicitly contrast itself with the sibling lt_search_court_rulings, so an agent must infer the difference from the 'on a given act' framing.

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 input shape: supply a tar_kodas (and optionally a provision) when you want rulings tied to a specific act. There is no explicit when-to-use/when-not guidance and no pointer to lt_search_court_rulings for free-text ruling search. The include_outcomes tradeoff ('slower') is the only cost/benefit guidance offered.

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 readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds that validity and issuer fields are included, but says nothing about the optional date parameter's effect on the response or any rate/auth considerations; with an output schema present, the remaining gap is modest.

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 filler; the resource and key selector are stated first.

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 rich annotations, a full output schema, and 100% schema coverage, the description only needs to orient the agent, and it does. It could have noted the optional date's effect on results, but nothing required for correct invocation 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 both parameters (including the date/consolidated-edition semantics) are fully documented in the schema. The description adds no parameter detail beyond echoing the validity concept, which is the expected baseline when the schema does the work.

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?

States a specific verb (fetch) and resource (Lithuanian act metadata) keyed by TAR code, and names the returned field groups (validity, issuer). It implicitly contrasts with text/provision siblings via 'metadata' but doesn't name them, so it stops short of full sibling differentiation.

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 when-to-use or when-not guidance, and no sibling alternatives are mentioned. The only hint of a workflow is the schema's note that tar_kodas comes from lt_search, which is not in the description itself.

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds that the result includes extracted text, metadata and a download URL, which is useful but does not disclose rate limits, size limits, or behavior when extraction is unavailable.

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 zero filler; the Lithuanian term 'priedas' is parenthetically glossed without bloating the text.

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?

An output schema exists, so the description need not explain return values, yet it briefly names them. For a two-parameter read-only fetch, nothing an agent needs in order to call it correctly is missing; only calling-sequence guidance is absent.

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 both parameters are documented there, including the lt_list_attachments provenance for priedo_id and the example format for tar_kodas. The description adds nothing beyond the schema, so baseline 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?

States a specific verb+resource (fetch one attachment of an act) and names the content returned (text, metadata, download URL). The word 'one' implicitly contrasts with the sibling lt_list_attachments, though it never names that sibling explicitly.

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 only implied: it's a retrieval-by-id tool, so the agent infers it must first obtain an attachment id via lt_list_attachments — but that hint lives in the schema, not the description. No when-not guidance or explicit alternative 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?

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so safety is covered. The description adds the structural point that the act is returned with its parts separated, but says nothing about default part selection, size of returned text, or truncation behavior.

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 front-loaded sentence with no filler. It is perhaps too terse for the job, but nothing is 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?

An output schema exists, so return values need not be explained, and the schema carries the parameter semantics. Still missing is the routing information an agent needs to choose this tool over the two search siblings and lt_get_act.

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%: both tar_kodas and the part enum-with-default are fully documented in the schema, including the operative/reasoning/facts/all values. The description adds nothing on top, so the baseline 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?

A specific verb (Fetch) and resource (Constitutional Court act) with the 'parts split out' qualifier. This distinguishes it reasonably well from lt_get_act, though that distinction rests on the reader knowing lt_get_act covers ordinary legislation rather than court rulings.

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 statement of when to use this versus lt_search_court_rulings, lt_find_rulings_on_act, or lt_get_act. The only hint that it consumes a code produced by the search tools lives in the schema, not the description.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered without the description. The description adds the useful fact that results are scoped to the act's definitions section and returned with provision ids, but says nothing about behavior when the act has no definitions article or how the date affects the result (that lives in 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?

A single, front-loaded sentence that names the operation, the domain-specific concept, and the return shape with zero filler. Nothing could be removed without losing 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?

With a full output schema, complete parameter documentation, and annotations covering the safety profile, the description only needs to convey the intent and scope, which it does. A minor gap is not addressing the empty/no-definitions case, but nothing essential for correct invocation 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%, with both parameters documented in the schema, including the ISO date format and its 'text in force that day' semantics. The description adds no parameter-level detail beyond what the schema already provides, so the baseline 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 states a specific verb and resource: 'List the terms an act defines', and clarifies the concept with the Lithuanian term 'sąvokos' plus the note that these live in a dedicated article or point. It also mentions the return payload (provision ids), so an agent can tell this apart from generic text-fetching siblings like lt_get_text or lt_get_provisions. It does not explicitly name which sibling to use instead, which keeps it from 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?

Usage is only implied: an agent infers it should call this when it wants the defined-terms section of an act rather than the full text. There is no explicit statement of when to prefer this over lt_get_provisions or lt_get_text, and no prerequisites or exclusions are 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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds nothing about output size, format, or whether the returned text reflects amendments consolidated up to the requested date — a meaningful gap for a legal-text 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?

One sentence, front-loaded with the verb and resource, with no filler. Every clause (in-force date / specific edition) carries 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?

With a full output schema and rich annotations, the definition covers what the tool returns and how it is selected. The one real omission is disambiguation from the adjacent lt_get_text and lt_get_act 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%, so date, tar_kodas and suvestines_id are already documented. The description reinforces the mutual exclusivity of date vs edition, but adds no format details beyond the schema's own ISO example and default-today note.

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?

Specific verb ('Fetch') plus resource ('consolidated text of an act') and a clear scope qualifier: the version in force on a date or a named edition. It does not explicitly say how it differs from sibling lt_get_text or lt_get_act, so it falls 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?

The phrase 'in force on a date, or a specific edition' implies the two calling modes, and the schema ties suvestines_id to lt_list_editions, but the description never states when to use this instead of lt_get_text, lt_get_act, or lt_diff_editions.

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, idempotentHint, non-destructive and open-world, so the safety profile is fully carried by structured data. The description adds only that the result includes the provision text plus a ready citation; it says nothing about failure modes for an unresolvable reference, the date/versioning behavior, or the 'alternatives' fallback for multi-document acts.

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 zero filler, leading with the action and scope and closing with the payload. Nothing is padded and nothing needs trimming.

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?

An output schema exists so return values need no explanation, annotations cover safety, and the schema fully documents parameters. The remaining gap is small: a clause about unresolved references or the point-in-time date semantics would complete the picture for a tool whose resolution rules are non-trivial.

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 four parameters (ref formats, ISO date, document index, tar_kodas) are already documented in detail, and the baseline of 3 applies. The description contributes only the phrase 'by reference', adding no 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 states a specific verb ('Fetch') and resource ('one provision of an act') and signals the return payload ('full text and a ready citation'). It implicitly separates itself from the singular/plural sibling lt_get_provisions ('one provision'), but never names a sibling or the act-level alternative lt_get_act.

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 only implied: 'by reference' hints that the caller should already hold a reference, but there is no explicit when-to-use, when-not, or named alternative (e.g. use lt_get_provisions to discover references, lt_get_text for the whole act). The agent must infer the routing from the tool name and 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 annotations already declare read-only, idempotent, open-world, and non-destructive behavior. The description adds useful behavioral context beyond annotations: provision ids follow specific patterns, amendment notes appear in each provision's notes, and amending acts appear in amendments.

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 the core purpose and then uses compact detail to explain id conventions and special document cases. It is dense but mostly earns its length, though the formatting and parenthetical examples make it less immediately 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?

For a structure-listing tool with an output schema and safety annotations already present, the description gives enough context to call it correctly. It explains id conventions, subordinate act differences, numbered documents, and amendment-related fields, with only sibling routing left implicit.

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 four parameters. The description adds some meaning around document numbering and provision id structure, but it does not materially extend parameter semantics 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 uses a specific verb and resource: 'List the provisions of an act (its structure)'. It clearly explains what is returned, including stable ids and references, but it does not explicitly distinguish this tool from siblings such as lt_get_provision or lt_get_text.

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 explaining that this tool lists an act's provision structure, but it does not state when to choose this over alternatives like lt_get_provision for a single provision or lt_get_text for full text. No exclusions or alternative routing 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?

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds genuinely new behavior: the edition-selection fallback and the fact that a 'stale' flag plus a text_source field signal which edition was returned. However, output-shape details are left to the output schema, so the added context is moderate rather than 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?

The core statement is front-loaded in the first sentence, and the following sentences explain the edition priority and the text_source signal. Slightly dense with internal terminology ('suvestine redakcija', 'stale') but each clause carries decision-relevant 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?

With an output schema present and annotations covering safety, the description only needs to explain retrieval semantics — which it does via the explicit edition-priority chain and the text_source indicator. Complete enough to invoke correctly; only the sibling-selection guidance 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?

There is a single required parameter whose schema description already carries 100% coverage, so the schema does the heavy lifting. The description only restates that lookup is by TAR code and adds no format guidance beyond the schema's example 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?

States a specific verb and resource ('Fetch the full Lithuanian text of an act') plus the identifier type (TAR code) and the temporal scope ('version in force today'). It implicitly separates itself from siblings like lt_get_edition_text or lt_get_provision by promising the whole act's current text, but it never names an alternative explicitly.

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 fallback chain (consolidated in force today → newest stale consolidated edition → original text) tells the agent exactly what it will get in each situation, which is strong decision-support. It stops short of saying when to prefer a sibling such as lt_get_edition_text for a historical version.

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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds genuinely new behavior: probes are not cached, so the call yields fresh state without polluting or reading stale cache. It also decodes the status taxonomy, notably that 'degraded' means plain reads work but filtered queries fail — context that cannot be inferred from annotations.

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?

Front-loaded with the purpose, then the trigger, then the return shape — a sensible order with no filler. The 'Returns:' block slightly restates what the output schema already declares, a minor redundancy but it does add the semantic gloss on status values.

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 zero-parameter diagnostic tool with a real output schema, the description supplies exactly the missing pieces: when to invoke it, that probes bypass the cache, and how to interpret the three status values. Nothing an agent needs in order to call or interpret it is absent.

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 tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. It correctly avoids spending text on nonexistent inputs.

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?

States a specific diagnostic verb-object pair: check whether data.gov.lt answers and how the local cache looks. This is clearly distinct from the retrieval-oriented siblings (lt_search, lt_get_act, etc.), which an agent can tell apart without opening any schema.

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?

Gives an explicit trigger condition: call it when a tool returns upstream_error or served_from_cache=true, and importantly 'before concluding anything from a failure.' This is actionable routing guidance rather than implied usage.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description adds the useful behavioral detail that results are keyed to the provisions actually changed, but says nothing about result volume, ordering, pagination, or behavior when an act has no amendments.

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 with the resource and the returned payload front-loaded. No filler, no restatement of the title or 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 an output schema present, return-value explanation is unnecessary, and annotations plus full schema coverage carry the rest. What remains thin is the temporal dimension: the description does not tie its results to the date-parameterized consolidated edition, which is the one conceptual gap for a legally-versioned listing.

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 the tar_kodas example format and the date parameter's 'edition in force that day' semantics documented in the schema itself. The description's phrase 'amended an act' loosely maps to tar_kodas but adds no syntax, default, or interaction detail beyond the schema, so the baseline 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?

States a specific verb ('List') and a specific resource ('acts that amended an act'), plus the payload each entry carries (which provisions changed). An agent can distinguish this from lt_list_editions or lt_get_act without opening a schema, though it never names a sibling to contrast against.

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 only implied: the phrasing 'amended an act' signals that an act identifier is required, which matches the single required tar_kodas parameter. There is no explicit when-to-use statement, no mention of prerequisites, and no routing to an alternative such as lt_get_act when the agent instead wants the text of the amendments.

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 readOnly, idempotent, non-destructive, openWorld, so safety is covered. The description adds nothing about ordering, empty-result behavior, or how listed attachments map to lt_get_attachment, so it is only minimum viable rather than contradictory.

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 waste. It is arguably under-specified rather than wordy, but nothing is 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?

An output schema exists and annotations cover safety, so the definition is functionally callable. However, for a listing tool the description omits any hint of result shape, empty-list behavior, or the relationship to lt_get_attachment, leaving the agent to infer the list-then-fetch 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 coverage is 100% with a single required parameter (tar_kodas) and an example value, so the schema carries the burden. The description never mentions the parameter, so it adds no meaning beyond it – baseline 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?

States a specific verb+resource ('List the attachments') and clarifies that attachments belong to an act, which distinguishes it from lt_get_attachment (single-item retrieval). It does not explicitly name that sibling, but the list/get split is inferable from the verb.

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 on when to use this versus lt_get_attachment, no precondition that the act must exist or that tar_kodas comes from lt_search/lt_get_act, and no note about what to do with the result. Usage is only implied by the verb.

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is fully covered structurally. The description adds the meaningful behavioral detail that results are ordered newest first, but says nothing about volume, pagination, or how "consolidated" editions differ from amendments.

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 sentence with zero waste; the resource and the ordering constraint are both front-loaded and immediately actionable.

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?

An output schema exists, so return values need not be explained, and the description covers purpose plus ordering. Remaining gap is modest: for a tool sitting beside lt_get_edition_text and lt_list_amendments, one clause on the handoff to those siblings would complete it.

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 single tar_kodas parameter carries an example value, so the schema does the heavy lifting. The description only restates that the input is an act, adding no format, validation, or error semantics 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?

States a specific verb and resource ("List the consolidated editions") plus the result ordering ("newest first"), which an agent can map to a concrete task. It does not name the sibling that fetches a single edition's text (lt_get_edition_text) or lt_list_amendments, so the boundary is left to inference.

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 only implied by the phrase "of an act" – the agent must infer that this is the entry point for edition history rather than amendment history or edition text. No explicit when-to-use, no prerequisites, and no named alternatives among the many lt_* siblings.

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 cover read-only/idempotent/open-world; the description adds genuinely useful behavior beyond them: multiple candidates are returned because numbers aren't unique, and each carries the individual checks (number/date/type/title match, validity on as_of). This tells the agent to expect and interpret a ranked set rather than a single hit. It doesn't discuss ambiguity resolution order or tie-breaking.

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 paragraphs, front-loaded with the verb and resource, then the rationale and the return behavior. Every sentence carries information; the example citation is the most efficient way to convey format.

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?

An output schema exists and all six params are documented, so the description only needs to explain the intent and candidate/check semantics – which it does. It could go slightly further on how an agent should pick among candidates or what to do when checks conflict, but nothing essential for calling it 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% and each parameter already documents its format and examples, so the description can't do much beyond reinforcing the number+date citation pattern. It does clarify that title is used alone when no number is given, a small cross-parameter insight.

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?

States a specific verb (resolve a citation) and resource (TAR acts), and explicitly contrasts with the identifier-based lookup approach used by siblings like lt_get_act: citations are by number+date, not TAR code. The example citation anchors exactly what input it expects.

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?

Explains the core problem it solves (documents cite by number/date, official numbers aren't unique) which implies when to use it vs. lookup-by-code tools. It doesn't explicitly name a sibling alternative or state exclusions, but the problem framing is a clear selection signal.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds the case-insensitivity trait, but says nothing about behavior with zero arguments (does it return everything up to limit?), whether filters combine with AND, or pagination depth. With annotations doing the heavy lifting, this is a modest add.

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 filler or redundancy. It is efficient, though for an 8-parameter tool with all-optional inputs it is arguably undersized rather than optimally sized.

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?

An output schema exists, so return values need not be described, and the schema documents every parameter. What is missing is what happens when no filter is supplied (broad scan capped at `limit`?) and how multiple filters interact — relevant context for a tool with zero required parameters.

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 carries detailed prose (diacritic sensitivity, Lithuanian examples, ISO date direction). The description only restates the title-matching behavior already documented in the `contains` field, so baseline 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?

States a specific verb and resource ("Search Lithuanian acts by title") plus the matching semantics (case-insensitive). It implicitly distinguishes itself from full-text siblings like lt_search_in_act and lt_search_court_rulings by scoping to act titles, but never names them explicitly.

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 word "optional" signals that filters need not be supplied, and "by title" implies this is a title-lookup rather than a full-text search. However, there is no explicit guidance on when to prefer lt_search_in_act, lt_get_act, or lt_search_court_rulings, and no stated preconditions 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is fully covered and the description need not repeat it. It does add one genuinely new behavioral fact — results come back "newest first" — which affects how an agent consumes output. It says nothing about total counts, empty-result behavior, or whether pagination beyond limit exists.

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 filler. Every clause (Constitutional Court, TAR registration, newest-first ordering) carries information an agent 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?

With an output schema present, full parameter coverage, and complete annotations, the description only needs to establish scope and ordering, which it does. The one residual gap is that a limit-only, newest-first tool gives the agent no hint about how to reach older results or how many 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%, including examples for `contains` and the ruling_type enumeration spelled out in prose, so the baseline is 3. The description itself adds no parameter meaning beyond the schema, which is acceptable here since the schema carries the 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?

Specific verb ("Search") plus a precisely scoped resource (Constitutional Court acts registered in TAR), with the Lithuanian term disambiguating the institution. It does not, however, distinguish itself from close siblings like lt_find_rulings_on_act or lt_get_court_ruling, so an agent must infer the boundary from names alone.

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 never states when to use this tool versus lt_find_rulings_on_act (rulings about a specific act) or lt_get_court_ruling (fetch one ruling by id). No prerequisites, exclusions, or routing guidance are given; usage is only implied by the word "Search".

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 readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds the key scoping trait (results are provisions of a single act, matched on wording) but says nothing about the date-versioned view, result limits/pagination, or what a match looks like.

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 filler; every word earns its place. It is arguably too terse for a 5-parameter tool, but there is no structural waste.

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?

An output schema exists and the schema fully documents parameters, so the description need not explain returns. What is missing is the relationship to the dense sibling set (lt_search, lt_get_provisions, lt_get_text) and the date-versioning behavior that materially affects results.

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 query, tar_kodas, date, limit, and ignore_diacritics are all documented with examples in the schema. The description adds no parameter detail beyond the general notion of matching a phrase, so the baseline 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?

States a specific verb+resource+scope: full-text phrase search restricted to the provisions of a single act (identified by tar_kodas). This is meaningfully narrower than a general search, so an agent can tell it is provision-level and act-scoped, though it never names the sibling tools it differs from.

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 only implied: 'one act' signals this is the tool for searching inside a known act, in contrast to the corpus-wide lt_search. There is no explicit when-to-use/when-not statement, no mention of preferring lt_search for multi-act queries, and no guidance on choosing between this and lt_get_provisions.

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