RFQdecoder

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

With no annotations, the description carries the full burden, but it does disclose meaningful behavior: the credit cost (free vs 1 unit) tied to each mode, which is not present in the schema. It does not explain error handling, what happens if both or neither parameter is supplied, or the shape of the returned rate.

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

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

A single well-formed sentence that front-loads the compute path and its free cost before the database alternative. Every clause carries information; no waste.

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

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

With no annotations, no output schema, and a nested object parameter, the description covers the two input modes and their cost but omits return value shape and behavior when parameters are combined or omitted. Adequate for a simple two-mode calculation tool, but with clear gaps.

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 baseline is 3, but the description adds genuine semantic value: it clarifies that 'poste' and 'machine' are alternative (mutually exclusive) input paths via 'ou', which the schema does not state since both are optional. This resolves real ambiguity about how the two parameters relate.

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 verb (calcule/lit) and resource (taux horaire d'une machine) and distinguishes two distinct modes of operation: computing from user-supplied values or reading from the database. It is clear without opening the schema, though it does not reference or differentiate from the sibling tools.

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 two operating paths are stated with their cost implications (gratuit vs 1 unité), effectively telling the agent which mode to choose and why. It gives clear context but stops short of explicit when-not-to-use guidance or naming sibling 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?

With no annotations, the description carries the full burden, and it does disclose output shape (unit price, per-line assumptions, explicit exclusions) plus a quantity basis ('1 unité'). It omits operational traits that matter for this API family, notably credit consumption (cf. recharger_credits, consulter_usage) and what happens if required plan inputs are missing.

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

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

A single front-loaded sentence beginning with the verb, with no filler; each clause (unit price, line items with assumptions, exclusions) carries information. It is dense but not 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?

There is no output schema, and the description compensates well by describing the returned breakdown. But for a cost-generating tool with a nested 'ajustements' object that self-references ('voir ajustements_possibles dans la réponse'), the absence of any credit/cost or failure-mode context leaves gaps.

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 71%, so the schema already documents most parameters (matiere, plan_id, epaisseur_mm, lot_de_fabrication). The description only touches matière and plan_id indirectly and adds '1 unité', which arguably relates to quantite but is not clearly tied to a parameter name, so it adds little beyond the schema.

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

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

States a specific verb (chiffre/cost) and resource (pièce usinée) and even enumerates the output breakdown (prix unitaire, lignes matière/opérations/frais/marge). It does not explicitly contrast itself with siblings like verifier_devis or comparer_quantites, so it stops short of 5.

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

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

The phrase 'depuis un plan déposé' implies the prerequisite that a plan must first exist (cf. deposer_plan), which is a usable usage cue. However, there is no explicit when-to-use/when-not and no routing to alternatives such as verifier_devis, leaving selection largely 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?

No annotations are provided, so the description carries the full burden. It discloses the 2–8 quantity range and '1 unité par quantité', but says nothing about whether the run consumes credits (relevant given the recharger_credits/consulter_usage siblings), how many pricing computations occur, or whether results are cached/reversible.

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 quantity range and the '1 unité par quantité' constraint lead. Minor overlap between 'plusieurs quantités (2 à 8)' and the trailing constraint, and no signal about what the tool returns.

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 8 parameters, a nested ajustements object, no output schema and no annotations, the description is too thin: it never explains the comparison output, the role of ajustements (only a cross-reference to the response payload), or any cost side-effect of running multiple quotes.

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%, which is moderately high, so the baseline is around 3. The phrase '1 unité par quantité' usefully clarifies the semantics of the quantites array, but the nested ajustements object and lot_de_fabrication are left to the schema alone.

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 ('Chiffre') and resource ('la même pièce'), plus the bounded scope (quantités 2 à 8) and the goal (voir l'effet de la quantité sur le prix). It implicitly contrasts with the single-piece sibling chiffrer_piece via 'la même pièce pour plusieurs quantités', but never names that alternative explicitly.

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

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

Usage is implied: use when you need to see how price varies with order quantity. There is no explicit when-not, no prerequisite, and no reference to chiffrer_piece or verifier_devis as alternatives, so the routing burden stays on the agent.

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?

With no annotations, the description carries the full burden of behavioral disclosure. 'Crédits restants … de la clé' implies a key-scoped, non-mutating read, but it never states that it is read-only, whether the call itself consumes credits, or any rate limits — meaningful gaps for a zero-annotation tool.

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

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

A single tight noun phrase with zero filler, front-loaded on the most useful information (credits, quotas, recent calls). It is a verbless fragment, which costs it the top mark but keeps it highly scannable.

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

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

For a simple, parameterless read tool with no annotations and no output schema, the description adequately enumerates the returned data. However it omits the auth/key context (who is 'la clé') and any hint of when the agent should check usage, leaving the definition 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?

The tool takes no parameters, so the baseline is 4. The description correctly adds no parameter guidance, as there is nothing to parameterize; the key scope is implied rather than configurable.

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 — the API key's remaining credits, quotas and recent calls — so an agent knows exactly what it returns. It lacks an explicit verb (e.g. 'retrieve/check') and never mentions the sibling recharger_credits, which is the natural counterpart, 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 statement of when to call this versus alternatives. The obvious pairing with recharger_credits (check balance before topping up) is never made explicit, and no prerequisites or exclusions are given.

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

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

With no annotations present, the description carries the full burden. It does disclose genuinely useful traits beyond the schema: the operation is free ('Gratuit') and the file is transmitted as base64. However it omits size limits, error/failure behavior, and any permission or quota constraints.

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 the core purpose front-loaded; no filler or redundancy. Every clause carries information (formats, return value, cost, transport).

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 usefully explains the returned plan_id and how to use it downstream, plus accepted formats and cost. It could be fuller on upload limits and failure modes, but it is adequate for a two-parameter upload 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 description coverage is 100%, so both parameters (nom_fichier, contenu_base64) are already documented. The description's 'Le fichier est envoyé en base64' only restates the encoding already captured by the parameter schema, adding no new syntax or constraint.

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 (dépose/upload), the resource (plan), the accepted formats (PDF, DXF, STEP), and the return value (plan_id). It is clearly distinguishable from the calculation, comparison, and billing 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?

'rend un plan_id à utiliser dans les autres outils' positions this as the prerequisite step that feeds downstream tools, which is real workflow guidance. It stops short of explicit when-not-use conditions or naming a specific alternative.

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

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

With no annotations, the description carries the full burden and does a good job: it discloses that the tool returns a url_paiement to hand to a human rather than granting credits directly, that credits land only on confirmed payment (asynchronous), and that the call is free. It omits auth/permission requirements and failure behavior, 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 compact clauses, front-loaded with the core action, followed by the return/timing and cost. Every sentence carries distinct, non-redundant 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 one-parameter tool with no output schema, the description supplies the key missing context: the returned url_paiement, the human hand-off, and the deferred credit timing. Only minor gaps remain (permissions, error/edge behavior), so it is nearly 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 100% and the single param is fully enumerated, so the baseline is 3. The description merely repeats the tier/quantity mapping already present in the schema ('essentiel 100, pro 500 ou volume 2 000 chiffrages'), adding no new parameter meaning.

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: 'Crée une page de paiement par carte pour recharger la clé' — creates a card payment page to top up the key. This is unmistakably distinct from the calculation/quote siblings, and it even names the tiers. An agent can identify what it does 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?

Usage is implied rather than stated: the agent can infer it should call this when the key needs recharging, and the description explains the downstream flow (give url_paiement to the human). But there is no explicit when-to-use, when-not, or named alternative among the siblings.

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

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

With no annotations, the description carries the full burden. It usefully discloses the credit cost ('1 unité') and that the output is a line-by-line comparison plus a list of questions, which goes beyond the schema. However, it says nothing about permissions, whether anything is mutated, or how it behaves when the plan and quote diverge.

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 sentences, front-loaded with the core action, plus a terse cost note. Nothing is wasted, though '1 unité.' is elliptical enough to read as an afterthought rather than structured metadata.

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 complex tool with 8 parameters, a nested object, and no output schema, the description is thin. It gives a one-line notion of the output but never explains the parameters, the 'ajustements' model, or the batch-related fields, leaving substantial gaps for correct invocation.

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 63%, and the description adds zero parameter meaning. Several parameters lack schema descriptions (quantite, devis, nb_campagnes, lot_de_fabrication) and the nested 'devis' object structure is never explained, so the description fails to 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?

States a specific verb (compare) and resource (supplier quote price vs price reconstructed from the plan), plus the granularity (poste par poste) and output (list of questions). This clearly separates it from chiffrer_piece, which appears to compute rather than verify a quote. It stops short of naming a sibling explicitly, so no full differentiation.

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

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

The comparison-versus-quote framing implies the use case (validating a supplier quote against an internally reconstructed price), and 'liste les questions à poser' hints at the follow-up purpose. But there is no explicit when-to-use, when-not-to-use, or reference to an alternative sibling such as chiffrer_piece.

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