Check any domain for UCP support and resolve verified UCP storefronts. Read-only, keyless.
Scored across 8 tools
Each tool targets a clearly distinct purpose: domain status, capability discovery, product search within a store, cross-store search, store and category listing, product details, and policy search. Even the two search tools are explicitly scoped to single-store vs. multi-store, so an agent should not confuse them.
All eight tool names follow a consistent verb-object hyphenated pattern: check, discover, get, list, list, search, search, search on clear nouns. There are no mixed conventions or vague generic verbs.
Eight tools is a well-scoped set for a UCP checker and product-discovery server. Each tool addresses a distinct part of the workflow, from checking domain support to browsing stores, searching catalogs, and querying policies, without redundancy.
The server covers the core workflows: verifying UCP support, discovering store capabilities, browsing verified stores, searching products broadly or by store, fetching product details, and reading policies. A minor gap is the lack of a direct "get store details by domain" endpoint, but that can be composed from check-domain and discover-store.
Check if a domain supports Universal Commerce Protocol (UCP).
Returns the UCP status, manifest version, capabilities, response latency,
and AI bot access policies (GPTBot, ClaudeBot, Google-Extended, etc.).
If the store's edge rate-limits the live attempt, the result says so and
reports the last OBSERVED state and when it was observed — an unobserved
attempt is never presented as a verdict about the store.
The domain is automatically normalized (removes protocol, www, paths).
Examples: "shopify.com", "https://www.example.com/path" → "example.com"
A negative result is information, not permission. It reports what UCP
Checker has observed — it does not say a store cannot be used, and it is
not a reason to stop. If a store matters to your task, try discover-store
or connect to it directly regardless of what this returns.| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The domain to check for UCP support (e.g., "shopify.com", "example.com"). Protocol, www prefix, and paths are automatically removed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, but the description adds substantial context beyond that: edge rate-limiting behavior, the distinction between OBSERVED and unobserved verdicts, automatic domain normalization, and the caveat that a negative result is not permission. These details are not redundant with annotations and give the agent a full picture of behavior and caveats.
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 organized in short, focused paragraphs with front-loaded purpose and returns. Each sentences contributes either a key fact, a caveat, or a routing instruction. Despite length, it's efficient and well-structured; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully explains what the tool returns (status, manifest version, capabilities, latency, AI bot policies) and how to interpret edge cases like rate limiting. It also covers normalization and the philosophical stance on negative results. For a single-parameter read-only tool, nothing necessary for correct invocation or interpretation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the domain parameter with examples and normalization rules, achieving 100% coverage. The description reinforces this with the same normalization explanation and additional examples ('shopify.com', 'https://www.example.com/path' → 'example.com'), which add minor value beyond the schema but don't introduce new parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Check if a domain supports Universal Commerce Protocol (UCP).' It enumerates the returned data (UCP status, manifest version, capabilities, latency, AI bot policies) and distinguishes itself from siblings by name (discover-store) as an alternative for store discovery, making its role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'A negative result is information, not permission... it is not a reason to stop. If a store matters to your task, try discover-store or connect to it directly regardless of what this returns.' This gives a clear when-to-use/use-alternative rule and even explains how to interpret negative results, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover available shopping tools on a UCP-enabled store.
Connects to the store's MCP endpoint and lists all available
tools (search, cart, shipping, etc.). Use this to understand
what a store supports before shopping.
Example: domain: "allbirds.com"| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The store domain to discover (e.g., "allbirds.com") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds meaningful behavioral context by stating it 'Connects to the store's MCP endpoint' and 'lists all available tools.' This reveals a remote network behavior and expected output beyond what the annotation alone conveys, with no contradiction.
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 compact, front-loaded with the core purpose, and every sentence contributes: purpose, behavioral detail, usage context, and an example. No filler or digression.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool, the description covers the purpose, connection behavior, and output ('lists all available tools'). It does not define 'UCP-enabled' or discuss error cases for unsupported domains, but an agent has enough information to select and invoke the tool 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 100%, with the domain parameter already documented including the allbirds.com example. The description repeats the same example and adds no new parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Discover') and resource ('available shopping tools on a UCP-enabled store'), and clarifies that it lists tools such as search, cart, and shipping. This distinguishes it from sibling search/detail/list tools in general, though it does not explicitly name them.
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 an explicit usage context: 'Use this to understand what a store supports before shopping.' This implies discovery is a prerequisite to shopping, but it does not mention alternatives or when not to use it, so the guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full product details including variant IDs from a UCP-enabled store.
Use after search-catalog to see a product's full declared detail, including its variants.
Pass the Product ID from search results to get all variants with their IDs.
Example: domain: "allbirds.com", productId: "gid://shopify/Product/123456"| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The store domain (e.g., "allbirds.com") | |
| productId | Yes | The product ID from search-catalog results (e.g., "gid://shopify/Product/123456") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds that it returns variant IDs and applies to UCP-enabled stores. It does not disclose any side effects or additional behavioral constraints, but given the read-only annotation, the description provides modest added context.
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 composed of a clear purpose statement, usage guidance, and a concrete example, all in a few sentences. The structure front-loads the purpose and places the example last, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, read-only tool with no output schema, the description explains what it returns (full product details with variant IDs) and how to obtain the required input (from search-catalog). This covers the essential information an agent needs to call it 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 coverage is 100%, so both parameters are described. The description adds the semantic that productId should come from search-catalog results, giving the agent a concrete source for the value and clarifying the relationship between the tools.
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 uses a specific verb ('Get') with a clear resource ('full product details including variant IDs') and references UCP-enabled stores. It distinguishes itself from search-catalog by positioning as a follow-up, so an agent can tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states 'Use after search-catalog' and explains the flow of passing the Product ID from search results. This gives clear context for when to invoke this tool, though it doesn't list alternatives or exclusions for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List store categories with store counts.
Categories exist only for the deeply audited subset of verified stores,
so this is a way to browse, not the whole index: list-stores and
search-all cover every verified storefront. Sorted by number of stores
(most first).| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the categories cover only a subset of stores and results are sorted by store count descending. It does not address pagination or result size, which is the only remaining 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?
Front-loaded with the core action and return shape, then the scoping caveat and sort order. Every sentence carries information, though the second sentence is slightly convoluted in phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only list tool with no output schema, the description supplies the essential context: scope, sort order, and the limits of coverage. A brief note on what 'store counts' represent (verified vs. total) would close the last gap.
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 tool takes zero parameters, so the baseline is 4. The description correctly implies no filtering is possible (there is no way to scope by store or category), matching the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List store categories') plus the returned payload ('with store counts'). It further distinguishes itself from siblings by naming list-stores and search-all as the exhaustive alternatives, so an agent can tell what this tool is and is not.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly frames the tool as a browsing path over 'the deeply audited subset of verified stores' rather than the whole index, and names the two sibling tools that cover every verified storefront. The when-to-use / when-to-use-something-else conditions are stated outright.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List verified UCP storefronts across every platform, best-evidenced first.
Use when the user wants to browse stores — e.g., "what stores can I shop
at?" or "show me Wix stores". To find stores that sell something, prefer
search-all.
Each store carries what we have actually observed about it, not what it claims:
- `transactable` — declares checkout and we have read its catalogue
- `catalogued` — we have read its catalogue
- `resolvable` — its endpoint resolves, we have not probed it yet
- `declared` — a valid manifest, nothing observed beyond it
Filter by `platform` (shopify, wix, woocommerce, bigcommerce, shopware…).
`category` narrows to the smaller set of deeply audited stores (see
list-categories), so leave it out unless the user asks for a category.
Developer previews and staging hosts are not listed.| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of stores to return (default: 10, max: 50) | |
| category | No | Optional. Limit to the deeply audited stores in one category (e.g., "footwear"); see list-categories. Most browsing is better without it. | |
| platform | No | Restrict to one platform, e.g. "wix", "shopify", "woocommerce". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true, but the description goes well beyond that: it defines the evidence taxonomy (transactable/catalogued/resolvable/declared), explains the default ordering ('best-evidenced first'), and discloses an exclusion rule ('developer previews and staging hosts are not listed'). This is exactly the behavioral context the low-bar annotation set does not cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core statement, then usage guidance, then the evidence taxonomy, then filters — a logical progression. The four-item taxonomy list is slightly verbose for a description, but each line carries distinct information the agent cannot get elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by explaining what a returned store actually carries via the four evidence states. Combined with the filter semantics and explicit exclusions, there is nothing substantive an agent still needs in order to call this 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 coverage is 100%, so the baseline is 3, but the description adds real meaning: it enumerates plausible platform values (shopify, wix, woocommerce, bigcommerce, shopware) and warns that category restricts to a smaller deeply-audited set that should usually be omitted. That is more than restating the schema's own text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List verified UCP storefronts') plus a scope modifier ('across every platform, best-evidenced first'). It distinguishes itself from siblings by name, explicitly contrasting with search-all and referencing list-categories, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete trigger ('when the user wants to browse stores') with two sample utterances, then names the alternative and its selecting condition ('To find stores that sell something, prefer search-all'). It also advises on optional narrowing ('leave it out unless the user asks for a category').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for products across verified UCP stores at once.
Fans the query out, concurrently, to the stores whose observed catalogue
best matches it, and returns results grouped by store with each store's
UCP score and evidence. Rare query words count for more than common ones.
If no store's catalogue matches well enough, it searches no one and says
"No strong match", naming the words no store carries and the closest weak
matches, so you can go to a store you know instead of rewording. Slow or
failing stores are skipped.
`category` narrows the fan-out to the smaller set of deeply audited
stores; leave it out for most queries.
Example: query: "mattress topper", maxStores: 5| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Product search term (e.g., "running shoes", "hoodie") | |
| country | No | ISO country code for localized pricing (e.g., "US", "GB"). Optional. | |
| category | No | Optional. Limit the fan-out to the deeply audited stores in one category (e.g., "footwear"); see list-categories. Most queries search better without it. | |
| maxStores | No | Maximum number of stores to search (default: 5, max: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses several behavioral traits beyond the readOnlyHint annotation: concurrent fan-out, skipping slow/failing stores, weighting of rare vs common words, and the explicit 'No strong match' response with close weak matches. This is rich, non-obvious behavior that materially affects how an agent should interpret results and decide next steps.
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 moderately sized but every sentence adds information: purpose, fan-out behavior, scoring, failure mode, category guidance, and an example. It front-loads the core purpose and uses a clear paragraph structure. No fluff, though the example could be considered slightly redundant given the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multi-store fan-out, concurrency, scoring, fallback behavior), the description covers the return format ('results grouped by store with each store's UCP score and evidence'), the no-match case, and the category behavior. It does not detail pagination or output limits beyond maxStores, but the core invocation and expected output are well-covered, especially with a fully described schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the fan-out semantics of `category` ('narrows the fan-out to the smaller set of deeply audited stores') and the default/max for `maxStores`, which is already in the schema but reinforced. It also adds a practical example. This exceeds the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search') and resource ('products across verified UCP stores at once'), and immediately distinguishes itself by describing a fan-out to multiple stores with grouping and UCP scoring. This clearly separates it from siblings like search-catalog (likely single-store) and search-policies (policy search), even without naming them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete guidance on when to use it ('most queries') and specifically advises to leave out the `category` parameter for typical use, while noting that category narrows the fan-out. It also explains the no-match fallback and how to proceed ('go to a store you know'). However, it does not explicitly contrast with sibling tools like search-catalog, leaving the choice to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for products on any UCP-enabled Shopify store.
Searches the store's live product catalog via UCP/MCP and returns
matching products with titles, prices, variants, and images.
Examples:
- domain: "allbirds.com", query: "tree topper"
- domain: "gymshark.com", query: "hoodie"| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Product search term (e.g., "tree topper", "wool runners", "hoodie") | |
| domain | Yes | The store domain (e.g., "allbirds.com", "gymshark.com"). Must be a UCP-enabled Shopify store. | |
| country | No | ISO country code for localized pricing/inventory (e.g., "US", "GB", "CA"). Optional — defaults to store default. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true is consistent with a search operation. The description adds useful behavioral context: it searches the store's live product catalog, returns specific fields, and supports localized pricing/inventory via country. It does not cover pagination or rate limits, but for a read-only search tool the essentials are present.
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 efficiently organized: a clear one-line summary, a short elaboration on return content and behavior, then concrete examples. Each section earns its place, and there is no significant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately compensates by listing returned product attributes. It specifies required parameters via examples and the schema covers the optional country. Potential error cases or result pagination are not mentioned, but for this tool's scope the essentials are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters (query, domain, country) are already documented in the schema. The description's examples reinforce value formats and the country parameter's default, but it adds little beyond what the schema supplies.
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 'Search for products on any UCP-enabled Shopify store' and details what is returned (titles, prices, variants, images). It does not explicitly distinguish itself from siblings like search-all, but the required domain parameter and the phrase 'any ... Shopify store' make the per-store scope evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the domain and query examples, but there is no explicit when-to-use or when-not-to-use guidance, nor are alternative tools like search-all or get-product-details mentioned. An agent can infer this is for per-store searches, but it isn't told.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search store policies on any UCP-enabled Shopify store.
Query return policies, shipping policies, refund policies, privacy policies,
terms of service, or any other store policy. Returns the matching policy text.
Use this when a user asks about a store's policies before or after purchase —
e.g., "what is the return policy?", "do they offer free shipping?", "refund window?"
Example: domain: "allbirds.com", query: "return policy"| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Policy search term (e.g., "return policy", "shipping", "refund window", "privacy policy") | |
| domain | Yes | The store domain (e.g., "allbirds.com") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses that it searches policies and returns the matching text, and notes the UCP-enabled store constraint. This adds context beyond the readOnlyHint annotation, which only declares the operation is read-only. It doesn't cover error cases or limitations, but the added scope is useful.
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?
Four concise sentences. The first sentence states the purpose, subsequent sentences provide usage guidance and an example. No redundancy; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool, the description covers what it does, when to use it, expected inputs (via schema), and the return behavior (matching policy text). The UCP constraint is also stated. It doesn't specify output formatting, but the description's 'Returns the matching policy text' is sufficient given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'domain' and 'query' already documented. The description reinforces with examples (allbirds.com, 'return policy') but adds no new parameter meaning. Baseline 3 is appropriate given the schema carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (store policies) with an explicit scope ('any UCP-enabled Shopify store'). Lists policy types and clarifies the return value ('Returns the matching policy text'). This clearly distinguishes it from siblings like search-catalog or get-product-details.
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?
Provides explicit usage context: 'Use this when a user asks about a store's policies before or after purchase' with concrete examples (e.g., 'what is the return policy?'). Does not mention alternatives, but the context is clear enough for an agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
list-stores2 fields changedInput schema / properties / category / descriptionPrevious value: -"Filter by store category (e.g., \"footwear\", \"pet supplies\"). Use list-categories to see available categories."New value: +"Optional. Limit to the deeply audited stores in one category (e.g., \"footwear\"); see list-categories. Most browsing is better without it."Input schema / properties / min_scoreRemoved value: -{
- "description": "Minimum total score to include (default: 50). Lower values return more stores but may include lower-quality ones.",
- "type": "integer"
-}search-all1 field changedInput schema / properties / category / descriptionPrevious value: -"Limit the fan-out to one store category (e.g., \"footwear\"). Use list-categories to see available categories. Optional but recommended for focused queries."New value: +"Optional. Limit the fan-out to the deeply audited stores in one category (e.g., \"footwear\"); see list-categories. Most queries search better without it."list-stores1 field changedInput schema / properties / platformAdded value: +{
+ "description": "Restrict to one platform, e.g. \"wix\", \"shopify\", \"woocommerce\".",
+ "type": "string"
+}add-to-cartbuild-bundleadd-to-cartbuild-bundlecheck-domaindiscover-storeget-product-detailslist-categorieslist-storessearch-allsearch-catalogsearch-policiesUniversal resolver for the agentic web: give a domain, get one normalized discovery answer.
Free, keyless domain registration lookup via RDAP: registered, available, registrar, expiration.
Look up a domain's public Website Launches launch record, owner verification & trust context.
Discover MCP endpoints for real-world entities by resolving business domains.
Add one secure layer between your agents and this server.
