Skip to main content
Glama
Sign In

kalicart-global

by io.github.giuseppesocci-bot
OverviewDiscussionsAdmin

Server Details

Federated commerce search across independent WooCommerce merchants. Keyless, read-only MCP server.

Ownership verified
Status
Healthy
Uptime
100.0% over 78 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
giuseppesocci-bot/kalicart-global
GitHub Stars
0
Server Listing
KaliCart Global
ChatGPT
–
Claude
–

TDQS

A4.3/5.0

Scored across 9 tools

Disambiguation4/5

Most tools have clearly distinct roles: search, category listing, merchant registry checks, attestation, product details, single-offer verification, basket verification, and cost estimation. The only meaningful overlap is between verify_offer, verify_basket, and estimate_delivered_cost around price/shipping checks, but their descriptions distinguish single-offer verification, multi-item basket checks, and deterministic estimation.

Naming Consistency4/5

Names are mostly consistent snake_case action_resource-style: list_categories, list_merchants, lookup_merchant, get_product, get_offer_attestation, verify_offer, verify_basket, estimate_delivered_cost. global_search is a minor deviation from the verb_noun pattern, but it remains readable and predictable.

Tool Count5/5

Nine tools is well scoped for a product discovery and merchant verification server. Each tool covers a distinct workflow stage, and there is no obvious bloat or missing utility that would justify a different count.

Completeness4/5

The surface covers discovery, categories, merchants, product details, attestation, single-offer checks, basket verification, and delivered-cost estimation. Checkout itself is intentionally left to the merchant handoff, so the main gap is the absence of a direct checkout/session operation, which is a reasonable design boundary rather than a severe incompleteness.

Available Tools

9 tools
estimate_delivered_costEstimate the delivered cost of one offer to a destinationA
Read-onlyIdempotent
Inspect

Deterministic estimate from the merchant's own data: item price x quantity plus the shipping options the store declares for the destination (flat rate = declared base rate; free shipping with its threshold, whether this quantity reaches it and how much is missing). Lists what is not included (shipping classes, cost formulas, duties, taxes on shipping). Pass variation_id for variable products. Valid within max_age_seconds of the last merchant confirmation; live=true reads the merchant now. The checkout is the only authority.

NameRequiredDescriptionDefault
liveNo
p2209_idYes
quantityNo
destinationYesISO 3166-1 country, optionally with region: "IT" or "IT:CB".
variation_idNo
max_age_secondsNo

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds real value beyond them: it is deterministic and derived from merchant-declared data, freshness is bounded by max_age_seconds, and it enumerates the exclusions (shipping classes, cost formulas, duties, taxes on shipping). It stops short of saying what happens when the confirmation is older than max_age_seconds (error vs. stale result), which is the one behavioral gap.

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?

Dense but front-loaded: the computation is defined first, then exclusions, then parameter guidance, then the authority caveat. Every sentence carries information, though the parenthetical free-shipping explanation is packed tightly enough to slow reading.

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

Completeness4/5

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

With six parameters, no output schema, and thin schema descriptions, the description carries most of the burden and does so well by describing both what the result includes and explicitly what it excludes. The missing piece is the return shape and default values, which the agent must infer.

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

Parameters3/5

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

Schema coverage is only 17% (only destination is documented), so the description must compensate, and it does explain variation_id, live, and the max_age_seconds window. However, p2209_id is never described, quantity is only implied via 'item price x quantity', and no defaults are given for quantity, live, or max_age_seconds.

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

Purpose5/5

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

States a specific verb and resource ('deterministic estimate ... item price x quantity plus the shipping options the store declares for the destination') and explains exactly what the computation covers. The closing line 'The checkout is the only authority' implicitly separates it from the verify_* siblings that do authoritative checks.

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

Usage Guidelines4/5

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

Gives concrete usage conditions: pass variation_id for variable products, use live=true to read the merchant now, and the result is only valid within max_age_seconds of the last confirmation. It does not explicitly say when to prefer verify_offer or verify_basket over this estimate, but the 'checkout is the only authority' caveat supplies that context.

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

get_offer_attestationPortable merchant attestation for one offerA
Read-onlyIdempotent
Inspect

Returns a cryptographic proof that this offer's product row is exactly the one the merchant signed in its catalog snapshot: the signed row, its bucket hashes, the Ed25519-signed manifest, the merchant public key and step-by-step verification. Trust is anchored on the merchant domain (key fingerprint published at key_anchor), not on KaliCart. It proves the row as signed at snapshot.generated_at, not the current price or stock: the checkout is authoritative. Independent verifier: https://global.kalicart.com/ucp/tools/verify-offer-attestation.js

NameRequiredDescriptionDefault
p2209_idYesOffer id from global_search (e.g. prod_duinshop-it_446678).

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: it discloses the trust anchor (merchant key fingerprint at key_anchor), the temporal scope of the proof (snapshot.generated_at, not current price/stock), the exact returned artifacts, and a pointer to an independent verifier. This is exactly the kind of caveat an agent needs to avoid misusing the result.

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?

