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

Annotations already cover read-only/idempotent/open-world, but the description adds behavior they cannot convey: filters are target-scoped, the meaning of date_from/date_to shifts by target, boolean `conditions` are evaluated in order and are 'not combinable with the keyword fields'. That incompatibility rule alone is high-value operational context.

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 core mode-of-operation ('Pick a `target`, then either keyword groups or boolean conditions'), then proceeds to filter mapping and date semantics. Dense, run-on sentences, but for a 23-parameter tool nearly every clause carries necessary 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?

Covered: target semantics, filter-to-target mapping, target-dependent date meaning, the keyword-vs-boolean exclusivity, prerequisite catalogue lookups, and the article-number workaround. An output schema exists, so return values need not be described. An agent has everything needed to construct a valid call.

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?

With only 57% schema description coverage, the description carries real weight: it enumerates which filters apply to each target (act_types/authority_ids, collectivity_ids, code_slugs/section_types, courts/court_orders/decision_types/case_number, consolidated_*) and redefines date_from/date_to per target. It does not clarify sort/page/page_size beyond the schema, leaving some gap.

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 (structured search) and immediately scopes it to 'precise requests: acts of a given type and authority over a period, decisions of a given court, articles of selected codes', which makes the tool's niche legible. It stops short of naming leginova_search as the simpler sibling alternative, so the contrast is inferred rather than stated.

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?

Explicitly says when to reach for it ('Use it for precise requests...') and routes prerequisites to siblings: IDs must come from leginova_get_catalogue, and there is a stated negative case with an alternative ('no article-number field here: use leginova_get_code_article'). This is textbook when/when-not/alternative 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?

Annotations already declare read-only, idempotent, open-world behavior, so the bar is low; the description adds the dual-mode return shape and the offset/limit paging behavior, which is genuine extra context. It omits auth requirements, rate limits, and the shape of the per-year count vs full-entry responses, keeping it short of a 5.

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, front-loaded with the core behavior, then collection semantics, then a usage cue; each sentence earns its place. Slightly dense but no wasted 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?

An output schema exists, so return values needn't be explained. The description covers both modes, all collection values, paging, and a use-case trigger, giving an agent everything needed to invoke it correctly alongside its many 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?

With 0% schema description coverage, the description carries the full burden and largely succeeds: it explains `year` semantics per collection (adoption year, hearing year, etc.), that offset/limit drive paging, and lists all four enum values for `collection`. It does not convey the year bounds (1850-2300) or limit cap (500), so not fully compensatory.

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 (Lists) and resource (a collection) and precisely describes the two operating modes: without `year` returns counts per year, with `year` returns every entry paged by offset/limit. It enumerates the four collection values with their year semantics, so an agent can distinguish this from the search/get siblings 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?

Gives a concrete when-to-use trigger ('what was published in 2025' questions that a keyword search cannot express), implicitly routing away from keyword search. It does not name the actual sibling (e.g. leginova_search or leginova_advanced_search) or state when-not conditions, so it falls short of explicit alternative naming.

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 a safe, idempotent, read-only, open-world lookup, so the safety profile is covered. The description adds one useful behavioral hint – that the unfiltered result can be long, hence the `contains`/`section` filters – but says nothing about result size limits, pagination, or whether identifiers are returned with labels.

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 tightly-packed sentences, front-loaded with what the tool returns and followed by the filtering advice. Every clause earns its place, though the phrase "keep the answer short" is slightly informal where a concrete size hint would be more useful.

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-optional-param reference-lookup tool whose annotations cover the safety profile and which has no output schema, the description tells the agent what the payload is (search identifiers) and how to constrain it. It does not describe the shape of a returned entry (identifier plus label), which is the only meaningful remaining gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%: `contains` is documented in-schema (case-insensitive label filter) while `section` is a bare enum. The description restates the section categories, which maps loosely to the enum values (though it omits `all` and `court_orders`), adding minimal meaning beyond what the enum already conveys. Baseline 3 for partial coverage 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 makes clear this returns the vocabulary/identifiers that leginova_advanced_search accepts, and names the sibling it supports, which distinguishes it from list/browse siblings. It never states an explicit verb ("Lists" or "Returns"), leaving the action implicit, which keeps it just short of a 5.

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

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

Usage context is clearly implied: fetch these identifiers to feed leginova_advanced_search, and narrow with `section`/`contains` when the full list is too long. There is no explicit when-not or a stated alternative tool for the same need, so it stops short of 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 cover read-only/idempotent/open-world safety, so the description is free to add the behavior that matters: prefix-tolerant matching, the match_status disclosure, the Lp. vs L. New Caledonia distinction, duplicate numbers across prefixes, and the critical caveat that not_found is never proof no legal basis 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?

