cross-shop
Search products on AliExpress via its Affiliate API (affiliate search only; no quote).
Search Amazon product listings via SerpApi, providing unverified leads without anonymous cart or quote support.
Search products, get product details, and request anonymous shipping quotes from BigCommerce storefronts.
Search products and get details with shipping via eBay Browse API; checkout APIs are restricted.
Search Google Shopping product listings via SerpApi, returning merchant leads to verify.
Search products and get details from Salesforce Commerce Cloud storefronts.
Search products, get details, and request shipping quotes from Shopify storefronts, including Shopify Global Catalog offers via shop.app.
Search products, get details, and request shipping quotes from Squarespace storefronts.
Search products and retrieve details from Wix storefronts; checkout quotes may require a browser.
Search products, get details, and request shipping quotes from WooCommerce stores.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@cross-shopsearch for bearings on example.com"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
cross-shop
cross-shop batches product search, exact product detail, and anonymous destination shipping quotes across public storefronts and marketplaces. Its compact JSON output is built for AI agents: store constants are hoisted, empty fields disappear, search results use handles instead of refs, and image URLs stay in the run cache.
Install
Install the CLI from PyPI:
uv tool install cross-shop
cross-shop search '[{"store":"https://example.com","query":"bearing"}]'Run a one-off command without installing:
uvx cross-shop search '[{"store":"https://example.com","query":"bearing"}]'Other commands follow the same form:
cross-shop product '["r1.1.1"]'
cross-shop quote '[{"store":"https://example.com","lines":[{"item":"r1.1.1.2","quantity":3}]}]'
cross-shop images r1.1.1 1:3
cross-shop config showFrom a source checkout, replace cross-shop with uv run --project <package-dir> cross-shop. Run tests with uv run --project <package-dir> pytest.
Related MCP server: KaliCart Global
MCP
The stdio MCP server exposes search, product, quote, and images with the same compact results as the CLI. Register it with Claude Code:
claude mcp add cross-shop -- uvx cross-shop mcpEquivalent .mcp.json:
{
"mcpServers": {
"cross-shop": {
"command": "uvx",
"args": ["cross-shop", "mcp"]
}
}
}Pi can read the same config through pi-mcp-adapter, installed with pi install npm:pi-mcp-adapter.
Commands
search <entries-json> [--limit 20] [--description-chars 300] [--redetect] [--debug]accepts 1–100{store,query}entries. Repeated stores share one session and detection, and products are deduplicated.product <items-json> [--description-chars 2000] [--redetect] [--debug]accepts 1–100 product URLs, run handles, or ref objects.quote <quotes-json> [--destination <json>] [--redetect] [--debug]accepts 1–20 stores with 1–20 lines each. One cart contains every line for a store entry.images <item-handle> [N|START:END]downloads at most ten cached product images and prints absolute paths.config set-destination <json>,config show, andconfig import-vendors <path>manage persistent configuration.config showreports configured credential blocks without printing secrets or private-key paths.mcpruns the stdio MCP server.
Search and product write monotonic run IDs. r7.2.5 means item 5 from store 2 in run 7; r7.2.5.3 means its third variant. Handles expire after seven days. Product detail emits strict, self-contained durable refs such as {"platform":"shopify","store":"https://example.com","variant_id":"gid://shopify/ProductVariant/123"}. Product URLs with query strings or fragments are rejected because those components can carry identity; Amazon product URLs are normalized to their ASIN.
Store workers run concurrently, up to five at a time. Operations for one store remain sequential in one isolated cookie jar. An unexpected adapter exception becomes an api_error for that store without aborting other workers. Exit status is 1 when any entry has status:api_error.
Storefronts and marketplaces
Storefront adapters cover Shopify, WooCommerce, Magento GraphQL/HTML/guest REST, BigCommerce Stencil/Storefront REST, Squarespace, Wix, Ecwid, and Salesforce Commerce Cloud boundaries. Wix, Ecwid, and customized SFCC or OpenCart checkout remain explicit browser boundaries.
These origins use marketplace adapters without live platform detection:
Origin | Backend | Detail and quote boundary |
| Shopify Global Catalog UCP MCP | Detail preserves seller domains and handoff links; quote a merchant offer |
| AliExpress Affiliate API | Affiliate search only; no quote |
| SerpApi Google Shopping | Unverified leads; quote the merchant |
| SerpApi search and Amazon all-offers display detail | Exact ASIN detail; no anonymous cart API |
| eBay Browse API | Detail includes shipping; checkout APIs are restricted-tier |
| SerpApi Walmart search and anonymous item-page detail | Exact item detail; delivery location follows the request IP, so no quote |
| Best Buy Products API | Exact SKU detail; shipping fields are catalog-level, so no quote |
| Etsy Open API v3 | Exact listing detail; quotes are buyer prices for the destination country |
Google Shopping, Amazon search, AliExpress, and Walmart search results are leads. Re-verify the exact listing, variant, stock, and delivered price. An Etsy listing with variations prices its cheapest offering, so its variant is named Lowest-priced variation.
Data and settings
The default data directory comes from platformdirs.user_data_path("cross-shop"). Set CROSS_SHOP_DATA_DIR to override it. Runtime data never writes into the package tree.
settings.jsonstores destination and optional integrations.vendors.jsonis the atomic, lock-protected canonical-origin platform registry.run-counternever resets, so deleted runs cannot make old handles point at new data.runs/stores full seven-day result payloads, including refs and image URLs omitted from stdout.images/stores files downloaded byimages.
Destination precedence is --destination, then settings.json, then the built-in San Francisco address. country and postal_code are required; region, city, and address1 are optional.
{
"destination": {"country":"US","region":"CA","city":"San Francisco","address1":"747 Howard St","postal_code":"94103"},
"web_bot_auth": {"private_key_path":"/secure/private.pem","key_directory_url":"https://agent.example/.well-known/http-message-signatures-directory"},
"ebay": {"client_id":"…","client_secret":"…"},
"bestbuy": {"api_key":"…"},
"etsy": {"keystring":"…","shared_secret":"…"},
"shopify_global": {"profile_url":"https://agent.example/profile.json"}
}Credentials
SERPAPI_API_KEY: SerpApi Google Shopping, Amazon, and Walmart search.ALIEXPRESS_APP_KEYandALIEXPRESS_APP_SECRET: AliExpress Affiliate Product Query.settings.ebay.client_idandsettings.ebay.client_secret: eBay Developers Program production Browse API keyset. Production access requires eBay marketplace account-deletion notification compliance.settings.bestbuy.api_key: Best Buy Developer API key, issued only to company-domain email addresses. Its terms cap caching at 72 hours and forbid use on behalf of other retailers.settings.etsy.keystringandsettings.etsy.shared_secret: Etsy Open API v3 app credentials from the approval-gated registration at etsy.com/developers/register.settings.shopify_global.profile_url: public UCP agent profile required by Shopify's Global Catalog contract.
Missing marketplace credentials produce a structured setup error only when that marketplace is requested.
Web Bot Auth
Shopify product URLs resolve through the public Ajax product endpoint; durable variant refs resolve through Storefront GraphQL. Unsigned Shopify HTTP is the default. settings.web_bot_auth opts into Ed25519 HTTP Message Signatures. The signer validates the key type and JWK thumbprint, creates fresh nonce and expiry material for every request, refuses pre-signed requests, and signs redirects only after the Shopify adapter verifies the HTTPS authority and API path. A configured but missing or unreadable key is an api_error; the tool never falls back to unsigned traffic.
Host your public key directory with the included Cloudflare Worker.
Available Tools
4 toolsimagesA
Download up to ten cached images for item handle r..; selection is N or START:END.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | ||
| selection | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It discloses the 'up to ten' limit and the selection format (N or START:END), providing useful constraints. However, it does not explain what happens on invalid handles or selection ranges, or what 'cached' implies about freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One well-structured sentence that front-loads the action, limit, and selection format. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema means return values need not be described. The description covers the tool's purpose, key parameters, and selection syntax, which is sufficient for a moderately complex tool. It lacks context about the meaning of the handle components or caching behavior, but overall is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description explains the 'handle' parameter as 'r<run>.<s>.<i>' and 'selection' as 'N or START:END', providing semantics beyond the raw schema. This compensates well for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads up to ten cached images for a given item handle, with a specific selection syntax. It distinguishes from sibling tools (product, search, quote) which are not about image downloading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a user needs cached images for a specific item handle, but does not explicitly contrast it with alternatives or state when not to use. No exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
productA
Fetch detail for 1–100 product URLs, refs, or r..[.] handles. Product results issue fresh handles for quote.
| Name | Required | Description | Default |
|---|---|---|---|
| inputs | Yes | ||
| redetect | No | ||
| description_chars | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It clearly states this is a fetch (read) operation, implying non-destructive behavior. It also discloses a notable trait: 'Product results issue fresh handles for quote,' which is useful for downstream tool chaining. However, it does not mention potential side effects, error conditions, or permission requirements, so it is not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise and front-loaded with the main purpose. The second sentence about fresh handles is a bit cryptic but still relevant and short. No redundant information, and the format is clean. It could be improved by separating parameters, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters and an output schema, which covers return values. However, the description omits explanations for 'redetect' and 'description_chars', and uses domain-specific terms like 'refs' and 'r<run>.<s>.<i>[.<v>]' that are not defined. It is adequate for a straightforward product detail fetch but leaves gaps for a fully autonomous agent to use all features correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions input types (URLs, refs, handles) which relates to the 'inputs' parameter, but it does not describe 'redetect' or 'description_chars' at all. The description adds minimal semantic value beyond the schema's bare titles, leaving the agent to guess the meaning of the other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches product details, specifying the exact input types (URLs, refs, or handles) and a batch size range (1–100). This distinguishes it from sibling tools like search, quote, and images, which have different purposes. The verb 'Fetch detail' is specific and aligns with the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving product details when you have product identifiers (URLs, refs, handles). It does not explicitly contrast with alternatives, but the context of sibling tools (search, quote, images) makes it clear this is for direct product lookups. The 1–100 range also conveys batch usage. No exclusions or prerequisites are mentioned, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
quoteC
Quote 1–20 stores with 1–20 lines each. Each item accepts a URL, ref, or r..[.] handle; use . for multi-variant products.
| Name | Required | Description | Default |
|---|---|---|---|
| quotes | Yes | ||
| redetect | No | ||
| destination | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose side effects, permissions, and behavioral traits on its own. It mentions constraints (1–20 stores/lines) and handle syntax, but doesn't state whether the operation is read-only, modifies anything, or requires special permissions. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It front-loads the core capacity and then packs in the essential parameter format, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool has an output schema (covering return values), the description omits semantics for two of three parameters ('redetect' and 'destination') and lacks any usage context or alternative tool comparisons. For a tool with three parameters and only core input documented, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides meaningful detail for the 'quotes' parameter, explaining acceptable values (URL, ref, handle) and the format for multi-variant products. However, it leaves 'redetect' and 'destination' completely unexplained, and with 0% schema description coverage, it only partially compensates for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the specific action of quoting 1–20 stores with 1–20 lines each, which distinguishes it from sibling tools like product, search, and images. However, it doesn't explicitly state the outcome or high-level purpose of a 'quote', leaving some ambiguity for an AI agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like product, search, or images. The description only covers capacity limits and input format, not the appropriate context or conditions for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchB
Search 1–100 {store, query} entries. Results use r.. item handles; append . for a variant, then pass handles to product or quote.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| entries | Yes | ||
| redetect | No | ||
| description_chars | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden. It usefully reveals the result handle format (r<run>.<s>.<i>) and variant suffix, but it doesn't mention pagination, result limits, or any side effects. The read-only nature is inferable from 'Search' but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence with no filler, making it concise and front-loaded. However, the compactness creates ambiguity (e.g., '1–100' and '{store, query}'), so it's not maximally clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema existing, the description fails to explain key parameters like redetect and description_chars, and only partially clarifies entries. The workflow hint is helpful, but overall the tool cannot be used with full confidence without making assumptions about three of the four inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides some meaning for 'entries' by suggesting each has 'store' and 'query' fields, but limit, redetect, and description_chars are completely unexplained, leaving the agent with significant gaps for three of four parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Search' and resource 'entries' clearly identify the tool's core purpose. The description also hints at the workflow by mentioning results can be passed to product or quote, which helps distinguish it from downstream tools, though it doesn't explicitly differentiate from 'images' and the '{store, query}' notation is ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear workflow context: search first, then pass handles to product or quote. It doesn't state when not to use the tool or compare it to the 'images' sibling, so it lacks explicit exclusions but still provides useful situational guidance.
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.
4 tool updates
v0.1.0- First observed
images - First observed
product - First observed
quote - First observed
search
TDQS
Scored across 4 tools
Each tool performs a distinct operation: search finds items, product retrieves details, quote generates quotes, and images downloads images. There is no overlap in their primary purposes, and the handles passed between them make the workflow clear.
All tool names are single lowercase words, which is consistent in format. However, they mix noun and verb forms (search is a verb, product and images are nouns), but this minor inconsistency does not impede predictability.
With exactly 4 tools, the server is tightly scoped to its cross-shop search, product detail, quoting, and image retrieval purpose. Each tool has a clear, non-redundant role, making the count ideal.
The tool set covers the core workflow: search, fetch product details, create quotes, and download images. Minor gaps like store listing or order management exist but fall outside the apparent scope of this server.
Maintenance
Related MCP Connectors
Hosted MCP for e-commerce: live product catalog, stock, and pricing for AI agents.
Unified MCP server for 70+ eCommerce platforms: products, orders, customers, and more.
Federated commerce search across independent WooCommerce merchants. Keyless, read-only MCP server.
Hosted Amazon Seller and Vendor MCP server for Claude, ChatGPT, Cursor, Codex, Gemini, Copilot.
Related MCP Servers
- AlicenseAqualityDmaintenanceMCP server that wraps Shopify, Amazon, and Google Maps intelligence tools. AI agents pay autonomously in USDC on Base via x402 — no API keys or accounts needed.62MIT
- FlicenseNot gradedqualityCmaintenanceFederated commerce search MCP server enabling AI agents to query real product offers, prices, and availability across independent WooCommerce stores without API keys or registration.-

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- FlicenseNot gradedqualityBmaintenanceMCP server providing unified access to eBay, Shopify, Best Buy, and Etsy marketplace data via the Commerce API, enabling product searches and listing retrieval across multiple retailers.-