Front-loaded with the core purpose, then the trust anchor and the snapshot-timestamp caveat, all in a compact block. Dense but every clause carries signal; only the enumerated payload list could be trimmed marginally.

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

Completeness5/5

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 must describe the return, and it does: signed row, bucket hashes, Ed25519-signed manifest, merchant public key, and step-by-step verification, plus an external verifier URL. Combined with the trust-model and timestamp caveats, 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.

Parameters3/5

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

With 1 parameter at 100% schema coverage, the schema already documents p2209_id including its source (global_search) and example. The description adds only that the id identifies 'this offer's product row' and does not extend the parameter meaning further, so baseline 3 applies.

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

Purpose5/5

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

States a specific verb and resource: 'Returns a cryptographic proof that this offer's product row is exactly the one the merchant signed in its catalog snapshot,' and enumerates the payload contents. This distinguishes it from siblings like verify_offer and get_product, which serve different verification/retrieval purposes.

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

Usage Guidelines4/5

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

Clarifies the trust model ('anchored on the merchant domain, not on KaliCart') and scopes the guarantee ('proves the row as signed at snapshot.generated_at, not the current price or stock: the checkout is authoritative'), which tells an agent when this proof is and isn't the right evidence. It does not explicitly name alternatives such as verify_offer for live data, 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.

get_productGet indexed product detailsA
Read-onlyIdempotent
Inspect

Use this after global_search when the selected candidate needs indexed details that are not already on its search card. The p2209_id must come from global_search. Variant options and colors are merchant-declared snapshot evidence matched by variation ID. This remains a snapshot, not live merchant verification; follow the returned handoff before confirming variant, price, or stock. Skip this call when the search card already answers the question.

NameRequiredDescriptionDefault
p2209_idYesKaliCart product ID (e.g. prod_duinshop-it_432395)

Output Schema

NameRequiredDescription
nameNo
errorNo
priceNo
scopeNo
handoffNo
categoryNo
p2209_idYes
variantsNo
attributesNo
provenanceNo
updated_atNo
merchant_idNo
product_urlNo
availabilityNo
storefront_urlNo

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them by disclosing that data is a merchant-declared snapshot rather than live verification, and that the returned handoff must be followed before confirming variant, price, or stock. That is meaningful behavioral context an agent could not infer from annotations.

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

Conciseness5/5

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

Front-loads the usage trigger, then layers the prerequisite, the evidence nature, and the exclusion in sequence. Every sentence carries distinct, actionable information with no filler.

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

Completeness5/5

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

An output schema exists so return values needn't be described, and the description covers the prerequisite, the snapshot caveat, and the follow-up handoff obligation. Nothing an agent needs to call this correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the p2209_id format is already documented; the description adds provenance semantics beyond the schema, stating the ID must come from global_search. It stops short of adding new syntax, but the provenance constraint is real added value.

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

Purpose5/5

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

States a specific verb (get) and resource (indexed product details), plus the exact scope ('indexed details that are not already on its search card'). It clearly distinguishes itself from global_search by framing this as the follow-up step that fetches detail beyond the search card.

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

Usage Guidelines5/5

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

Explicit when-to-use ('after global_search when the selected candidate needs indexed details') and when-not ('Skip this call when the search card already answers the question'), and it names the sibling global_search as the source of the required ID.

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

list_categoriesBrowse canonical product categoriesA
Read-onlyIdempotent
Inspect

Use this to discover the canonical category paths currently represented in KaliCart Global before calling global_search with leaf. An optional parent returns that node and its full subtree. This lists category vocabulary and counts; it does not return products.

NameRequiredDescriptionDefault
parentNoOptional canonical node to restrict results to that node and its subtree (for example apparel or home.bedroom)

Output Schema

NameRequiredDescription
totalYes
next_stepNo
truncatedYes
categoriesYes
filtered_byYes
complete_viaNo
returned_countYes

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds real behavioral context beyond them: it returns vocabulary and counts rather than products, and an optional parent expands results to that node plus its full subtree. It omits any pagination or result-size behavior, which keeps 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.

Conciseness5/5

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

Three tightly packed sentences that front-load the primary purpose, then the follow-up unblocking constraint, then the exclusion. No filler.

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

Completeness5/5

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

For a single-optional-parameter read tool with annotations and an output schema, the description covers purpose, sequencing with a sibling, and scope boundaries. 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.

Parameters3/5

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

Schema description coverage is 100% and the single parameter is fully documented there, so the baseline is 3. The description's note that 'parent' returns the node and its full subtree restates the schema's own explanation rather than adding new meaning.

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

Purpose5/5

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

States a specific verb and resource ('discover the canonical category paths') and explicitly scopes the result set to category vocabulary in KaliCart Global, which cleanly separates it from product-returning siblings like global_search and get_product.

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

Usage Guidelines5/5

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

Gives an explicit triggering condition ('before calling global_search with leaf') and an explicit exclusion ('it does not return products'), so the agent knows both when to call it and what it is not for.

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

list_merchantsList participating merchantsA
Read-onlyIdempotent
Inspect

Use this to inspect which WooCommerce merchants currently participate in the searchable KaliCart Global catalog and how much catalog coverage each contributes. It returns stable merchant identifiers, domains, storefront URLs, product counts, and sync time. Do not use it to find products; use global_search instead.

