A
licenseB
qualityA
maintenanceRead-only MCP server for WooCommerce that enables answering questions about products, orders, sales, and blog posts via the WordPress REST API without needing plugins or write access.
5
46 npm
2
MIT
kalicart-global
Server Details
Federated commerce search across independent WooCommerce merchants. Keyless, read-only MCP server.
Ownership verified
- Status
- Healthy
- Uptime
- 100.0% over 39 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- giuseppesocci-bot/kalicart-global
- GitHub Stars
- 0
- Server Listing
- KaliCart Global
TDQS
A4.7/5.0
Scored across 5 tools
Disambiguation5/5
Each tool targets a distinct purpose: global_search discovers product candidates, get_product retrieves detailed indexed data for a selected candidate, list_categories provides category vocabulary, list_merchants enumerates participating merchants, and lookup_merchant checks a specific merchant's registry status. The overlap between list_merchants and lookup_merchant follows a standard list/get pattern, so no real ambiguity exists.
Naming Consistency4/5
Tool names mostly follow a verb_noun pattern: list_categories, list_merchants, get_product, lookup_merchant. global_search breaks the pattern slightly (adjective + noun rather than verb + noun), but the inconsistency is minor and the intent is still clear.
Tool Count5/5
Five tools is well-scoped for a read-only cross-merchant search and registry discovery service. Each tool covers a distinct part of the workflow without redundancy or unnecessary bloat.
Completeness5/5
The tool surface covers the full discovery journey: category exploration, product search, product detail lookup, merchant enumeration, and merchant registry inspection. The handoff links replace checkout/payment operations, which are intentionally external, so there are no obvious dead ends for the stated purpose.
Available Tools
5 toolsget_productGet indexed product detailsARead-onlyIdempotentInspect
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. 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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| p2209_id | Yes | KaliCart product ID (e.g. prod_duinshop-it_432395) |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| name | No | |
| error | No | |
| price | No | |
| scope | No | |
| handoff | No | |
| category | No | |
| p2209_id | Yes | |
| variants | No | |
| attributes | No | |
| provenance | No | |
| updated_at | No | |
| merchant_id | No | |
| product_url | No | |
| availability | No | |
| storefront_url | No |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds material behavioral context: this is a snapshot, not live merchant verification, and the returned handoff must be followed before confirming variant, price, or stock. That staleness/handoff disclosure is exactly the kind of trait an agent needs and cannot get from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the trigger condition before the ID provenance rule and the skip condition. No redundant restatement of the name or schema.
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?
With an output schema present, the description needn't explain return values, and it covers the remaining gaps an agent needs: prerequisite source of the ID, the snapshot limitation, the handoff requirement, and when to skip. Nothing essential is missing for a 1-parameter read tool.
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% and the single parameter is fully documented in the schema, so baseline would be 3. The description adds provenance semantics beyond the schema: p2209_id must originate from global_search, which is a real constraint on how to obtain a valid value.
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 and resource ('get product' returning indexed details) and explicitly positions itself against the sibling global_search. The scope is clear, though it does not enumerate what 'indexed details' comprises beyond the caveat that it is a snapshot rather than live merchant data.
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 explicit when-to-use ('after global_search when the selected candidate needs indexed details not already on its search card') and when-not-to-use ('skip this call when the search card already answers the question'), plus the prerequisite that p2209_id must come from global_search. Alternatives and exclusions are fully covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
global_searchSearch products across merchantsARead-onlyIdempotentInspect
Use this when a user wants to find or compare product candidates across participating WooCommerce merchants. Search with q and/or a canonical category leaf; results contain snapshot price and stock, match evidence, provenance, and merchant Bridge handoff links. Do not use this as final price, variant, stock, checkout, or payment authority; verify the selected offer through its handoff.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free-text product query. Each term must match as a whole word in the native merchant catalog text (name, short description, description) or in the canonical category path, so English category terms reach catalogs written in other languages: q="mattress" returns products under home.bedroom.mattress even when their text is Italian. There is no server-side translation of product text; for language-neutral retrieval by category use leaf and the canonical filters. | |
| leaf | No | Canonical category node. Accepts a terminal leaf (e.g. beverages.alcohol.sparkling_prosecco) or any parent node (e.g. jewellery, home.bedroom): a parent matches the node and its whole subtree, so you can widen or narrow the search by moving up or down the tree. Use list_categories to browse the tree. | |
| brand | No | Brand facet filter (normalized, e.g. "nike") | |
| color | No | 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. | |
| limit | No | Max offers to return (1-25, default 10). No pagination; raise to get more in one call | |
| gender | No | Canonical gender facet. Filtering is discovery-tolerant: untagged and unisex products can remain candidates, so verify the chosen product. Allowed values: female, male, unisex. | |
| in_stock | No | true filters product-level stock in the indexed snapshot. Does not verify a selected variant or a booking slot. | |
| max_price | No | 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. | |
| min_price | No | 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| scope | No | |
| offers | No | |
| coverage | No | |
| federated | No | |
| result_count | No | |
| guidance_code | No | |
| applied_filters | No |
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/openWorld, and the description adds material behavior beyond them: results are snapshot (not live) data, verification must happen through the merchant Bridge handoff, and filters are discovery-tolerant rather than authoritative. This is exactly the extra context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the use case, then the result shape, then the guardrail. Every clause carries distinct information; no restatement of the name or title.
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?
With an output schema present the description need not enumerate return fields, yet it still characterizes the result payload and the handoff requirement. Combined with full schema coverage, an agent has everything needed to call this correctly and interpret the response.
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 schema already documents all nine parameters in depth; the baseline would be 3. The description still adds the combination rule ('q and/or a canonical category leaf') and the pagination-free limit behavior, which is helpful beyond the schema text.
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 ('find or compare product candidates across participating WooCommerce merchants') and scopes the result contents (snapshot price/stock, match evidence, provenance, handoff links). An agent can distinguish this discovery tool from the detail-oriented siblings (get_product, lookup_merchant) 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly gives the trigger condition ('when a user wants to find or compare product candidates') and an explicit exclusion ('Do not use this as final price, variant, stock, checkout, or payment authority'), naming the correct alternative path (the handoff link). The schema additionally routes tree browsing to list_categories.
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 categoriesARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| parent | No | Optional canonical node to restrict results to that node and its subtree (for example apparel or home.bedroom) |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| next_step | No | |
| truncated | Yes | |
| categories | Yes | |
| filtered_by | Yes | |
| complete_via | No | |
| returned_count | Yes |
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 merchantsARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max merchants to return (default 20, max 50), ordered by product count descending. No pagination |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| merchants | Yes | |
| truncated | Yes | |
| returned_count | Yes |
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 BridgeARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Merchant domain, e.g. shop.example.com |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| probe | No | |
| domain | Yes | |
| consent | No | |
| registered | Yes | |
| observed_at | No | |
| bridge_access | No | |
| bridge_version | No | |
| bridge_detected | No | |
| federation_status | No | |
| merchant_discovery_url | No |
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
list_merchants1 field changed- changed
Output schema / properties / merchants / items / requiredPrevious value: -[ - "merchant_id", - "merchant_domain", - "storefront_url", - "platform", - "product_count", - "last_sync" -]New value: +[ + "merchant_id", + "merchant_domain", + "platform", + "product_count", + "last_sync" +]
5 tool updates
- Changed
get_product1 field changed- changed
Output 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" +}
- Changed
global_search8 fields changed- changed
Input schema / properties / gender / descriptionPrevious 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." - added
Input schema / properties / gender / enumAdded value: +[ + "female", + "male", + "unisex" +] - removed
Input schema / properties / gender / maxLengthRemoved value: -64 - changed
Input schema / properties / max_price / descriptionPrevious 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." - added
Input schema / properties / max_price / minimumAdded value: +0 - changed
Input schema / properties / min_price / descriptionPrevious 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." - added
Input schema / properties / min_price / minimumAdded value: +0 - changed
Output 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" +}
- Changed
list_categories2 fields changed- changed
Input schema / properties / parent / descriptionPrevious 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)" - changed
Output 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" +}
- Changed
list_merchants2 fields changed- changed
Input schema / properties / limit / descriptionPrevious 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" - changed
Output 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" +}
- Changed
lookup_merchant1 field changed- changed
Output 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" +}
1 tool update
- Changed
global_search6 fields changed- changed
Input schema / properties / gender / descriptionPrevious 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." - removed
Input schema / properties / gender / enumRemoved value: -[ - "male", - "female", - "unisex", - "kids" -] - added
Input schema / properties / gender / maxLengthAdded value: +64 - changed
Input schema / properties / in_stock / descriptionPrevious 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." - changed
Input schema / properties / max_price / descriptionPrevious 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." - changed
Input schema / properties / min_price / descriptionPrevious 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."
1 tool update
- Changed
global_search1 field changed- changed
Input schema / properties / color / descriptionPrevious 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."
1 tool update
- Changed
global_search1 field changed- changed
Input schema / properties / leaf / descriptionPrevious value: -"Canonical category leaf (e.g. beverages.alcohol.sparkling_prosecco)"New value: +"Canonical category node. Accepts a terminal leaf (e.g. beverages.alcohol.sparkling_prosecco) or any parent node (e.g. jewellery, home.bedroom): a parent matches the node and its whole subtree, so you can widen or narrow the search by moving up or down the tree. Use list_categories to browse the tree."
1 tool update
- Changed
global_search1 field changed- changed
Input schema / properties / q / descriptionPrevious value: -"Free-text product query matched against native merchant catalog text; no server-side translation. Translate when needed, or use leaf and canonical filters for language-neutral retrieval."New value: +"Free-text product query. Each term must match as a whole word in the native merchant catalog text (name, short description, description) or in the canonical category path, so English category terms reach catalogs written in other languages: q=\"mattress\" returns products under home.bedroom.mattress even when their text is Italian. There is no server-side translation of product text; for language-neutral retrieval by category use leaf and the canonical filters."
1 tool update
- Changed
global_search1 field changed- changed
Input schema / properties / q / descriptionPrevious value: -"Free-text query, any language (e.g. \"prosecco\", \"materasso memory foam\")"New value: +"Free-text product query matched against native merchant catalog text; no server-side translation. Translate when needed, or use leaf and canonical filters for language-neutral retrieval."
2 tool updates
- Changed
global_search4 fields changed- added
Input schema / properties / gender / descriptionAdded value: +"Gender facet (normalized): male, female, unisex, kids" - added
Input schema / properties / limit / descriptionAdded value: +"Max offers to return (1-25, default 10). No pagination; raise to get more in one call" - added
Input schema / properties / max_price / descriptionAdded value: +"Maximum price filter (numeric; per-offer merchant currency, no FX conversion)" - added
Input schema / properties / min_price / descriptionAdded value: +"Minimum price filter (numeric; per-offer merchant currency, no FX conversion)"
- Changed
list_merchants1 field changed- added
Input schema / properties / limit / descriptionAdded value: +"Max merchants to return (default 20, max 50), ordered by product count desc. No pagination"
3 tool updates
- Added
get_product - Added
list_categories - Added
list_merchants
2 tool updates
- First observed
global_search - First observed
lookup_merchant
Related MCP Connectors
Unified MCP server for 70+ eCommerce platforms: products, orders, customers, and more.
Google Shopping products, prices, sellers, and deals as structured data via a hosted MCP server.
Real-time data APIs for 50+ commerce, grocery, social and maps platforms over one OAuth MCP server
Multi-tenant MCP gateway for AI commerce. One connection, every store.
Related MCP Servers
- AlicenseAqualityBmaintenanceBatch-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.4MIT
BizNetAI MCP Serverofficial
AlicenseNot gradedqualityBmaintenanceA hosted MCP server that routes natural-language shopping queries to independent merchant storefronts, returning normalized product and merchant results for AI agents and shopping assistants.MIT- AlicenseAqualityBmaintenanceRead-only MCP server for searching Yahoo! Shopping products through the Yahoo! Shopping Item Search API v3. It supports keyword and JAN-code search with price, stock, condition, shipping, sorting, category, brand, seller, image-size, and pagination filters.11MIT
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.