Search Qomvia Market shops and buy on the merchant's checkout; score any site's agent readiness.
Scored across 10 tools
Tools split cleanly into two domains: checkout session lifecycle (create, get, complete, cancel) and offer management (get, extend, search), plus a distinct readiness cluster (score, scan, rubric). Within each domain every tool targets a unique action with no overlapping purpose, and descriptions explicitly distinguish cached vs fresh readiness reads.
All 10 tools follow a strict snake_case verb_noun pattern: cancel_checkout_session, complete_checkout, create_checkout_session, extend_offer, get_ai_readiness_score, get_checkout_session, get_offer, list_readiness_checks, scan_website, search_products. No deviations or mixed conventions.
10 tools is well within the ideal 3-15 range and each tool maps to a distinct operation in either the agentic checkout flow or the AI-readiness scan flow. No tool feels redundant or filler.
Core lifecycle coverage is solid: search_products surfaces offers, create/get/complete/cancel cover the checkout session, and get/extend cover offers, while the readiness cluster covers score, checks, and fresh scanning. Minor gaps remain (e.g., no list_checkout_sessions or update_session_quantity), but agents can work around them.
Cancel an open checkout session and release the offer.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | Checkout session id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses a side effect ('release the offer') beyond the tool name, but says nothing about idempotency, error behavior when the session is already closed, or permission requirements for a mutation.
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 naming the action and its consequence, with zero filler or restatement of the title.
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 one-parameter mutation with no annotations and no output schema, the description covers the action and its main effect, but omits failure/idempotency context an agent would want before invoking a cancel operation.
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% with a single required sessionId, so the schema already documents the parameter. The description adds no format, source, or lookup guidance beyond what the schema provides, making the baseline 3 appropriate.
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 (cancel) and resource (checkout session), plus the secondary effect of releasing the offer. It is clearly distinguishable from siblings like complete_checkout and create_checkout_session by the action itself, though it never names an alternative to contrast against.
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 qualifier 'open' implies the session must still be open to be cancelled, giving an implicit precondition, but there is no explicit when-to-use/when-not-to-use guidance or reference to sibling alternatives such as complete_checkout.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Complete a checkout session and receive the merchant-hosted payment URL. The buyer pays the merchant there; Qomvia never takes payment for the goods.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | Checkout session id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, and it does disclose the key mechanism: the buyer pays on the merchant-hosted page and Qomvia never handles payment for goods. However it is silent on whether completing a session is idempotent, whether the session becomes unusable afterward, and what errors occur for expired/invalid sessions.
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 its result, with the payment-liability clarification following immediately. No filler or repetition of the tool name.
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 single-parameter tool with no output schema, the description usefully explains what the caller receives (a payment URL) and where payment occurs. It is slightly thin on post-completion session state and failure modes, but otherwise adequate.
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?
Only one parameter exists and schema coverage is 100%, so the schema already documents sessionId fully. The description adds no format, sourcing, or lifecycle detail about the session id, making this a baseline 3.
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+resource ('Complete a checkout session') and names the concrete outcome ('receive the merchant-hosted payment URL'), which cleanly distinguishes it from create_checkout_session, cancel_checkout_session, and get_checkout_session 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?
Usage is implied by the state-transition verb - an agent infers this is called after a session exists - but there is no explicit when/when-not guidance, no mention of required session state, and no routing advice relative to get_checkout_session or cancel_checkout_session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a checkout session on an offer: freezes the agent price, quantity and shipping. Qomvia never takes the payment; complete_checkout returns the merchant's payment URL.
| Name | Required | Description | Default |
|---|---|---|---|
| qty | No | Quantity (default 1) | |
| buyer | No | Buyer JSON: {email, name?, phone?} | |
| shipTo | No | Ship-to JSON: {name, line1, line2?, zip, city, state?, country, company?, phone?} | |
| offerId | Yes | Offer id from search_products |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does meaningful work: it discloses the key side-effect (freezing price, quantity and shipping) and explicitly clarifies a non-behavior ('Qomvia never takes the payment'). It omits auth requirements, whether the frozen values expire, and what the session object contains, which are gaps for a state-creating 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?
Two tight clauses, front-loaded with the action and its effect, then the crucial non-payment caveat and the next step. No filler sentences.
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 tool with no output schema, the description covers the workflow and the safety-relevant caveat that payment happens elsewhere, which is the most important thing an agent needs. It could still mention what the session returns (e.g., a session id for use with complete_checkout) and any expiry, but the essentials are 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 100%, so all four parameters are already documented in the schema, making 3 the baseline. The description's mention of price/quantity/shipping loosely maps to qty and shipTo but adds no format or constraint detail 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 and resource ('Open a checkout session on an offer') and names the exact scope of what it freezes (agent price, quantity, shipping). It also positions itself in the workflow relative to complete_checkout, so an agent can distinguish it from get_checkout_session and cancel_checkout_session without opening a 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?
The description implies the workflow ordering by noting that 'complete_checkout returns the merchant's payment URL', which tells the agent this tool is the precondition step and that payment is a separate call. It stops short of explicitly stating prerequisites or when not to use it, but the routing context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extend an offer's validity once by its TTL. A second extension is refused.
| Name | Required | Description | Default |
|---|---|---|---|
| offerId | Yes | Offer id to extend |
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 usefully discloses the once-only extension rule and the TTL-based mechanism, which is real behavioral value. It does not disclose permissions, whether an expired offer can be extended, or what happens on refusal beyond the bare statement.
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 core action first and the key limitation second. Every word earns its place; nothing is padded or repeated from the name.
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 single-parameter, no-output-schema mutation, the description covers what it does and its main constraint. It is only slightly thin on preconditions and the outcome of a refused extension, which an agent might want to know before calling.
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 a single parameter at 100% schema description coverage, the schema already defines offerId as the offer to extend. The description adds no format, source, or lookup detail beyond that, so the baseline of 3 applies.
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 (extend) and resource (an offer's validity) with the mechanism (its TTL), so the action is unambiguous. It does not explicitly differentiate from siblings like get_offer or cancel_checkout_session, but they are unrelated operations, so confusion risk is low.
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 implies the usage context (extending an offer's validity) and reveals a hard constraint that affects when it can be called (only once). However, it never names alternatives or states the precondition under which extension applies, e.g. whether the offer must still be active.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the published AI-readiness score for a website: core score out of 100 (same checks for every site), grade, per-dimension breakdown, separate add-on scores (e.g. e-commerce) and the status of every measured check. Reads the cached public scan; use scan_website to force a fresh measurement.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain or URL, e.g. example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose the key trait that this is a read of a cached public scan rather than a live measurement, plus the fact that core checks are identical for every site. It omits what happens when no cached scan exists (error vs empty) and any auth/rate-limit notes, so it is strong but not complete.
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 dense sentences with zero filler; the return contents come first and the routing hint is front-loaded at the end where it is most actionable.
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 rightly enumerates the returned fields, and it covers the cached-vs-fresh tradeoff. The only real gap is the unstated behavior when a site has never been scanned.
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% for the single domain parameter, so the schema already carries the semantics. The description adds nothing about accepted domain formats or normalization, making this the baseline 3.
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 ('Return the published AI-readiness score for a website') and enumerates the payload (core score out of 100, grade, per-dimension breakdown, add-on scores, check statuses). This clearly distinguishes it from sibling scan_website and list_readiness_checks.
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 the context ('Reads the cached public scan') and names the alternative with its selecting condition ('use scan_website to force a fresh measurement'). The agent knows exactly when to pick this tool over the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a checkout session's status, amounts and expiry.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | Checkout session id |
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 conveys read-only semantics and hints at the returned fields (status, amounts, expiry), but says nothing about permissions, error behavior for unknown/expired session ids, or idempotency. A 3 reflects adequate but thin disclosure for a parameterless read.
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?
One front-loaded sentence with zero filler; the verb and resource lead and the returned fields follow immediately.
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 single-parameter read tool with a fully documented schema, this is nearly complete. The mention of returned fields (status, amounts, expiry) partly compensates for the absent output schema, though the description could note failure modes.
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% for the single sessionId parameter, so the schema already defines it. The description adds no format or sourcing detail beyond what the schema provides, making the baseline 3 appropriate.
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 (read) and resource (checkout session) plus what is retrieved (status, amounts, expiry). This clearly distinguishes it from sibling writes like cancel_checkout_session and create_checkout_session, though it doesn't name a sibling 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?
There is no explicit when-to-use guidance or named alternative. The agent must infer that this is the lookup-by-id complement to create/cancel, with no stated prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-read an offer by id: merchant, product, agent price, shipping, landed price, terms and expiry.
| Name | Required | Description | Default |
|---|---|---|---|
| offerId | Yes | Offer id from search_products |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Re-read' implies a non-mutating fetch and it discloses the returned fields including 'expiry', hinting that offers can lapse, but it says nothing about behavior for expired/missing offers, auth requirements, or rate limits.
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 with the verb and lookup key first, followed by the field list. Every clause earns its place with no 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?
There is no output schema, so the description usefully enumerates the return fields (merchant, product, agent price, shipping, landed price, terms, expiry). For a simple one-param read tool this is nearly complete; only edge-case behavior for expired or missing offers is absent.
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 schema already documents the single offerId parameter including its origin ('from search_products'). The description's 'by id' adds no meaning beyond that, so the baseline 3 is appropriate.
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+resource ('Re-read an offer by id') and enumerates the returned fields, so an agent knows this is an id-based retrieval of an existing offer rather than a search or mutation. It does not explicitly name a sibling, so it falls short of a 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 word 'Re-read' implies fetching an offer previously surfaced (the id origin lives in the schema, 'Offer id from search_products'), which hints at usage. However there is no explicit when-to-use/when-not guidance or mention of alternatives like search_products or extend_offer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the rubric: every pack (core, e-commerce), its dimensions and the individual checks with why each one matters and how to fix it.
| Name | Required | Description | Default |
|---|---|---|---|
| pack | No | Optional pack id: core or ecommerce |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose the payload shape (packs, dimensions, checks, why-it-matters, how-to-fix), which is real value, and "List" implies a read-only, side-effect-free operation. However, it says nothing about pagination, ordering, or permissions, leaving gaps on a tool with zero annotation coverage.
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 that leads with the verb and enumerates the return contents compactly. No filler or redundant clauses; the only shortfall is the trailing list getting slightly dense.
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 no annotations, the description adequately covers what the caller receives (dimensions, checks, rationale, remediation) and how the optional pack filter narrows it. Missing only edge details like scope of the unfiltered list and result ordering.
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% with a single optional "pack" param already documented as "core or ecommerce." The description restates those values ("core, e-commerce") and implies that omitting the filter surfaces every pack, adding only marginal semantics beyond the schema. Baseline 3 applies when the schema does the documenting.
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?
Specific verb ("List") plus a concrete resource (the rubric of packs, dimensions, and checks), and it even previews what each check includes (rationale and fix). An agent can tell it returns reference/rubric content rather than a score. It never names or distinguishes itself from the obviously related sibling get_ai_readiness_score, so it stops short of a 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 sentence describes what is returned but gives no when-to-use signal, no exclusions, and no pointer to the alternative. For a rubric-listing tool sitting next to get_ai_readiness_score, the agent gets no guidance on choosing between reading the rubric and requesting a score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Measure a website's AI-readiness now and return the score. Read-only HTTP requests only; a domain can be scanned once per hour and results become part of the public index.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain or URL to measure |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It usefully discloses that only read-only HTTP requests are made, that there is a per-domain rate limit of once per hour, and that scan results are added to a public index. It does not mention authentication needs or error behavior, but for a simple read-only scan this is solid transparency.
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?
The description is two compact sentences with no waste. It front-loads the core action and result, then follows with operational constraints, making it easy for an agent to parse quickly.
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 low-complexity tool with one parameter, no output schema, and no annotations, the description covers the essential behavior: what it does, its read-only nature, rate limits, and the public-index side effect. It could add a bit more on expected latency or failure modes, but nothing critical is missing 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?
The schema already documents the single 'domain' parameter at 100% coverage with the description 'Domain or URL to measure'. The tool description adds no additional meaning about the parameter format, accepted values, or handling of different input types, so the baseline of 3 applies.
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 gives a specific verb ('Measure') and resource ('a website's AI-readiness') and states the immediate outcome ('return the score'). It is clear, but it does not name or distinguish itself from the sibling tool get_ai_readiness_score, leaving some ambiguity about when a scan is needed versus when a stored score can be retrieved.
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 'now' and the rate-limit constraint ('once per hour') imply a fresh scan context, which gives some usage guidance. However, the description never explicitly states when to use this tool versus alternatives like get_ai_readiness_score or list_readiness_checks, so the guidance remains inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search every shop listed on Qomvia Market in one call and get signed, time-limited offers. Prices are the merchant's own prices with an agent discount applied; the buyer always pays the merchant on the returned payment URL, never Qomvia.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free-text product search, e.g. 'bike helmet' | |
| qty | No | Quantity (default 1) | |
| sku | No | Exact SKU match | |
| gtin | No | Exact GTIN/EAN match, wins over q | |
| brand | No | Brand filter | |
| limit | No | Max offers (default 10, max 25) | |
| shipTo | Yes | ISO-2 country the goods ship to, e.g. CH | |
| category | No | Category filter | |
| currency | No | ISO-4217 currency for a converted price hint | |
| maxPriceCents | No | Upper price bound in minor units |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers unusual and important behavior: offers are signed and time-limited, prices are merchant prices with an agent discount, and payment goes directly to the merchant via the returned payment URL, never to Qomvia. It omits rate limits, auth requirements, and result pagination behavior, so it is not exhaustive.
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, zero filler. The core action and scope are front-loaded, and the second sentence carries non-obvious payment-model context rather than repeating 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 10-parameter read tool with full schema coverage and no output schema, the description covers the essentials: what is searched, what comes back, and the payment model. It does not describe the offer object's fields or the default limit, but the schema covers defaults and the payment-URL detail anchors the return value.
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 every one of the 10 parameters is already documented in the schema (including defaults, max, and precedence like gtin winning over q). The description adds no parameter-level detail, so the baseline 3 applies.
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 (search), resource (every shop on Qomvia Market), and scope (one call returning signed, time-limited offers). This clearly separates it from retrieval siblings like get_offer and from checkout siblings, so an agent knows this is the discovery entry point.
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 — you call it to find products across shops — but there is no explicit when-to-use/when-not-to-use guidance or reference to alternatives such as get_offer for a known offer ID. The buyer-payment sentence clarifies context but not tool selection.
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.
cancel_checkout_sessioncomplete_checkoutcreate_checkout_sessionextend_offerget_ai_readiness_scoreget_checkout_sessionget_offerlist_readiness_checksscan_websitesearch_productsIs a website ready for AI shopping agents? Readiness score (0-100) + agent shopping simulation.
Agentic commerce gateway: discovery, search, checkout across Shopify/Woo/Odoo/PrestaShop.
Shop connected e-commerce stores: search, compare, cart, and checkout with buyer approval.
Shopify product discovery and x402-paid offer verification for AI agents.
Add one secure layer between your agents and this server.