NameRequiredDescriptionDefault
limitNoMax merchants to return (default 20, max 50), ordered by product count descending. No pagination

Output Schema

NameRequiredDescription
totalYes
merchantsYes
truncatedYes
returned_countYes

TDQS

A4.5/5.0
Behavior4/5

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

The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context beyond the annotations: the returned data highlights 'stable merchant identifiers, domains, storefront URLs, product counts, and sync time,' and characterizes the data as 'currently participate' to indicate current-scope semantics.

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

Conciseness5/5

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

Three sentences with no filler; the main usage and scope are front-loaded, the return contents are listed compactly, and the redirect to global_search is placed at the end. Every sentence earns its place.

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

Completeness5/5

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

For a one-optional-parameter read-only list with a full output schema available, the description is complete: it states the collection being listed, the per-item information returned, and the alternative for product search. Nothing needed to call it correctly is missing.

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

Parameters3/5

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

The single parameter, limit, is fully described in the schema (default, max, ordering, no pagination), so schema coverage is 100%. The description does not add parameter-level detail, but it doesn't need to because the schema already carries that burden.

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

Purpose5/5

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

The description names a concrete action ('inspect'), a specific resource (participating WooCommerce merchants in the KaliCart Global catalog), and the key outcome (catalog coverage contributed). It also distinguishes itself from global_search by saying it should not be used to find products.

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

Usage Guidelines5/5

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

It opens with 'Use this to inspect...' and explicitly says 'Do not use it to find products; use global_search instead.' This gives an explicit when-to-use, when-not-to-use, and a named alternative, which is exactly the routing guidance an agent needs.

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

lookup_merchantCheck a merchant for KaliCart BridgeA
Read-onlyIdempotent
Inspect

Use this when the user already knows a merchant domain and needs to check whether it publishes a KaliCart Bridge catalog, its latest observed access state, or its federation consent. This tool only reads the Global registry and never probes or modifies the merchant. Do not use it to discover products; use global_search instead.

NameRequiredDescriptionDefault
domainYesMerchant domain, e.g. shop.example.com

Output Schema

NameRequiredDescription
probeNo
domainYes
consentNo
registeredYes
observed_atNo
bridge_accessNo
bridge_versionNo
bridge_detectedNo
federation_statusNo
merchant_discovery_urlNo

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered structurally. The description adds genuinely new behavioral context: it reads only the Global registry and never probes or modifies the merchant, which clarifies the surprising openWorldHint=true. It does not mention auth requirements or rate limits, 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.

Conciseness5/5

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

Three sentences, each doing distinct work: purpose and returned facets first, read-only scope second, exclusion third. Zero filler and the most decision-relevant information is front-loaded.

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

Completeness5/5

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

An output schema exists, so return formatting need not be explained, and annotations carry the safety profile. The description still names the three things the lookup answers, which is exactly the completeness an agent needs for a one-parameter read tool.

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

Parameters3/5

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

Schema description coverage is 100% and there is a single parameter, so the schema already documents the domain format and example. The description adds no format or validation detail beyond it, making the baseline 3 correct.

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

Purpose5/5

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

States a specific verb (check/lookup) and resource (merchant domain) plus the exact facets returned: Bridge catalog publication, latest observed access state, and federation consent. It also explicitly distinguishes itself from global_search, so an agent can route without opening either schema.

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

Usage Guidelines5/5

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

Gives a positive precondition ('when the user already knows a merchant domain') and an explicit exclusion with the correct alternative ('Do not use it to discover products; use global_search instead'). Nothing about when to select this tool 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.

verify_basketVerify a multi-merchant basket before handing it to checkoutA
Read-onlyIdempotent
Inspect

For a multi-item request, collect p2209_id and any selected variation_id from global_search results and send all selected items in one call. For every variable product, include a variation_id from its selected variants_compact entry on the first call; without it the price and basket total may be unknown. Never substitute WooCommerce numeric product IDs for p2209_id. Set live=false for a snapshot-only check with no merchant request; live=true reads merchants. Checks a basket of offers (up to 40 lines, any merchants) against the merchants' own data. Per merchant: subtotal, declared shipping options, and checkout handoff. Optional quote=true requires live=true and destination_details; it makes one bounded merchant request per basket and returns a WooCommerce quote when the merchant enabled it, otherwise unknown alongside the estimate. A quote creates no checkout session or order; checkout may still change the total.

NameRequiredDescriptionDefault
liveNofalse (default) uses saved Global data without contacting merchants; true reads each merchant now (at most 10 lines).
itemsYes
quoteNofalse by default. true requires live=true and destination_details, and may contact up to four merchants for WooCommerce quotes.
destinationNoISO 3166-1 country, optionally with region: "IT" or "IT:CB". Needed for shipping.
max_age_secondsNo
destination_detailsNoPostal destination for precise declared shipping zones even with quote=false and live=false; required for quote=true. Example: {country:"IT",state:"CB",postcode:"86100",city:"Campobasso"}.

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/openWorld annotations, the description discloses that live=true actually contacts merchants, that quote=true makes one bounded merchant request per basket, and that a quote creates no checkout session or order and the total may still change at checkout. It also warns that omitting variation_id can leave price and basket total unknown. That is exactly the kind of cost and side-effect disclosure the annotations cannot carry.

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

