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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the description only needs to add context — and it does: case and diacritic insensitivity and the fact that each match is returned with surrounding text. Nothing contradicts the annotations; the only omission is any note on result limits or pagination.

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 tight sentences, front-loaded with the core behavior, then when to use it, then what it returns and the follow-up call. The example phrases earn their space by showing the exact query shapes ranked search would miss.

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 annotations covering the safety profile, full schema coverage, and an output schema handling return structure, the description supplies everything else an agent needs: matching semantics, targeting guidance, and the follow-up to get_article. There is no meaningful gap for a two-parameter read 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, but the description adds genuinely useful meaning for the required parameter: the phrase is matched literally with case and diacritics ignored, which changes how an agent constructs the query. The optional 'act' scoping parameter is left entirely to the schema, which already documents it.

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

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

The description gives a specific verb and resource ("Find every article that contains a phrase LITERALLY") plus the precise matching rule (case and diacritics ignored). It is clearly distinguishable from ranked search (search_law) because it declares literal matching rather than ranking.

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 says when to use it — numbers and fixed wording that ranked search cannot see — with concrete example phrases ('15%', 'art. 41 alin. (10)'). It also gives a next step ("pull the whole article with get_article"), though it never explicitly states when not to use it or names search_law as the alternative to choose 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered elsewhere. The description still contributes real behavioral context: the result is verbatim and exact, independent of search ranking, which tells the agent the output is authoritative text rather than a ranked snippet. It says nothing about behavior when the act or article does not resolve, 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?

Two sentences, no filler, with the core action and the key differentiator (verbatim, ranking-independent) front-loaded. Every clause earns its place.

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

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

An output schema exists, so return values need no explanation, and the tool is a simple two-required-parameter read. What an agent still might want — behavior on ambiguous act names or a missing article number — is absent, but the definition is otherwise sufficient to invoke 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 both parameters (act, article) are already documented with accepted forms including '24', 'art. 24' and 'Articolul 24'. The description's mention of citation-by-number largely restates that, adding little syntax or constraint information beyond the schema, so the baseline of 3 applies.

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

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

The description gives a specific verb and resource ('Return one article of one act verbatim, by number') and scope ('one article of one act'), which is unambiguous. It implicitly separates itself from ranking-based search siblings ('does not depend on search ranking') but never distinguishes itself from find_exact or outline, which are the most plausible confusions.

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 states an explicit trigger condition: use this whenever an article is cited by number, with a concrete citation example ('art. 24 din Regulament'). It does not state when-not to use it or name an alternative sibling for the non-citation case, so the routing guidance is clear but incomplete.

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 closed-world behavior, so the safety profile is covered. The description adds a genuinely useful behavioral signal, that results carry provenance (consolidation) and freshness (last fetched), enabling currency judgments. It says nothing about result volume or whether the whole corpus is returned in one call, which is the remaining behavioral unknown for a zero-parameter enumeration.

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 sentences, both load-bearing: the first defines the payload, the second defines the decision it supports. The content is front-loaded and there is no filler or restatement of the tool name.

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

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

Given zero parameters, full annotation coverage, and an output schema that documents the returned fields, the description carries only the burden of stating purpose and trigger, which it does. The one gap is scale: an agent cannot tell whether this returns the entire corpus at once or a truncated 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?

The tool takes zero parameters, so there is no parameter meaning for the description to supply. Baseline for a no-parameter tool applies, and the description correctly avoids inventing filtering options that do not exist.

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 enumerates exactly what the call returns per act: size, source consolidation, and last-fetched date, which combined with the name makes the resource and operation unambiguous. It does not explicitly contrast itself with search_law or outline, so sibling differentiation is left to inference from the noun 'each 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?

'Check this when an answer needs to state how current the law text is' gives a concrete triggering condition tied to a user-facing need, which is stronger than generic 'use this to list' guidance. It stops short of naming when-not to use it or pointing to search_law/find_exact as the alternative for content lookup.

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 this as a read-only, idempotent, closed-world operation, so the safety profile needs no restating. The description adds structural context (headings are grouped by chapter), which helps the agent interpret the result, but says nothing about ordering, depth, or size of the outline.

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

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

Two short sentences, zero redundancy, with the capability stated first and the usage rationale second. Every clause earns its place.

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

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

For a one-parameter read tool with annotations and an output schema, the description plus structured fields cover everything an agent needs to invoke it correctly. Only the shape of the outline output is left unaddressed, and the output schema supplies that.

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 act parameter is already documented as accepting an id, number, or a word from the name. The description adds no further meaning about the parameter, so the schema carries the full burden and 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?

"List the article headings of one act, with its chapters" gives a specific verb (list), resource (article headings) and scope (one act, grouped by chapter). It is distinguishable from get_article, which is implied by "before pulling its text," though no sibling is named outright.

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 states a concrete use case: orient yourself in a long regulation before retrieving text. That gives the agent a clear when-to-use signal and implicitly points to get_article for the follow-up step, but no explicit exclusion or named alternative.

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=false, so the safety profile is fully covered elsewhere. The description adds genuinely new behavioral context on top: multilingual query tolerance (Romanian or Hungarian), diacritic insensitivity, and the shape of each hit (article text plus act and chapter, presented for citation).

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 sentences, each doing distinct work: corpus scope, selection condition, language/encoding tolerance plus result shape. Front-loaded, no filler, and the language note is placed where it will be read before the agent types a query.

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 four annotations, a fully documented 3-parameter schema, and a present output schema, the description only needs to supply corpus scope, retrieval semantics and language handling — and it does all three. Nothing an agent needs in order to issue a correct query 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%, so the baseline is 3; the description earns above baseline by adding meaning to the query parameter — it accepts a question or key terms, in Romanian or Hungarian, with optional diacritics. The act filter and limit cap are left entirely to their schema descriptions, which is acceptable given full coverage.

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

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

States a specific verb (search) and a precisely scoped resource (the Romanian surveying-law corpus, enumerated as cadastre, land registry, construction permits, land fund) and says what comes back (matching articles verbatim). It does not name the siblings it is meant to be distinguished from (find_exact, get_article, outline, list_acts), so the boundary is inferable but not declared.

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?

"Use this for a question about what the law requires" gives a clear positive trigger, and the corpus enumeration implicitly scopes out non-surveying-law questions. However, no alternatives are named and no exclusions are given, so an agent cannot tell from this text when find_exact or get_article would be the better call.

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