Front-loads the return value and the two input paths before the edge cases, which is well ordered. It is dense and the New Caledonian loi du pays digression is lengthy, but each sentence carries real disambiguation value.

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 elaboration, and the description covers matching semantics, defaults and the failure-mode caveat. Nothing an agent needs to call this correctly 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, but the description genuinely adds meaning: it explains that article_number matching is prefix-tolerant with concrete variants, and that omitting code_slug broadens the search to all codes, which the schema only states tersely.

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 ('Returns one code article') and enumerates what comes back (text, amendment history, place in the code, previous/next articles, official URL). This clearly separates it from search, outline and section-reading 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?

Explains the two entry paths (article_slug from search results or outlines, or article_number) and that omitting code_slug searches every code. It gives a clear usage context but does not explicitly say when to prefer read_code_section or search 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, openWorldHint, destructiveHint=false, so safety is covered. The description adds real behavioral value by disclosing the shape of the response (counts, slugs) and the intended iterative browse strategy, though it says nothing about size limits or pagination of large outlines.

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, zero filler. The resource/return summary comes first and the traversal advice second, so the agent gets purpose then action in reading order.

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

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

With no output schema, the description usefully names the returned artifacts (article counts, section_slug/article_slug), which is what an agent needs to chain into a follow-up call. It is slightly thin on the depth/result-size tradeoff, but otherwise complete for a read-only outline 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 depth, code_slug and section_slug are already documented, including the depth default and the pointer to leginova_list_codes. The description only reinforces depth 2 and the section_slug drill-down, adding marginal 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?

Names a specific resource (a code's table of contents) and enumerates the hierarchy it covers (parts, books, titles, chapters, sections), plus what it returns (article counts, section_slug/article_slug). This clearly separates it from siblings like leginova_get_code_article and leginova_read_code_section.

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 explicit operating guidance: start broad with depth 2, then drill in via section_slug. That's a usable when/how, but it never names an alternative sibling (e.g. read_code_section) or states when to prefer reading a section directly over navigating the outline.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds meaningful behavioral context beyond that: documents run to hundreds of pages and first access downloads up to 60 MB taking a few seconds, which explains latency and why paging is required.

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

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

A single compact paragraph with the core purpose front-loaded and the operational warning attached at the end. Efficient, though the parenthetical detail about PDF size slightly crowds the purpose statement.

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

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

With no output schema, the description does enough: it identifies the document type, identifier format, paging approach and the download cost. The one gap is that max_chars behavior and the default page window remain unexplained.

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 75% and the description reinforces the page-range model and the numero format. However, max_chars is undocumented in both schema and description, and no extra syntax or defaulting guidance is added 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?

States a specific verb (Reads) and resource (record of a sitting, 'compte rendu des débats') with the identifier format, and the extraction mechanism (official PDF by page range). This clearly distinguishes it from siblings like leginova_get_jonc or leginova_get_jurisprudence, which cover different document types.

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 closing instruction 'read them page range by page range' gives implied usage guidance driven by document size, but there is no explicit statement of when to choose this tool over alternatives such as leginova_search or leginova_browse, and no 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 readOnly/idempotent/non-destructive/openWorld, so safety is covered; the description adds genuinely new behavior by describing the two return shapes (full act vs. TOC with act ids) and the semantic meaning of the issue date. No output schema exists, so this prose return-shape disclosure is doing real work; it stops short of describing pagination or failure modes.

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 core action, then dense but useful routing in three sentences. Slightly parenthesis-heavy, yet every sentence carries distinct information (return shapes, item hand-off, year listing).

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 one parameter, no output schema, and annotations covering safety, the description supplies the missing return-value semantics and sibling routing. It is complete enough to invoke correctly; only edge cases (invalid numbers, empty TOC) are unaddressed.

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 param is already described, so the baseline is 3; the description goes beyond it by explaining what the two number formats mean and what each yields, which the schema's bare 'e.g.' does not convey.

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 ('Opens an issue of the Journal officiel de la Nouvelle-Calédonie') and crucially disambiguates itself from siblings: it explains that JONC-number lookups return the act while plain numbers return a table of contents, and points to leginova_get_jonc_item and leginova_browse. An agent can distinguish this from leginova_browse and leginova_get_jonc_item 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?

Explicit routing: it tells the agent that plain numbers return a TOC whose per-act ids are passed to leginova_get_jonc_item, and that leginova_browse lists the issues of a year. When to use this tool versus the two nearest alternatives is spelled out rather than inferred.

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?

Beyond the readOnly/idempotent/openWorld annotations, the description discloses important behavior: returned publication date and filing authority, text_status values, automatic PDF text extraction with pdf_text "auto", and why pdf_without_text_layer means retrying pages is futile. It also explains pdf_scope "whole_issue" as a potential PDF scope. This is unusually rich operational context.

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, then moves efficiently through return values, text availability, and PDF scope. Despite covering complex behavior, every sentence contributes useful information without repetition.

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 lack of an output schema and low schema description coverage, the description supplies the most important return and text-extraction context. It still leaves some parameter semantics implicit, notably id, max_chars, and full page-range behavior, so it is strong but not airtight.

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 only 43%, so the description must compensate. It explains pdf_text behavior and maps item categories to the kind enum, but id, max_chars, and much of the page-range semantics remain undocumented outside 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 gives a specific verb and resource: reads one item published in the JONC, with examples of item types. It clearly distinguishes item-level reading from broader JONC access, allowing an agent to identify the tool without opening the 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?

The description establishes that this tool reads one JONC item and explains PDF/text extraction behavior, but it never explicitly names when to choose it over siblings like leginova_get_jonc or the search tools. Usage is implied rather than contrasted against alternatives.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive). The description adds real behavioral context beyond that: text comes from the official PDF, output is paginated by page range, and `text_status` reports whether text was found and why if not — a useful failure-mode disclosure.

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 core purpose, and the second clause about text_status is well-placed and earns its space. The parenthetical list of jurisdictions is long but informational rather than padding.

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

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

