Skip to main content
Glama

verifier_devis

Compare le prix d'un devis fournisseur au prix reconstruit depuis le plan, poste par poste, et liste les questions à poser. 1 unité.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
devisYes
matiereYesEx. aluminium, acier, inox, fonte, pa6
plan_idYesIdentifiant rendu par POST /plans
quantiteYes
ajustementsNoParamètres du modèle (voir ajustements_possibles dans la réponse)
epaisseur_mmNoPour la tôle si le plan ne la porte pas
nb_campagnesNo
lot_de_fabricationNoNombre de pièces par lot, ou « commande_entiere »

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.1/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters2/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources