Search products from independent stores. Read-only remote MCP; no sign-in. Buy on merchant sites.
Scored across 2 tools
The two tools have clearly distinct purposes: find_shop_nobi_page finds editorial pages about a topic, while search_products searches actual product catalogs. The descriptions explicitly contrast the two, even stating that page-finding is not for product search, so an agent can easily select the right tool.
Both names use a verb_noun pattern (find_..._page, search_products), though one includes a brand prefix and the other does not, creating a minor deviation. The conventions are otherwise readable and consistent.
Only 2 tools for a shopping discovery server is extremely thin and cannot adequately cover typical user needs such as product comparison, filtering, or store browsing. The scope implied by the descriptions suggests far more operations should exist.
The surface covers finding products and topic pages, but there is no tool for getting product details, comparing products, listing stores, or paginating results. Significant gaps will cause agents to hit dead ends for common shopping workflows.
Finds a Shop Nobi web page about a product topic, such as "leather boots" or "linen dresses", to link to. It does not search products, so it is not the tool for a shopper's request to find or compare products. Each page lists matching products from many stores with a short buying guide. Returns the page's title, description and link only when its topic has the same words, allowing changes in word order, accents and singular or plural forms. Says when no matching page exists. It never substitutes a broader page. exactMatch is true for every returned page.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | The product topic, in a few plain words, such as "leather boots". |
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| found | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (read-only, idempotent, not destructive). The description adds substantive behavior the annotations cannot: matching is word-order, accent and plural tolerant; no broader page is ever substituted; the tool reports when no matching page exists; and exactMatch is true for every result.
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 sentences, front-loaded with purpose followed by the exclusion, matching rules and no-match behavior. Dense but each sentence carries information; nothing is redundant with the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup with an output schema and full annotation coverage, the description supplies everything an agent needs: scope, exclusion, matching semantics and edge-case behavior (no match, no substitution). Nothing material is left to inference.
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% and the topic parameter is documented, so baseline is 3. The description adds real interpretive value beyond the schema by explaining how the topic string is matched (same words, variable order/accents/plurals) and giving examples like 'leather boots' or 'linen dresses'.
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 (finds) and resource (a Shop Nobi web page about a product topic) and immediately distinguishes itself from product search: 'It does not search products.' An agent can tell this apart from the sibling search_products 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 clear negative condition — it is not for a shopper wanting to find or compare products — which routes the agent toward search_products. It stops short of naming that sibling explicitly, so the alternative is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches the product catalogs of curated independent online stores, chosen for the quality of their catalogs, for products that match the request. It fits requests to find, compare or choose products, such as "find me waterproof hiking boots under $200", gift ideas, or a specific product type or brand. Unlike a general web search, it returns products rather than web pages: each result is one product with its name, the store that sells it, its price and currency, whether it is in stock, an image, and a direct link to its page on the store's own website. Store catalogs are kept constantly refreshed, so prices and stock are up to date. Shop Nobi sells nothing itself: the user buys from the store. Links carry UTM tags that tell the store the visit came from Shop Nobi. When a product's linkLabel is set, such as "We may earn a commission", show it next to that product's link.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many products to return, from 1 to 20. The default is 10. | |
| query | Yes | What the user is looking for, in plain words, with the details that matter to them, such as "waterproof hiking boots" or "linen dress for a summer wedding under $150". |
| Name | Required | Description |
|---|---|---|
| products | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it enumerates the exact fields returned per product, states that catalogs are continuously refreshed so prices/stock are current, clarifies that the platform sells nothing itself (the store fulfills), discloses that links carry UTM tags, and gives a rendering instruction for linkLabel. That is substantive operational context the annotations cannot supply.
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 what the tool does and how its output differs from web search, then layers operational detail. Sentences are dense and mostly earn their place, though the UTM-commerce paragraph is longer than strictly needed to call the tool correctly.
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 being present, the description still characterizes result contents, freshness, and attribution/linkLabel handling, leaving no gaps an agent would need before invoking it. Nothing material 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?
Schema description coverage is 100%, so the schema already documents both query and limit (including default and 1–20 bounds). The description adds only plain-words phrasing examples for query, which is marginal value over the schema; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (searches) and resource (product catalogs of curated independent online stores), and explicitly distinguishes the output from a general web search: it returns products, not pages. An agent can tell immediately what this tool produces without opening the 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 concrete fit criteria ('find, compare or choose products') with illustrative requests, and states the negative case versus a general web search. It does not, however, mention the sibling find_shop_nobi_page or draw any boundary against it, so routing between the two remains an inference.
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.
find_shop_nobi_pagesearch_productsSearch products from independent Shopify stores: prices, merchant offers and buy links.
Federated commerce search across independent WooCommerce merchants. Keyless, read-only MCP server.
Read-only fashion and beauty product search across popular online shops, any price, any language.
Product search for agents: price, merchant, rating and checkout links across online stores.
Add one secure layer between your agents and this server.