With no output schema, the description must carry return-value burden, and it does flag metadata, full text, and the text_status field. It stops short of describing what the metadata contains or how pages interact with max_chars truncation, but it is complete enough 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 coverage is 75% (slug, page_start, page_end documented; max_chars only carries a default and bounds). The description reinforces the page-range semantics and ties max_chars to the page window ('default: as many as max_chars allows'), adding meaning the raw schema doesn't state.

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 (Reads) and resource (a decision published on Leginova), and enumerates the courts covered, so it is immediately distinguishable from siblings like leginova_search or leginova_get_code_article. The scope — metadata plus extracted full text — is spelled out rather than implied.

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 is clear this tool fetches a decision once you have a slug, but there is no explicit when-to-use guidance and no mention of how it relates to the sibling search tools that produce the slug. The usage is inferable from the slug requirement and the verb, not stated.

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

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

Annotations already declare readOnly/idempotent/openWorld, so the bar is lower, but the description adds real behavioral context: chunked pagination via max_chars/offset, per-mode return shapes, and the important warning that the text is the version in force on the consolidation date and that date must be quoted.

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 action and the mode semantics, then the pagination mechanic and the citation caveat. Dense but every clause carries information; no filler.

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

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

With no output schema and six parameters, the description does the heavy lifting by describing what each mode returns and how paging works. The only modest gap is that include_history's effect is left entirely to the schema's short note.

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 only 50%, so the description must compensate, and it does for the key parameters: it explains what each mode returns, that max_chars chunks the output, that offset continues the read, and that article_id scopes to one article with its history. Only `include_history` and `id` are left to 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?

Clearly states a specific verb and resource ('Reads a consolidated text') and disambiguates from the code-oriented siblings by naming the legal source types (loi, délibération, arrêté). It also spells out the two operating modes, so the agent knows the tool's shape, though it never explicitly contrasts itself with leginova_get_code_article or leginova_read_code_section.

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 selection guidance between mode 'outline' and 'full', explains when to pass article_id, and instructs the agent to pass back `offset` to continue paging. It lacks any explicit when-not or named-alternative routing, but the context is strong.

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 establish the safe read-only, idempotent, open-world profile, so the bar is lower. The description still adds real value beyond them by disclosing latency ('takes a few seconds' on the first call) and the fact that the call reads every code, which the annotations do not convey.

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 purpose is front-loaded, but the description runs long: the two Nouvelle-Calédonie filing examples and the mixed-code/prefix explanation are educational and back-loaded, only tangentially serving tool selection. Useful for interpreting output but not tightly edited.

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-value documentation is not required, and the description instead prepares the agent for data quirks (misleading titles, mixed State/loi-du-pays codes, per-article competence). That is adequate coverage for a no-argument listing tool; only the absence of explicit routing to siblings leaves a small gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters and schema coverage is effectively complete, so there is nothing for the description to clarify. Baseline 4 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 (lists) and resource (the 31 consolidated codes) and enumerates the fields returned: slug, filing authority, and published-version date. It hints at its role as the entry point for the other code tools but never names a sibling it should be preferred over, so differentiation is implicit rather than explicit.

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 'the slug every other code tool expects' and 'the first call reads every code' imply this is the prerequisite entry point before the code-outline/article tools, which is useful. However, no alternative tool is named and no explicit when-to-use/when-not-to-use condition is stated, so guidance is inferred rather than 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 the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds real behavioral context beyond them: results are in reading order and long sections are chunked with an offset continuation protocol. It does not mention limits or what happens at the end of content, keeping it short of a 5.

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, front-loaded with the return content and followed by the one operational rule that matters. No filler, no restatement of the title.

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

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