Conciseness3/5

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

Every sentence carries information, but the ordering is poor: procedural instructions about p2209_id and variation_id come before the reader is told what the tool actually does, so the purpose statement lands mid-paragraph. Several clauses restate schema-documented behavior (variation_id required to price a line), costing space without adding value.

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

Completeness4/5

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

For a six-parameter tool with a nested destination_details object, no output schema and broad annotations, the description covers the risky parts well: merchant contact, quote preconditions, and the fact that a quote is not an order. Remaining gaps are the return shape (no output schema exists to cover it) and the max_age_seconds parameter, which is never mentioned in either place.

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

Parameters4/5

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

Schema coverage is a moderate 67%, and the description adds real meaning the schema lacks — most importantly 'never substitute WooCommerce numeric product IDs for p2209_id' and the guidance that destination_details sharpens declared shipping zones even when quote and live are false. It reinforces but does not extend the variation_id semantics already documented in the schema, and it says nothing about max_age_seconds.

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?

The description states a specific verb and resource: it checks a basket of up to 40 offer lines against the merchants' own data and returns per-merchant subtotal, declared shipping options and checkout handoff. That scope implicitly separates it from the single-offer sibling verify_offer, though it never names the sibling explicitly. The core purpose sentence is buried after the tactical instructions, which slightly weakens first-read clarity.

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

Usage Guidelines5/5

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

It gives concrete when-to-use routing: gather p2209_id and any variation_id from global_search results and send all selected items in one call. It explicitly defines the live=false versus live=true tradeoff and the preconditions for quote=true (requires live=true plus destination_details). The alternative paths are spelled out rather than left to inference.

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

verify_offerVerify constraints on one offer (true / false / unknown)A
Read-onlyIdempotent
Inspect

Checks ONE offer (optionally a selected variant) and returns true, false or unknown per constraint with evidence. Pass constraints as an ARRAY, for example [{"field":"available"},{"field":"price","max":300,"currency":"EUR"},{"field":"ships_to","value":"IT:CB"}]. available has no expected key: ask for the fact and read its result. For a merchant-declared variant option use {"field":"option","keys":["pa_color"],"values":["black"]}; use only native merchant values, with variation_id for a specific variant. Nothing is inferred or translated. Results are unknown outside max_age_seconds (default 86400); live=true reads the merchant now. Checkout is the final authority.

NameRequiredDescriptionDefault
liveNotrue reads the merchant Bridge now (one request).
p2209_idYesOffer id from global_search (e.g. prod_duinshop-it_446678).
constraintsYesRequired array of 1-8 objects. Each object has field and only the keys shown by its schema. Examples: [{"field":"available"}], [{"field":"price","max":50,"currency":"EUR"}].
variation_idNoVariant to check (from matching_variants or variants_compact). Without it, variant-dependent constraints may be unknown.
max_age_secondsNo

TDQS

A4.3/5.0
Behavior5/5

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

Beyond annotations (readOnly/idempotent/non-destructive/openWorld), it discloses freshness semantics (unknown outside max_age_seconds, default 86400; live=true issues one merchant request) and the no-inference/no-translation rule. These are real behavioral traits an agent must know before trusting a result.

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?

Front-loaded with the core purpose and return contract, then parameter-shape examples. Dense but each sentence carries information; slightly run-on in the middle clause.

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

Completeness5/5

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

No output schema exists, and the description compensates by explaining the return contract (per-constraint verdict plus evidence) and the 'unknown' fallback. Given the 8-branch constraint union, this is sufficient for correct invocation.

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

Parameters4/5

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

With 80% schema coverage the baseline is 3, but the description adds genuine meaning: 'available' takes no expected key, 'option' uses merchant-native keys/values, and variation_id's effect on variant-dependent constraints. Only max_age_seconds' default is left to the description alone.

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 ('Checks') and resource ('ONE offer'), plus the return shape (true/false/unknown per constraint with evidence). The 'ONE offer' scoping implicitly separates it from verify_basket, but 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.

Usage Guidelines4/5

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

Gives concrete usage rules: constraints must be an array, native merchant values only, live=true for a fresh read, variation_id for a specific variant, and 'Checkout is the final authority'. It doesn't explicitly state when to prefer this over verify_basket or get_offer_attestation.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedglobal_search1 field changed
      • addedInput schema / properties / price_currency
        Added value: +{
+  "description": "ISO 4217 currency of min_price/max_price (e.g. EUR). With it, only offers priced in that currency are returned; without it the bounds compare numbers in each offer's own currency. Needs min_price or max_price.",
+  "pattern": "^[A-Za-z]{3}$",
+  "type": "string"
+}
  2. 1 tool update
    • Changedverify_basket1 field changed
      • changedInput schema / properties / destination_details / description
        Previous value: -"Postal destination for quote=true, e.g. {country:\"IT\",state:\"CB\",postcode:\"86100\",city:\"Campobasso\"}."New value: +"Postal destination for precise declared shipping zones even with quote=false and live=false; required for quote=true. Example: {country:\"IT\",state:\"CB\",postcode:\"86100\",city:\"Campobasso\"}."
  3. 1 tool update
    • Changedverify_basket2 fields changed
      • addedInput schema / properties / destination_details
        Added value: +{
+  "additionalProperties": false,
+  "description": "Postal destination for quote=true, e.g. {country:\"IT\",state:\"CB\",postcode:\"86100\",city:\"Campobasso\"}.",
+  "properties": {
+    "city": {
+      "maxLength": 100,
+      "type": "string"
+    },
+    "country": {
+      "pattern": "^[A-Z]{2}$",
+      "type": "string"
+    },
+    "postcode": {
+      "maxLength": 20,
+      "minLength": 1,
+      "type": "string"
+    },
+    "state": {
+      "maxLength": 16,
+      "type": "string"
+    }
+  },
+  "required": [
+    "country",
+    "postcode"
+  ],
+  "type": "object"
+}
      • addedInput schema / properties / quote
        Added value: +{
+  "description": "false by default. true requires live=true and destination_details, and may contact up to four merchants for WooCommerce quotes.",
+  "type": "boolean"
+}
  4. 1 tool update
    • Changedverify_basket2 fields changed
      • addedInput schema / properties / items / items / properties / variation_id / description
        Added value: +"For a variable product, pass the chosen variant ID from global_search variants_compact; required to price that line and compute a complete basket total."
      • changedInput schema / properties / live / description
        Previous value: -"true reads each merchant now (at most 10 lines)."New value: +"false (default) uses saved Global data without contacting merchants; true reads each merchant now (at most 10 lines)."
  5. 1 tool update
    • Changedverify_offer4 fields changed
      • changedInput schema / properties / constraints / description
        Previous value: -"Up to 8 constraints, e.g. [{\"field\":\"price\",\"max\":50},{\"field\":\"available\"},{\"field\":\"ships_to\",\"value\":\"IT:CB\"}]."New value: +"Required array of 1-8 objects. Each object has field and only the keys shown by its schema. Examples: [{\"field\":\"available\"}], [{\"field\":\"price\",\"max\":50,\"currency\":\"EUR\"}]."
      • removedInput schema / properties / constraints / items / additionalProperties
        Removed value: -{}
      • addedInput schema / properties / constraints / items / anyOf
        Added value: +[
+  {
+    "additionalProperties": false,
+    "properties": {
+      "currency": {
+        "pattern": "^[A-Z]{3}$",
+        "type": "string"
+      },
+      "field": {
+        "const": "price",
+        "type": "string"
+      },
+      "max": {
+        "minimum": 0,
+        "type": "number"
+      },
+      "min": {
+        "minimum": 0,
+        "type": "number"
+      }
+    },
+    "required": [
+      "field"
+    ],
+    "type": "object"
+  },
+  {
+    "additionalProperties": false,
+    "properties": {
+      "field": {
+        "const": "available",
+        "type": "string"
+      }
+    },
+    "required": [
+      "field"
+    ],
+    "type": "object"
+  },
+  {
+    "additionalProperties": false,
+    "properties": {
+      "field": {
+        "const": "option",
+        "type": "string"
+      },
+      "keys": {
+        "items": {
+          "minLength": 1,
+          "type": "string"
+        },
+        "maxItems": 16,
+        "type": "array"
+      },
+      "values": {
+        "items": {
+          "minLength": 1,
+          "type": "string"
+        },
+        "maxItems": 32,
+        "minItems": 1,
+        "type": "array"
+      }
+    },
+    "required": [
+      "field",
+      "values"
+    ],
+    "type": "object"
+  },
+  {
+    "additionalProperties": false,
+    "properties": {
+      "field": {
+        "const": "brand",
+        "type": "string"
+      },
+      "values": {
+        "$ref": "#/properties/constraints/items/anyOf/2/properties/values"
+      }
+    },
+    "required": [
+      "field",
+      "values"
+    ],
+    "type": "object"
+  },
+  {
+    "additionalProperties": false,
+    "properties": {
+      "field": {
+        "const": "merchant",
+        "type": "string"
+      },
+      "values": {
+        "$ref": "#/properties/constraints/items/anyOf/2/properties/values"
+      }
+    },
+    "required": [
+      "field",
+      "values"
+    ],
+    "type": "object"
+  },
+  {
+    "additionalProperties": false,
+    "properties": {
+      "field": {
+        "const": "attribute",
+        "type": "string"
+      },
+      "keys": {
+        "$ref": "#/properties/constraints/items/anyOf/2/properties/keys"
+      },
+      "values": {
+        "$ref": "#/properties/constraints/items/anyOf/2/properties/values"
+      }
+    },
+    "required": [
+      "field",
+      "values"
+    ],
+    "type": "object"
+  },
+  {
+    "additionalProperties": false,
+    "properties": {
+      "field": {
+        "const": "barcode",
+        "type": "string"
+      },
+      "values": {
+        "$ref": "#/properties/constraints/items/anyOf/2/properties/values"
+      }
+    },
+    "required": [
+      "field",
+      "values"
+    ],
+    "type": "object"
+  },
+  {
+    "additionalProperties": false,
+    "properties": {
+      "field": {
+        "const": "ships_to",
+        "type": "string"
+      },
+      "value": {
+        "pattern": "^[A-Z]{2}(:[A-Z0-9-]{1,10})?$",
+        "type": "string"
+      }
+    },
+    "required": [
+      "field",
+      "value"
+    ],
+    "type": "object"
+  }
+]
      • removedInput schema / properties / constraints / items / type
        Removed value: -"object"
  6. 1 tool update
    • Changedglobal_search1 field changed
      • addedInput schema / properties / variant_price_currency
        Added value: +{
+  "description": "ISO 4217 currency of variant_price_min/max (e.g. EUR). With it, only variants priced in that currency satisfy the bound; no FX conversion. Without it, bounds compare numbers in each variant's own currency.",
+  "pattern": "^[A-Za-z]{3}$",
+  "type": "string"
+}
  7. 1 tool update
    • Addedverify_basket
  8. 4 tool updates
    • Addedestimate_delivered_cost
    • Addedget_offer_attestation
    • Changedglobal_search4 fields changed
      • addedInput schema / properties / cursor
        Added value: +{
+  "description": "Opaque next_cursor from a previous global_search with the SAME arguments; returns the next page. A cursor from a different query is rejected.",
+  "maxLength": 512,
+  "type": "string"
+}
      • changedInput schema / properties / limit / description
        Previous value: -"Max offers to return (1-25, default 10). No pagination; raise to get more in one call"New value: +"Max offers per page (1-25, default 10). Use next_cursor for the next page."
      • addedInput schema / properties / merchant
        Added value: +{
+  "description": "Restrict to one merchant: merchant_id as returned in result_facets.merchants or offers (e.g. \"duinshop-it\") or its domain.",
+  "maxLength": 253,
+  "type": "string"
+}
      • addedInput schema / properties / result_facets
        Added value: +{
+  "description": "true adds result_facets: counts over ALL matching offers (not just this page) by merchant, category leaf, brand, availability, and price quartiles per currency. Use them to narrow the next call.",
+  "type": "boolean"
+}
    • Addedverify_offer
  9. 1 tool update
    • Changedglobal_search7 fields changed
      • addedInput schema / properties / variant
        Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "items": {
+              "type": "string"
+            },
+            "maxItems": 32,
+            "type": "array"
+          }
+        ]
+      },
+      "type": "object"
+    },
+    {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "keys": {
+            "items": {
+              "type": "string"
+            },
+            "maxItems": 16,
+            "type": "array"
+          },
+          "values": {
+            "items": {
+              "type": "string"
+            },
+            "maxItems": 32,
+            "minItems": 1,
+            "type": "array"
+          }
+        },
+        "required": [
+          "values"
+        ],
+        "type": "object"
+      },
+      "maxItems": 4,
+      "type": "array"
+    }
+  ],
+  "description": "Constraints that must ALL hold on the SAME variant. Keys and values are the merchant's own, in any language or script (read variant_vocabulary first): {\"pa_taglia\":\"L\"}, {\"size\":[\"L\",\"Large\"]}, {\"*\":[\"rouge\",\"rosso\"]} (* = any option), or [{\"keys\":[\"pa_taglia\",\"size\"],\"values\":[\"L\",\"Large\"]}] across merchants. KaliCart never translates: pass every value you accept. match.kind: exact (ignoring case, Latin accents, separators) or normalized (same number+unit symbol, NxN, size code). Indexed snapshot: verify on the merchant before quoting."
+}
      • addedInput schema / properties / variant_facets
        Added value: +{
+  "description": "true adds variant_vocabulary: real option keys and values with variant and in-stock counts, for the offers returned or, with no q, for the merchant (or all merchants). Use it to choose the values to pass in variant.",
+  "type": "boolean"
+}
      • addedInput schema / properties / variant_facets_limit
        Added value: +{
+  "description": "Max values per option key in variant_vocabulary (1-200, default 40); values_total is always the full count",
+  "maximum": 200,
+  "minimum": 1,
+  "type": "integer"
+}
      • addedInput schema / properties / variant_in_stock
        Added value: +{
+  "description": "true keeps only variants whose own availability is in_stock",
+  "type": "boolean"
+}
      • addedInput schema / properties / variant_limit
        Added value: +{
+  "description": "Max matching variants returned per offer (1-500, default 50); matching_variant_count is always the full count",
+  "maximum": 500,
+  "minimum": 1,
+  "type": "integer"
+}
      • addedInput schema / properties / variant_price_max
        Added value: +{
+  "description": "Upper bound on the variant price (major units)",
+  "minimum": 0,
+  "type": "number"
+}
      • addedInput schema / properties / variant_price_min
        Added value: +{
+  "description": "Lower bound on the variant price (major units)",
+  "minimum": 0,
+  "type": "number"
+}
  10. 1 tool update
    • Changedlist_merchants1 field changed
      • changedOutput schema / properties / merchants / items / required
        Previous value: -[
-  "merchant_id",
-  "merchant_domain",
-  "storefront_url",
-  "platform",
-  "product_count",
-  "last_sync"
-]New value: +[
+  "merchant_id",
+  "merchant_domain",
+  "platform",
+  "product_count",
+  "last_sync"
+]
  11. 5 tool updates
    • Changedget_product1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {
+    "attributes": {},
+    "availability": {},
+    "category": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "error": {
+      "type": "string"
+    },
+    "handoff": {},
+    "merchant_id": {
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    },
+    "p2209_id": {
+      "type": "string"
+    },
+    "price": {},
+    "product_url": {
+      "anyOf": [
+        {
+          "format": "uri",
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "provenance": {},
+    "scope": {
+      "additionalProperties": true,
+      "properties": {
+        "type": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "type"
+      ],
+      "type": "object"
+    },
+    "storefront_url": {
+      "anyOf": [
+        {
+          "format": "uri",
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "updated_at": {
+      "anyOf": [
+        {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "format": "date-time",
+              "type": "string"
+            }
+          ]
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "variants": {}
+  },
+  "required": [
+    "p2209_id"
+  ],
+  "type": "object"
+}
    • Changedglobal_search8 fields changed
      • changedInput schema / properties / gender / description
        Previous value: -"Gender facet. Use a value from get_meta.accepted_filters.gender; aliases may be normalized. If the value is unknown, the search returns an explicit error rather than broadening the result."New value: +"Canonical gender facet. Filtering is discovery-tolerant: untagged and unisex products can remain candidates, so verify the chosen product. Allowed values: female, male, unisex."
      • addedInput schema / properties / gender / enum
        Added value: +[
+  "female",
+  "male",
+  "unisex"
+]
      • removedInput schema / properties / gender / maxLength
        Removed value: -64
      • changedInput schema / properties / max_price / description
        Previous value: -"Upper bound of the requested interval. A matching range may include variants above this bound; verify the chosen variant. Per-offer currency, no FX conversion."New value: +"Upper bound in major currency units (for example 1550 means EUR 1,550 for EUR offers). A matching range may include variants above this bound; verify the chosen variant. Per-offer currency, no FX conversion."
      • addedInput schema / properties / max_price / minimum
        Added value: +0
      • changedInput schema / properties / min_price / description
        Previous value: -"Lower bound of the requested interval. Matches overlapping variant price ranges in each offer currency; no FX conversion. Verify the chosen variant."New value: +"Lower bound in major currency units (for example 50 means EUR 50 for EUR offers). Matches overlapping variant price ranges in each offer currency; no FX conversion. Verify the chosen variant."
      • addedInput schema / properties / min_price / minimum
        Added value: +0
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {
+    "applied_filters": {
+      "additionalProperties": {},
+      "type": "object"
+    },
+    "coverage": {
+      "additionalProperties": true,
+      "properties": {
+        "limit": {
+          "exclusiveMinimum": 0,
+          "type": "integer"
+        },
+        "more_results_possible": {
+          "type": "boolean"
+        },
+        "returned": {
+          "minimum": 0,
+          "type": "integer"
+        },
+        "total_known": {
+          "type": "boolean"
+        }
+      },
+      "required": [
+        "returned",
+        "limit",
+        "total_known",
+        "more_results_possible"
+      ],
+      "type": "object"
+    },
+    "error": {
+      "type": "string"
+    },
+    "federated": {
+      "type": "boolean"
+    },
+    "guidance_code": {
+      "type": "string"
+    },
+    "offers": {
+      "items": {
+        "additionalProperties": true,
+        "properties": {
+          "availability_status": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "category_leaf": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "handoff": {},
+          "merchant_domain": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "p2209_id": {
+            "type": "string"
+          },
+          "price": {},
+          "provenance": {}
+        },
+        "required": [
+          "p2209_id",
+          "merchant_domain",
+          "name"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "result_count": {
+      "minimum": 0,
+      "type": "integer"
+    },
+    "scope": {
+      "additionalProperties": true,
+      "properties": {
+        "type": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "type"
+      ],
+      "type": "object"
+    }
+  },
+  "type": "object"
+}
    • Changedlist_categories2 fields changed
      • changedInput schema / properties / parent / description
        Previous value: -"Filter to children of this node (e.g. \"apparel\")"New value: +"Optional canonical node to restrict results to that node and its subtree (for example apparel or home.bedroom)"
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "categories": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "leaf": {
+            "type": "string"
+          },
+          "product_count": {
+            "minimum": 0,
+            "type": "integer"
+          }
+        },
+        "required": [
+          "leaf",
+          "product_count"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "complete_via": {
+      "format": "uri",
+      "type": "string"
+    },
+    "filtered_by": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "next_step": {
+      "type": "string"
+    },
+    "returned_count": {
+      "minimum": 0,
+      "type": "integer"
+    },
+    "total": {
+      "minimum": 0,
+      "type": "integer"
+    },
+    "truncated": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "categories",
+    "total",
+    "returned_count",
+    "truncated",
+    "filtered_by"
+  ],
+  "type": "object"
+}
    • Changedlist_merchants2 fields changed
      • changedInput schema / properties / limit / description
        Previous value: -"Max merchants to return (default 20, max 50), ordered by product count desc. No pagination"New value: +"Max merchants to return (default 20, max 50), ordered by product count descending. No pagination"
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "merchants": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "last_sync": {
+            "anyOf": [
+              {
+                "anyOf": [
+                  {
+                    "type": "string"
+                  },
+                  {
+                    "format": "date-time",
+                    "type": "string"
+                  }
+                ]
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "merchant_domain": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "merchant_id": {
+            "type": "string"
+          },
+          "platform": {
+            "type": "string"
+          },
+          "product_count": {
+            "minimum": 0,
+            "type": "integer"
+          },
+          "storefront_url": {
+            "format": "uri",
+            "type": "string"
+          }
+        },
+        "required": [
+          "merchant_id",
+          "merchant_domain",
+          "storefront_url",
+          "platform",
+          "product_count",
+          "last_sync"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "returned_count": {
+      "minimum": 0,
+      "type": "integer"
+    },
+    "total": {
+      "minimum": 0,
+      "type": "integer"
+    },
+    "truncated": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "merchants",
+    "total",
+    "returned_count",
+    "truncated"
+  ],
+  "type": "object"
+}
    • Changedlookup_merchant1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {
+    "bridge_access": {
+      "type": "string"
+    },
+    "bridge_detected": {
+      "type": "boolean"
+    },
+    "bridge_version": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "consent": {},
+    "domain": {
+      "type": "string"
+    },
+    "federation_status": {
+      "type": "string"
+    },
+    "merchant_discovery_url": {
+      "anyOf": [
+        {
+          "format": "uri",
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "observed_at": {
+      "anyOf": [
+        {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "format": "date-time",
+              "type": "string"
+            }
+          ]
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "probe": {
+      "type": "string"
+    },
+    "registered": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "registered",
+    "domain"
+  ],
+  "type": "object"
+}
  12. 1 tool update
    • Changedglobal_search6 fields changed
      • changedInput schema / properties / gender / description
        Previous value: -"Gender facet (normalized): male, female, unisex, kids"New value: +"Gender facet. Use a value from get_meta.accepted_filters.gender; aliases may be normalized. If the value is unknown, the search returns an explicit error rather than broadening the result."
      • removedInput schema / properties / gender / enum
        Removed value: -[
-  "male",
-  "female",
-  "unisex",
-  "kids"
-]
      • addedInput schema / properties / gender / maxLength
        Added value: +64
      • changedInput schema / properties / in_stock / description
        Previous value: -"Only offers with availability_status=in_stock"New value: +"true filters product-level stock in the indexed snapshot. Does not verify a selected variant or a booking slot."
      • changedInput schema / properties / max_price / description
        Previous value: -"Maximum price filter (numeric; per-offer merchant currency, no FX conversion)"New value: +"Upper bound of the requested interval. A matching range may include variants above this bound; verify the chosen variant. Per-offer currency, no FX conversion."
      • changedInput schema / properties / min_price / description
        Previous value: -"Minimum price filter (numeric; per-offer merchant currency, no FX conversion)"New value: +"Lower bound of the requested interval. Matches overlapping variant price ranges in each offer currency; no FX conversion. Verify the chosen variant."
  13. 1 tool update
    • Changedglobal_search1 field changed
      • changedInput schema / properties / color / description
        Previous value: -"Color family (e.g. \"blue\")"New value: +"Bridge color family (e.g. \"blue\"). Common aliases are resolved to a family available in the active index. A family match does not guarantee an exact shade; read filter_semantics.color and verify the chosen product via handoff.bridge_product_url."

Publisher details

Operator
SAVE THE BRAIN (VAT IT01830350706, Colletorto, Italia) · Publisher source
Operator website
https://www.kalicart.com
Vendor relationship
Not applicable
Documentation
Not applicable
Trust center
Not applicable
Restrictions
Not applicable

Related MCP Connectors

Related MCP Servers

  • Agent Studio — WooCommerce

    Hemakrishna7406
    A
    license
    B
    quality
    B
    maintenance
    A read-only MCP server that lets an Agent Studio agent query a WooCommerce store's orders, products, inventory and customers, with pagination, filtering, typed errors and automatic rate-limit retry. It never mutates store data, keeping the blast radius of an agent's actions bounded to reads.
    7
    MIT

  • ai-chat-for-amazon-bedrock

    noteflowai
    A
    license
    Not graded
    quality
    A
    maintenance
    WordPress plugin that runs an MCP server on your own site: search and read published posts and pages, look up WooCommerce products, describe the site as schema.org types and query site figures, with drafts only when the site enables them. Signed-in access by default; anonymous access and OAuth are optional and off.
    2
    GPL 2.0

  • cross-shop

    ahalekelly
    A
    license
    A
    quality
    B
    maintenance
    Batch-first MCP server for product search, product detail, and anonymous shipping quotes across public storefronts and marketplaces, exposing search, product, quote, and images commands with compact JSON output for AI agents.
    4
    MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources