NLocale

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely useful context beyond that: the temporal window is computed against the current Paris date, and results carry no guarantee of being maintained and involve no reservation. Return format/pagination remain unstated, but the added caveats are substantive.

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 short sentences with no filler, and the core filter (Friday–Sunday published events) is front-loaded. The sector list is the longest element but is genuinely informative 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?

For a read-only listing tool whose annotations already cover safety and idempotency, and with no output schema to explain, the description supplies everything an agent needs to invoke it correctly: temporal scope, geographic scope, and the absence of reservation/maintenance guarantees. The only omission, default result count, is minor.

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 0%, so the description carries the parameter burden, and it only partially does: it enumerates the valid 'secteur' areas (Laon, Saint-Quentin, Soissons, etc.), which meaningfully constrains that free-text field, but says nothing about 'limit' behavior or the 'langue' choice. Partial compensation justifies a middling score.

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

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

The description states a specific resource and scope: published events ('rendez-vous publiés') restricted to the Friday–Sunday window, with a named geographic sector. It is easy to tell what is returned, but it never contrasts itself with the obvious siblings such as rechercher_evenements or chercher_sorties, so the agent must infer the difference.

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 weekend framing and the sector list suggest when this tool is appropriate, but the description gives no explicit 'use this when…, use X instead when…' guidance and never names an alternative among the sibling tools. Adequate but leaves routing to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered elsewhere. The description adds that results carry 'références des fiches publiques et leurs sources' — useful output-content context — but says nothing about pagination, limits, or default 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?

Two compact clauses with no waste, front-loading the alias identity before the filter list. Sentences are short and information-dense, though the second clause could be folded tighter.

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 9-parameter tool with no parameter descriptions and no output schema, the description is on the thin side — it covers filter dimensions and result contents but leaves query, limit, and default values unexplained. It is adequate but not sufficient on its own.

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 across 9 parameters, the description must compensate; it names commune, dates (date_debut/date_fin), catégorie, gratuité, and langue. It omits the two most consequential inputs, 'query' (the free-text search term) and 'limit', so the compensation is only partial.

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 this is a 'stable alias of rechercher_evenements' and enumerates the searchable dimensions (commune, dates, catégorie, gratuité, langue), which identifies both resource and scope. It also names its sibling, letting an agent recognize equivalence without opening schemas, though it never states the verb 'search' directly.

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

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

Calling itself a 'stable alias' implies interchangeability with rechercher_evenements, which is mild routing guidance. However, there is no explicit statement of when to prefer this tool over rechercher_evenements or any of the other recherche* siblings, leaving selection partly to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description still adds genuine context: only the currently public version is returned (so drafts/unpublished states are excluded), visit status and partnership presence are surfaced, and the published signature is explicitly distinct from interviewed persons' identities. That is meaningful behavioral disclosure beyond the 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?

Two sentences with no filler, so it is not bloated. However it is not front-loaded on the action: the first sentence describes output content before the reader knows what the tool does, which weakens scannability.

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

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

For a two-parameter read-only tool with no output schema, the description helpfully covers most of what comes back, which is real value. What is missing is any statement of the identifying input (slug) and any routing versus the sibling search tool, leaving the definition adequate but not complete.

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

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

Schema description coverage is 0% for two parameters. The description covers the meaning of 'langue' ('dans la langue demandée') but the allowed values already sit in the schema enum, and it says nothing about the required 'slug' parameter or its format. It compensates only partially for the missing schema documentation.

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 is a noun phrase describing the returned artifact ('Version actuellement publique de l'article dans la langue demandée') rather than stating the action of fetching one article. It never says the article is identified by slug, and it does not differentiate itself from the sibling rechercher_articles_carnet, which also concerns Carnet articles. An agent can infer the purpose from the title plus this text, but the description alone is only adequate.

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

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

There is no guidance on when to use this versus rechercher_articles_carnet or any other sibling. With nine siblings including a clearly overlapping article-search tool, the absence of routing guidance is a real gap. Only an implicit 'retrieve one thing' reading distinguishes it.

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, so safety is covered. The description adds genuine context beyond that: the record is returned only 'après vérification de la publication actuelle' (i.e., unpublished/stale keys may not resolve) and the response carries an NLocale link, original sources, and distinct retrieval/validation/identity/visit field groups.

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, reasonably front-loaded with the purpose, but the trailing clause listing 'champs distincts pour la récupération, la validation documentaire, l'identité et la visite' is vague jargon that consumes space without clarifying the response.

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 partially compensates by sketching the response contents, and annotations cover safety. However, for a tool whose only input is a constrained key plus a language, the absence of any parameter semantics leaves the definition only minimally viable.

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 0%, so the description carries the burden, yet it never explains the key parameter's prefixed format (event|business|municipality|place|content) or the langue enum/default. It only hints that the key originates from a search, which is marginal compensation for two undocumented parameters.

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

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

The description conveys that it returns factual details for a key produced by a search, and the title supplies the verb (Lire). It does not state the purpose with a clean verb+resource phrasing ('Détails factuels de la clé' is nominal and vague) and never explicitly positions itself as the detail-read counterpart to the chercher/rechercher siblings, though that is inferable from context.

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?

Saying the key is 'retournée par une recherche' implies the prerequisite that this tool follows a search, which is the main routing hint. There is no explicit when-to-use/when-not guidance and no named alternative, so the guidance stays at the implied level.

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, non-destructive, closed-world behavior, so the safety bar is covered. Beyond that, the description adds genuinely useful traits: only published (no drafts), no fallback to another language, and that returned slugs are the entry point to full articles. The no-language-substitution note is real behavioral context an agent needs.

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?

Four short sentences, each carrying a distinct point (content, languages, exclusions, return access), with the core resource description front-loaded. No filler, though the language list slightly duplicates the visible enum.

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

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

For a read-only search tool with no output schema, the description gives decent coverage of what is returned (real author, sources, dates, slugs). However, pagination behavior (limit/offset) and how results are ordered or bounded are absent, which is a gap for a search tool with four 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 0%, so the description must carry parameter meaning, yet it only addresses 'langue' (listing the six languages, which merely echoes the enum) and its no-substitution behavior. The 'query', 'limit', and 'offset' parameters - including pagination bounds - are entirely undocumented in both schema and description.

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 resource (published articles by NLocale - rencontres, coulisses, récits) and the search verb is carried by the tool name and title, so an agent can tell what it returns. It does not, however, differentiate itself from adjacent siblings like rechercher_contenus_publics or lire_article_carnet, which an agent might confuse it with.

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?

'Aucun brouillon ni remplacement par une autre langue' implies scope (published only, strictly the requested language) but no alternative tool is named and no explicit when-to-use condition is given. Usage is inferable from the content description rather than 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, non-destructive, and closed-world, so the safety profile is covered. The description adds real scope context beyond them: it clarifies the data is 'approved and published' institutional info, notes that the actually-available language is surfaced in results, and explicitly excludes statistics, registration data, and private information. That exclusion list is genuinely useful in bounding expectations.

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 sentences with no filler, and the content scope is front-loaded. However, leading with a noun phrase rather than an action statement is a structural weakness for a search tool.

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

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

For a 4-parameter search tool with no output schema and 0% schema coverage, the description is materially incomplete: it explains the data scope well but omits how to invoke the tool (what query/insee_code do, and the limit constraint). An agent cannot confidently construct a call from the description alone.

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 0%, so the description carries the full burden, yet it only hints at the 'langue' parameter by listing the six languages. It says nothing about 'query' (the search term), 'insee_code' (the 5-char code pattern), or 'limit' (default 10, max 20). Three of four parameters are undocumented in both schema and description.

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 never states an action (no verb like 'search' or 'find') and instead only describes the data domain: 'Informations institutionnelles approuvées et publiées.' The name/title carries the actual purpose, so an agent must infer 'search local authorities' from the tool name rather than the description. This is a vague, content-focused purpose rather than a clear verb+resource statement.

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

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

There is no guidance on when to use this tool versus siblings like rechercher_etablissements, rechercher_lieux, or rechercher_contenus_publics. No prerequisites, no alternatives, and no exclusions are stated. The agent is left to infer usage entirely from the name.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds real context beyond that: it discloses the return shape ('chaque résultat comprend une référence vers le détail public et son lien') and the constraint that only content actually published in the requested language is returned — useful given there is no output 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?

Two tight sentences with the resource scope front-loaded and no filler. Efficient, though the second sentence shifts abruptly from corpus scope to return format rather than proceeding in a single logical thread.

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

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

For a search tool with no output schema, the description correctly notes the return payload (a public-detail reference plus link), which is genuinely helpful. However, with five completely undocumented parameters at 0% schema coverage and no required fields, an agent is left guessing about filtering behavior; the definition is minimally viable rather than complete.

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

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

Schema description coverage is 0% across five parameters, so the description must carry the load and largely does not. 'Dans la langue demandée' loosely implies the langue enum parameter, but limit, query, commune and categorie receive no explanation of format, matching semantics or interaction (e.g., whether commune/categorie pre-filter the search).

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 (rechercher/contenus publiés) and enumerates the resource types covered: FAQ, sources, méthode, offres et conditions publiques. That is clear enough to distinguish it from the 'lire_*' detail tools, but it never names or contrasts against the many sibling 'rechercher_*' tools, so sibling differentiation 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?

There is no explicit when-to-use or when-not-to-use guidance, and no alternative is named despite nine siblings (chercher_sorties, rechercher_articles_carnet, rechercher_lieux, etc.). The phrase 'contenus réellement publiés dans la langue demandée' vaguely scopes the corpus but does not tell an agent when to prefer this over a sibling.

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=false and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral note — that verification dates and status reflect checks actually performed — which is data-interpretation context beyond the 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?

Two short sentences with no padding, so it is not bloated. But the brevity comes at the cost of substance, and the second sentence is about result interpretation rather than front-loading what the tool searches.

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

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

A 5-parameter search tool with zero schema coverage, no output schema, and no parameter guidance in the description. The agent knows it reads public records but not what can be queried, filtered, or returned — a significant completeness gap for a search entry point.

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 0% across 5 parameters (limit, query, langue, commune, categorie), and the description mentions none of them. The only enum and all filtering dimensions are left entirely undocumented, so the description fails to compensate for a total 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?

States a verb ("Recherche") and a resource ("fiches publiques NLocale"), so the basic action is clear. But it never says what an "établissement" is or what distinguishes this from siblings like rechercher_lieux or rechercher_collectivites, leaving the agent unable to tell which search tool applies.

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

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

No when-to-use, when-not-to-use, or alternative-tool guidance at all. The second sentence addresses data semantics (verification dates/status) rather than selection criteria, so the agent gets no routing help among the nine sibling search tools.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds a useful scope constraint (only published and active events) and a price disclaimer, but says nothing about pagination behavior despite the limit parameter.

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

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

Two short, front-loaded sentences with no filler, efficient for the space it occupies. The brevity is appropriate structurally even though it under-informs.

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 9-parameter search tool with zero schema coverage and no output schema, the description is too thin. It gives partial output characterization but omits any explanation of how the filters interact, which an agent needs in order to 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?

Schema description coverage is 0% across 9 parameters, yet the description explains none of them — no mention of query, commune, gratuit, periode, dates, categorie or langue semantics. The occurrence/price remarks describe output, not the filtering inputs, leaving the parameters entirely undocumented.

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 resource — published/active events from the NLocale agenda — and clarifies that occurrences are included, which is more than a tautology of the title. It does not, however, distinguish itself from event-related siblings like agenda_weekend or chercher_sorties, so an agent cannot tell them apart from the text 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?

There is no when-to-use guidance, no exclusions, and no reference to alternatives, despite three closely related siblings (agenda_weekend, chercher_sorties) that an agent must choose between. Usage is only implied by the name.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds a conceptual scope constraint (documentary verification is not a visit) but nothing about result format, ranking, or limits. Adds modest value beyond 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?

Two short, front-loaded sentences with no filler. The brevity is genuine conciseness rather than the padding seen in bloated definitions, though it borders on being too terse to be 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 search tool with 5 optional filtering parameters and no output schema, the description is far too thin: it never explains what the search returns, how filters combine, or how many results to expect. Annotations cover safety, but the functional gaps remain large.

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 0% across 5 parameters (query, limit, langue, commune, categorie), and the description mentions none of them. Only the enum/default/min-max constraints in the schema offer indirect hints. The description fails to compensate for the complete lack of parameter documentation.

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 identifies the resource domain ('patrimoine et lieux') but never states the verb of search explicitly, even though the name is 'rechercher_lieux' and the title says 'Rechercher des lieux documentés'. It also does not clearly distinguish this resource from siblings like rechercher_etablissements or rechercher_evenements. Purpose is inferable but only vaguely 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 only guidance is a scope note ('une vérification documentaire ne constitue pas une visite'), which hints at what counts as a documented place but gives no when-to-use, when-not-to-use, or alternatives among the many sibling search tools. The agent must infer selection from the name alone.

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