There is no output schema, so the description carries the burden of describing returns, and it does so adequately (full text, all articles, reading order, chunking). The only meaningful omission is max_chars, which an agent may need to tune for large sections.

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 50%: code_slug and section_slug are documented in the schema, while offset and max_chars are not. The description compensates for offset by explaining its continuation role, but max_chars (default 30000, range 2000-100000) is left entirely unexplained in both places. 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?

States a concrete verb+resource ('Full text of a code section ... with all its articles, in reading order'), which implicitly separates it from leginova_get_code_article (single article) and leginova_get_code_outline (structure only). It never names those siblings explicitly, so the differentiation is inferable rather than stated.

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 second sentence gives a clear operational instruction for pagination ('pass back `offset` to continue'), which is genuinely useful. However, there is no when-to-use/when-not guidance relative to siblings like get_code_article or get_code_outline; the intended usage is only implied by the content 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 cover the safety profile (readOnly/idempotent/non-destructive), so the description uses its space for genuinely additive behavior: default AND semantics, exact-phrase quoting, operator keywords, the shape of each result (official URL to cite plus a `next` tool call), and the scope→facets→filters round-trip. This is real behavioral context beyond structured fields.

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?

Dense but front-loaded: what it searches, then query grammar, then result shape, then facet loop, then the alternative-tool caveat. Every sentence carries information, though the single block is long and could be broken up for faster scanning.

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 11 parameters, nested `filters`, an output schema, and a rich set of 13 siblings, the description supplies what the schema cannot: the query language, the facets/filters workflow, and routing to leginova_get_code_article. Since an output schema exists, it correctly avoids describing return values in detail.

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 parameters are already well documented and the baseline is 3. The description adds meaning the schema lacks: that `scope` must be restricted for facets, that facet values flow back through `filters`, and that queries are French-language with a specific operator grammar. It does not cover date or pagination semantics, which the schema handles.

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 ('full-text search across the official law of New Caledonia on leginova.gouv.nc') and enumerates the covered collections (JONC, consolidated texts, codes, case law, Congress debates). It explicitly distinguishes itself from the sibling leginova_get_code_article for article-by-number lookups.

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 concrete when-to-use guidance (write queries in French, use scope to get facets, feed facets back through filters) and an explicit when-not: an empty result is not proof a rule doesn't exist, and to fetch a code article by number use leginova_get_code_article. Query-operator semantics (AND default, quotes for exact phrase, OU/SAUF) are documented 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 structurally. The description adds a cost/latency trait relative to search, which is genuinely useful, but says nothing about result caps, ranking, or pagination behavior for an autocomplete endpoint.

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, zero filler, with the core behavior and output shape front-loaded and the cost comparison as a trailing qualifier. Nothing could be cut 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?

An output schema exists, so return values need not be explained, and the description still hints at the id/slug payload. Combined with annotation coverage, the definition is nearly sufficient; only the undocumented scope parameter leaves a small gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%: 'query' is documented and the description's sample strings ('code du travail', 'loi du pays 2021-2', 'télétravail') usefully indicate expected phrasing, including accented French. However, the six-value 'scope' enum carries no explanation in either schema or description, so the description does not fully compensate for the coverage gap.

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

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

The description names a specific operation ('Autocomplete over titles') and states exactly what it returns (documents with their ids and slugs), which is enough to distinguish it from leginova_search without opening either schema. The examples of partial inputs make the resource concrete.

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 an explicit selection rule against a named sibling: use this 'cheaper than a search when the target is known by name'. That is clear routing guidance, but it stops short of stating when-not-to-use cases (e.g. broad or fuzzy discovery, where search should win).

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