Can an AI agent buy on this French store? 500 stores tested: score, guest checkout, UCP. Free.
Scored across 5 tools
Each tool targets a distinct retrieval mode: full sector ranking, filtered discovery, name/domain lookup, single-store detail, and multi-store comparison. The descriptions explicitly route the agent between them ("to find candidates first, use trouver_marchands", "for the details of one store, consulter_marchand"), leaving almost no room for misselection.
Four tools follow a clean French verb_noun pattern: comparer_, consulter_, rechercher_, trouver_ + marchand(s). The outlier is classement_secteur, a noun-based name, but it is still readable and clearly signals its distinct ranking purpose.
Five tools exactly match the five natural access paths (rank a sector, filter by facts, search by name, inspect one store, compare several). Nothing is redundant and nothing feels bolted on for a read-only store-testing directory.
Discovery, lookup, ranking, detail and comparison fully cover the read-only query lifecycle, with sensible error/empty-result behavior described. Minor gaps remain: no tool to enumerate the valid sectors or their metadata, and no surface for rate-limit or attribution info beyond passing mentions.
Ranking of ALL tested French online stores in one sector, best score first. Use it when the user wants the best stores of a sector as a whole (for example the best beauty stores for an AI agent). To filter by proven facts such as guest checkout, use trouver_marchands; for the details of one store, consulter_marchand. Returns: secteur and marchands, a list of every ranked store (30 to 70 per sector) with rang, ex_aequo (equal scores share a rank, then alphabetical order), domaine, nom, note out of 100, nombre_avis, dernier_test, test_ancien and page. Sectors: beaute, mode, maison, sport, epicerie, enfant, animalerie, bijoux, bricolage, high-tech. Unknown sector: error result listing the valid ones.
| Name | Required | Description | Default |
|---|---|---|---|
| langue | No | Language of the page links and, for consulter_marchand, of the summary sentence: fr (default) or en. Data fields are the same in both. | |
| secteur | Yes | Sector id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world, and the description still adds real behavior: result size (30-70 stores per sector), rank tie-breaking via ex_aequo then alphabetical, staleness flags (dernier_test, test_ancien), pagination via page, and the exact failure mode for an unknown sector. That is disclosure well 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?
Front-loaded with purpose and alternatives before the return-field dump; every sentence is functional. The long comma-separated field and sector lists are informative but dense, costing a little readability rather than adding 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 output schema, the description carries the return contract and does so fully: top-level keys (secteur, marchands), per-item fields, ordering, tie-breaking, and error behavior. Nothing an agent needs to call or interpret 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% and both params have enums with their own descriptions, so the baseline is 3. The description still adds value by enumerating the ten valid sectors inline and specifying the unknown-sector error, whereas the langue param is only handled by 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 and resource ('Ranking of ALL tested French online stores in one sector, best score first') and immediately contrasts with the sibling tools trouver_marchands and consulter_marchand by name. An agent can pick this over its four siblings 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 trigger ('when the user wants the best stores of a sector as a whole'), a concrete example, and two named alternatives with the condition that selects them (proven-fact filtering -> trouver_marchands, single-store detail -> consulter_marchand). Nothing left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Side-by-side test results for two to five French online stores you already know, in the order given. Use it when the user hesitates between specific stores. To find candidates first, use trouver_marchands or rechercher_marchand. Returns: marchands, one full result per store, identical to consulter_marchand (score out of 100, six steps acces to caisse, proven facts, machine readability, UCP checkout, summary and page). Each store counts as one request against the rate limit. Fewer than two or more than five domains: error result.
| Name | Required | Description | Default |
|---|---|---|---|
| langue | No | Language of the page links and, for consulter_marchand, of the summary sentence: fr (default) or en. Data fields are the same in both. | |
| domaines | Yes | Two to five store domains, for example ["respire.co", "typology.com"]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description goes beyond them with two operational facts an agent cannot infer: each store counts as one request against the rate limit, and fewer than two or more than five domains yields an error result. It also discloses the return shape per store.
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 purpose and usage before mechanics, with no filler sentences. The long parenthetical enumerating result fields is dense but substitutes for the absent output schema, so it earns its place, though it could be structured as a list.
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 covers return contents by reference to consulter_marchand, plus rate-limit cost and error conditions. For a 2-parameter read-only comparison tool, nothing an agent needs to invoke it 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 baseline would be 3, but the description adds meaning not in the schema: the result order follows the input order, and out-of-range counts produce an error rather than being silently trimmed. The langue parameter's effect is left to the schema, which fully documents it.
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 and resource ("side-by-side test results for two to five French online stores") and fixes the ordering semantics ("in the order given"), which no sibling provides. An agent can distinguish it from classement_secteur and consulter_marchand 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?
It states the selecting condition explicitly ("Use it when the user hesitates between specific stores") and routes candidate discovery to the alternatives by name: "To find candidates first, use trouver_marchands or rechercher_marchand." Both the when and the when-not are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full test result for ONE French online store, by domain: what an AI shopping agent managed to do there at the latest test. Use it before visiting, recommending or buying from a French store, or when the user asks if a store works with AI agents. To find stores you do not know yet, use trouver_marchands; to look up a store by name, rechercher_marchand; to put several side by side, comparer_marchands. Returns: note (score out of 100: journey 55, proven purchase facts 30, machine readability 15), etapes (six steps in order — acces, cookies, recherche, fiche, panier, caisse — each reussi, partiel, echec or non_atteint, with a motif when it failed), faits (oui, non or inconnu: checkout without an account, delivered price before sign-up, shipping costs, return policy, third-party seller), machine (product data, robots.txt, llms.txt, sitemap, UCP), ucp_commande (store declares UCP checkout), dernier_test (date), test_ancien (true if older than 90 days), resume (one-sentence summary to quote) and page (link to cite). Unknown or untracked domain: error result, nothing charged.
| Name | Required | Description | Default |
|---|---|---|---|
| langue | No | Language of the page links and, for consulter_marchand, of the summary sentence: fr (default) or en. Data fields are the same in both. | |
| domaine | Yes | Store domain, for example respire.co. A full URL or a www. prefix is accepted and normalised. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotent/non-destructive, so the safety profile is covered. The description adds real behavior beyond that: unknown or untracked domains return an error result and nothing is charged, plus a detailed account of the return payload. It doesn't mention rate limits or latency, keeping it from 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?
Purpose and usage routing are front-loaded in the first two sentences, and the long return-value enumeration is justified because no output schema exists. It is dense but earns most of its length; the payload list is slightly over-packed into one paragraph.
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 fully compensates by enumerating the return fields (note, etapes, faits, machine, ucp_commande, dernier_test, test_ancien, resume, page) including score breakdown and step names. Covers the error case as well, so an agent has everything needed to call and interpret it.
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 schema itself documents both domaine (format/normalisation) and langue (fr/en, effect on summary). The description only implicitly touches domaine ('by domain') and langue ('one-sentence summary to quote'), adding little beyond the schema. Baseline 3 applies when the schema carries the parameter detail.
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+resource+scope immediately: a full test result for ONE French online store, by domain, describing what an AI shopping agent could do there at the last test. It also explicitly names the sibling tools (trouver_marchands, rechercher_marchand, comparer_marchands) so an agent can distinguish it 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 explicit when-to-use cues ('before visiting, recommending or buying from a French store', 'when the user asks if a store works with AI agents') and routes to alternatives for other jobs ('to find stores you do not know yet', 'to look up a store by name', 'to put several side by side'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a tracked French store by part of its NAME or DOMAIN, across all sectors (case and accents ignored). Use it when the user names a store but you do not know its exact domain; then call consulter_marchand with the domain found. To discover stores by criteria rather than by name, use trouver_marchands. Returns: requete and marchands, every match (usually a few) with rang in its sector, ex_aequo, secteur, domaine, nom, note out of 100, nombre_avis, dernier_test, test_ancien and page. No match: an empty list, which means the store is not tracked yet.
| Name | Required | Description | Default |
|---|---|---|---|
| langue | No | Language of the page links and, for consulter_marchand, of the summary sentence: fr (default) or en. Data fields are the same in both. | |
| requete | Yes | At least two characters of the store name or domain, for example nocibe or sezane. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent and closed-world behavior, so the bar is lower; the description still adds real context: case/accent-insensitive matching, expected result volume ('usually a few'), and the meaning of an empty list ('store is not tracked yet'). It omits ranking order of multiple matches and any rate/limit notes, so it stops 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?
Front-loaded with purpose, then usage, then return shape, and every sentence carries information since there is no output schema. The return-field enumeration is long but justified; a slightly tighter grouping of the field list would earn a 5.
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 compensates by naming the returned fields (requete, marchands, rang, ex_aequo, secteur, domaine, nom, note, nombre_avis, dernier_test, test_ancien, page) and defining the empty-result case. That is everything an agent needs to call it and interpret the result.
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; the description adds matching semantics that the schema does not (partial match, case and accents ignored, 'nocibe'/'sezane'-style examples) and clarifies the scope of 'requete'. It says nothing extra about the 'langue' parameter beyond what the schema already explains.
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 ('find a tracked French store by part of its NAME or DOMAIN') with matching scope (case/accent insensitive, all sectors). It is clearly separable from the two siblings it names, trouver_marchands (criteria-based discovery) and consulter_marchand (domain lookup).
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 states when to use it ('user names a store but you do not know its exact domain'), what to do next ('then call consulter_marchand with the domain found'), and which sibling to use instead for criteria-based discovery. No inference left to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover French online stores where an AI agent can actually buy, filtered by PROVEN facts, in one sector or all of them. Use it when the user asks where to buy something online in France, which stores allow guest checkout, or which show the delivered price. To look up a store by name, use rechercher_marchand; for a whole sector ranking, classement_secteur. Every filter is optional; set a boolean to true to require that fact. Returns: secteur, criteres (filters applied), total (number of matching stores) and marchands, best score first, at most limite entries, each with rang, ex_aequo, secteur, domaine, nom, note out of 100, the five facts as booleans (sans_compte, prix_livre, frais_livraison, retours, ucp_commande), dernier_test and page. No match: total 0 and an empty list.
| Name | Required | Description | Default |
|---|---|---|---|
| ucp | No | Store publishes a UCP profile that declares checkout, so an agent can order through the protocol. | |
| langue | No | Language of the page links and, for consulter_marchand, of the summary sentence: fr (default) or en. Data fields are the same in both. | |
| limite | No | Maximum number of stores returned (default 20, at most 50); total still counts every match. | |
| retours | No | Return policy was found and quoted. | |
| secteur | No | Restrict to one sector; all sectors if omitted. | |
| note_min | No | Minimum score out of 100. | |
| prix_livre | No | Total price including delivery was shown before any sign-up. | |
| sans_compte | No | Agent reached checkout without creating an account (proven by a screenshot or quote). | |
| frais_livraison | No | Shipping costs were found. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so safety is cheap here; the description still adds real behavior: results sorted best-score-first, capped at limite, and the explicit no-match contract (total 0 plus empty list). It stops short of explaining how the score is computed or how freshness (dernier_test) affects ranking, which keeps it off 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?
Front-loaded with purpose, then routing alternatives, then the return contract; no wasted sentences. The return enumeration is dense but earns its place because there is no output schema, though it is long enough to slightly dilute the routing message.
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 carries the full return contract (secteur, criteres, total, marchands with rang/ex_aequo/note/five facts/page) and the empty-result case, which is exactly what an agent needs for 9 optional params. Minor gaps remain: it does not say how proven facts are missing vs false, nor whether the data is cached or how recent dernier_test must be.
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 the baseline is 3. The description does add one genuinely non-schema insight — that every filter is optional and a boolean true means 'require this proven fact' — but it otherwise restates the filter set rather than adding per-parameter meaning (e.g. how note_min interacts with unproven facts).
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 (discover/list) and resource (French online stores where an agent can buy), plus the filter-by-proven-facts scope. It explicitly names the siblings it is not (rechercher_marchand for name lookup, classement_secteur for a sector ranking), so an agent can route without opening other 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 concrete trigger scenarios ('where to buy something online in France', 'which stores allow guest checkout', 'which show the delivered price') and pairs each sibling name with the condition that selects it. It also states all filters are optional and that a boolean set to true is a requirement, which removes the main usage ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
classement_secteur2 fields changedInput schema / properties / langue / descriptionAdded value: +"Language of the page links and, for consulter_marchand, of the summary sentence: fr (default) or en. Data fields are the same in both."Input schema / properties / secteur / descriptionAdded value: +"Sector id."comparer_marchands2 fields changedInput schema / properties / domaines / descriptionPrevious value: -"Merchant domains, for example [\"a.fr\", \"b.fr\"]. / Domaines des marchands."New value: +"Two to five store domains, for example [\"respire.co\", \"typology.com\"]."Input schema / properties / langue / descriptionAdded value: +"Language of the page links and, for consulter_marchand, of the summary sentence: fr (default) or en. Data fields are the same in both."consulter_marchand2 fields changedInput schema / properties / domaine / descriptionPrevious value: -"Merchant domain, for example exemple-beaute.fr. A full URL is accepted. / Domaine du marchand, adresse complète acceptée."New value: +"Store domain, for example respire.co. A full URL or a www. prefix is accepted and normalised."Input schema / properties / langue / descriptionPrevious value: -"Language of the summary sentence and of the page link (default fr)."New value: +"Language of the page links and, for consulter_marchand, of the summary sentence: fr (default) or en. Data fields are the same in both."rechercher_marchand2 fields changedInput schema / properties / langue / descriptionAdded value: +"Language of the page links and, for consulter_marchand, of the summary sentence: fr (default) or en. Data fields are the same in both."Input schema / properties / requete / descriptionPrevious value: -"Part of the merchant name or domain, at least two characters."New value: +"At least two characters of the store name or domain, for example nocibe or sezane."trouver_marchands9 fields changedInput schema / properties / frais_livraison / descriptionPrevious value: -"Shipping costs found. / Frais de livraison trouvés."New value: +"Shipping costs were found."Input schema / properties / langue / descriptionAdded value: +"Language of the page links and, for consulter_marchand, of the summary sentence: fr (default) or en. Data fields are the same in both."Input schema / properties / limiteAdded value: +{
+ "description": "Maximum number of stores returned (default 20, at most 50); total still counts every match.",
+ "maximum": 50,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / note_min / descriptionPrevious value: -"Minimum score out of 100. / Note minimale sur 100."New value: +"Minimum score out of 100."Input schema / properties / prix_livre / descriptionPrevious value: -"Delivered price shown before any account. / Prix livré affiché avant tout compte."New value: +"Total price including delivery was shown before any sign-up."Input schema / properties / retours / descriptionPrevious value: -"Return policy found. / Politique de retour trouvée."New value: +"Return policy was found and quoted."Input schema / properties / sans_compte / descriptionPrevious value: -"Checkout without an account proven. / Commande sans compte prouvée."New value: +"Agent reached checkout without creating an account (proven by a screenshot or quote)."Input schema / properties / secteur / descriptionPrevious value: -"Sector; all sectors if omitted. / Secteur, tous si absent."New value: +"Restrict to one sector; all sectors if omitted."Input schema / properties / ucp / descriptionPrevious value: -"Publishes a UCP profile that declares checkout. / Profil UCP avec la commande."New value: +"Store publishes a UCP profile that declares checkout, so an agent can order through the protocol."comparer_marchandstrouver_marchandsclassement_secteurconsulter_marchandrechercher_marchandIs a website ready for AI shopping agents? Readiness score (0-100) + agent shopping simulation.
Free open check: can an AI agent reach checkout on this store? Advisory; ARC stops before payment.
AgentReady.market audit: can an AI shopping agent find, understand and BUY on this store? /100.
Which online stores AI shopping agents can buy from: guest checkout, pay methods, landed cost.
Add one secure layer between your agents and this server.
