imprimeur.paris

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds only that the response language is selectable, which is genuinely useful behavior context, but says nothing about what the fiche contains or how missing records behave.

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 sentence with the resource front-loaded and the identifier alternatives attached directly to the key parameter. The telegraphic 'langue : fr, en, …' tail is efficient rather than padded.

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?

No output schema exists, so the description would ideally sketch the shape of a 'fiche complète' (which fields come back). It covers inputs adequately for a two-parameter read tool but leaves the return content entirely unspecified.

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 the parameter burden and it largely does: it clarifies that 'identifiant' accepts either an 'id' field or a SIRET, and it enumerates the accepted 'langue' values (fr, en, es, de, it, zh) that the schema does not encode as an enum. It stops short of explaining whether language affects only the output text.

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 (retrieve) and resource ('fiche complète d'un établissement') with the two supported lookup keys. It implicitly contrasts with the sibling search tool 'rechercher_imprimeurs' by emphasizing that this is a full record fetched by identifier, though no sibling is named explicitly.

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

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

The phrasing 'par son identifiant ou son SIRET' implies the caller already holds a key, which differentiates it from a search flow, but it never states when to prefer 'rechercher_imprimeurs' to obtain that key first, nor any failure case for an unknown identifier.

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 burden is not on the description. The description adds genuine context those annotations cannot convey: accepted input formats for the arrondissement and the set of supported output languages. It does not mention result ordering or what happens with an out-of-range value.

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 dense sentence that leads with the resource and scope, then appends the parameter formats with zero filler. Nothing is repeated from the title or schema and every clause carries information.

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

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

For a two-parameter, read-only, closed-world listing tool with no output schema, the description covers both inputs adequately and lets annotations handle the safety profile. It stops short of stating return contents or ordering, which is a minor gap given the simplicity.

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 0%, so the description must carry the parameters, and it does: it specifies the arrondissement range (1 to 20) plus the alternate accepted forms '11e' and '75011', and enumerates the valid 'langue' values (fr, en, es, de, it, zh) that the schema leaves unconstrained. This is exactly the compensation the schema lacks.

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 ('Tous les imprimeurs') scoped to a Paris arrondissement, which is much clearer than the name alone. It does not, however, contrast itself with the sibling 'rechercher_imprimeurs', so an agent must infer that this is the narrow geographic listing versus a broader search.

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

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

Usage is only implied: an agent can infer this is the tool for enumerating printers in one arrondissement. There is no explicit when-to-use statement, no exclusion, and no mention of the sibling alternative 'rechercher_imprimeurs' or 'fiche_imprimeur' for follow-up detail.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds that each entry carries an establishment count, which is useful return-shape context, but says nothing about ordering, pagination, or completeness of the reference list.

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, front-loaded with the resource and payload, with the language note appended. Nothing is wasted, though the language clause reads as a tacked-on fragment rather than integrated guidance.

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

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

For a simple read-only listing tool with one optional parameter and no output schema, the description covers what is listed and what each item contains. Only minor gaps remain (ordering, whether the list is exhaustive).

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 0% and the single 'langue' parameter has no enum in the schema, so the description's enumeration of accepted values (fr, en, es, de, it, zh) genuinely compensates for the gap. It does not state the effect of the language choice on returned labels, but the value set is the critical missing piece and it is supplied.

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 the resource (techniques et services référencés) and the payload (nombre d'établissements pour chacun), which is specific enough to separate it from the printer-oriented siblings. It lacks an explicit verb, but the name 'lister' plus the content description makes the operation unambiguous.

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

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

There is no statement of when to call this tool versus alternatives such as rechercher_imprimeurs or trouver_imprimeur_capable, and no prerequisites or exclusions are given. The agent must infer usage 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.

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 genuinely new behavioral context: the PDF checker runs in the browser and no file is ever sent to the server, which matters for an agent handling client files.

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 what is listed and followed by the checker link and privacy note. Slightly dense with parenthetical examples, but every clause carries information.

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

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

With no output schema, the description does the work of indicating the return shape: a list of checkpoints plus a link to the browser-based verifier. Combined with annotations, an agent has enough to call it correctly; only the 'produit' value domain remains unclear.

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

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

There is a single required parameter, 'produit', with 0% schema description coverage, and the description only echoes it as 'pour un produit donné'. It adds no information about accepted values, format, or whether product names must match another tool's vocabulary, so it does not 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 resource (checkpoints to verify in a print file) and scopes it to a given product, listing concrete examples (fond perdu, résolution, couleurs, polices). This is clearly distinct from the sibling tools, which deal with finding printers, techniques, and quotes.

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 the moment of use explicitly: 'avant de le confier à un imprimeur'. That gives a clear context, but it never names an alternative tool or a when-not-to-use condition, so it stops short of full routing 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 readOnlyHint=true, openWorldHint=false, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond that: nothing is sent or stored, and the person transmits the request themselves. This clarifies the tool's side-effect-free nature in a way annotations alone do not.

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 action and followed by the critical no-send/no-store assurance. Every sentence earns its place with no repetition or 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 only annotations carrying safety metadata, the description still covers what the tool produces (a specification and contact details), what it does not do (send or store), and where identifiers come from. The main missing piece is explicit usage guidance, but otherwise an agent has enough to call 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%, so the description carries the burden. It lists six of the seven parameters by name (produit, quantité, format, papier, finition, délai) and explains that identifiants are printer identifiers obtained from other tools. It still does not specify optionality or formats, but it compensates well for the schema's lack of descriptions.

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

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

The description states a specific verb and resource: drafting a quote-request specification and providing public contact details of selected printers. It enumerates the specification fields (produit, quantité, format, papier, finition, délai) and clarifies that identifiers come from other tools, making it easy to distinguish from siblings like rechercher_imprimeurs or fiche_imprimeur.

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

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

Usage is implied: gather identifiers from other tools and then prepare a quote request. However, the description never explicitly says when to use this tool versus alternatives, nor does it name any sibling or state exclusions. A user must infer the workflow.

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 description does not need to restate the safety profile. It instead adds genuinely new behavioral detail: the 50-result hard cap and the caveat that the boolean filters only keep establishments that actually confirmed the attribute, plus that langue changes returned labels and links. Return shape and pagination beyond the cap remain unstated.

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?

Purpose is front-loaded in one line, then parameters are presented as a compact key-to-meaning list with no filler. Every line adds information an agent could not get from the schema.

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 seven-parameter, zero-coverage search tool it is nearly complete: all filters, their formats and their limits are covered. The main omission is what a result entry looks like and whether to page beyond the 50-item cap, which matters with no output schema present.

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 and does so for all seven parameters: it enumerates the accepted technique values, gives arrondissement formats ("1 à 20, '11e', 75011"), names the fields mot_cle searches, defines both booleans as confirmed-only filters, caps limite at 50, and lists the six langue codes. This is a full compensation for the empty 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 opening line gives a specific verb and resource ("Recherche des imprimeurs parisiens") with an implicit geographic scope. It never distinguishes itself from near-siblings such as trouver_imprimeur_capable or lister_techniques, so an agent must guess which search entry point 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?

The description explains how to fill each filter but never says when this tool is the right choice versus the six siblings, nor what happens with no filters at all. Nothing signals when to stop browsing with this and switch to fiche_imprimeur or preparer_demande_devis.

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/closed-world, so the safety profile is covered. Beyond that, the description adds genuinely useful behavior: result ordering (distance if a location is given, otherwise alphabetical), what each result contains (reason for inclusion, nearest transport station, link to the record), and the hard cap of 50 on 'limite'. It stops short of saying what happens when nothing matches or how results are paginated.

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 and front-loaded: capability and scope come first, then ordering, then result contents, then the limit. No filler sentences, though the parenthetical product examples and the trailing 'limite' note are slightly compressed into one block.

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 an eight-parameter, filter-only read tool with no output schema, the description covers capability, location modes, ordering, result shape and the result-count cap — enough for an agent to call it correctly without further inspection. Only 'langue' and 'ouvert_samedi' remain unexplained, a minor gap against what is otherwise a self-sufficient definition.

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% and the schema exposes only bare titles, so the description carries the burden — and it does: it explains 'produit' (with examples), 'technique', the latitude/longitude pair, 'arrondissement', and the 50 maximum for 'limite'. Two of the eight parameters, 'langue' and 'ouvert_samedi', get no mention and their intent must be inferred from the French titles.

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 ('Imprimeurs parisiens capables de réaliser un produit ou une technique') plus the geographic scope (latitude/longitude or arrondissement), with concrete product examples. It does not, however, differentiate itself from the sibling 'rechercher_imprimeurs', which an agent could plausibly confuse with this tool.

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

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

Usage is implied by the parameter enumeration (give a product or technique, optionally a location or arrondissement) and the ordering rule tells the agent what output to expect. There is no explicit 'use this when…' statement, no prerequisites, and no routing to alternatives such as 'rechercher_imprimeurs', 'lister_techniques' or 'fiche_imprimeur'.

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