Search products from independent stores. Read-only remote MCP; no sign-in. Buy on merchant sites.
Scored across 7 tools
Each tool targets a distinct shopping task: search, exact details, price/stock, comparison, alternatives, page lookup, and provider info. Overlap is minimal, and find_shop_nobi_page explicitly disclaims product search, reducing likely misselection.
All names use snake_case consistently, and most follow a verb_noun pattern such as search_products, compare_products, and get_product_details. The main minor deviations are about_mcp as a noun-style info tool and the brand-specific find_shop_nobi_page.
Seven tools is well-scoped for a shopping assistant server. Each tool earns its place by covering a distinct step in product discovery, evaluation, or provenance lookup.
The surface covers product search, exact detail retrieval, price and stock checks, comparisons, alternatives, and editorial page lookup. Minor gaps exist around cart/checkout or broader category/store browsing, but those may be intentionally out of scope.
Says who provides this MCP server and gives their website. Call it when someone asks who built or runs this server. It takes no arguments and returns nothing about any catalog. For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one.
| Name | Required | Description | Default |
|---|---|---|---|
| visitorId | No | For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one. |
| Name | Required | Description |
|---|---|---|
| website | No | |
| provider | No | |
| visitorId | No | For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one. |
| thisServer | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real value beyond them by explaining the stateful visitorId convention — omit on first call, echo unchanged on follow-ups, never invent one — which no annotation conveys.
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?
Purpose and trigger condition are front-loaded in the first two sentences, which is exactly right. The final sentence duplicates the schema's parameter description word-for-word, so it is redundant payload rather than new information.
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 an output schema present, the description need not explain return values, and it still names the two things returned (provider identity and website). For a zero-required-parameter, single-parameter tool, nothing an agent needs in order 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the visitorId semantics are already fully documented in the schema. The description restates that guidance nearly verbatim, which aids recall but adds no new meaning. Baseline 3 applies when the schema does the heavy lifting.
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: reports who provides the server and their website. It also explicitly scopes itself away from the sibling catalog tools ("returns nothing about any catalog"), so an agent can distinguish it from check_price_and_availability or get_product_details without opening any 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?
"Call it when someone asks who built or runs this server" gives an explicit trigger condition, and the catalog disclaimer implicitly rules out product-query use. It stops short of naming an alternative tool for adjacent questions, but the sibling set makes the boundary obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the current price, currency, whether it is in stock, and the stock count when the store gives one, for one or more products found in a product search, taking their ids from the search results. Store catalogs are kept constantly refreshed, so the price and stock are up to date. There is no price history, as the catalogs keep none. For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Nobi variant ids, each from a product search result. | |
| visitorId | No | For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one. |
| Name | Required | Description |
|---|---|---|
| products | Yes | |
| visitorId | No | For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely non-schema context: catalogs are continuously refreshed so values are current, and no price history exists anywhere. Missing is any statement about behavior for unknown ids or partial results.
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?
Returns are front-loaded in the first sentence, followed by freshness, scope limits, and the visitorId protocol — a sensible ordering. It loses a point only for restating the visitorId guidance already present in 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?
With rich annotations, an output schema, and full schema coverage, the description needs to carry little, and it still explains the return shape and data-freshness caveats. The one remaining gap is that the batch limit of 20 and handling of invalid ids are left entirely to the 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%, and the visitorId sentence in the description is a verbatim copy of the schema's field description, so no new meaning is added. The ids parameter gains only the framing that they originate from a prior search, which the schema already says.
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 names a specific operation and enumerates exactly what comes back: price, currency, stock flag, and conditional stock count, for one or more products. It also delimits scope by ruling out price history, so an agent can separate this from get_product_details or search_products 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the input source clearly — ids must come from a product search result — and gives an explicit rule for the visitorId across turns (omit first call, pass unchanged after, never invent). It stops short of naming when to prefer compare_products or find_alternatives, so no explicit alternatives are offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compares two or more products found in a product search, side by side, taking their ids from the search results. It returns the attributes the products share, such as price, brand, color and material, with each product's value, so a shopper can tell them apart. It lines up only the attributes at least one product gives, so products with few details still compare cleanly. For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Nobi variant ids, each from a product search result. | |
| visitorId | No | For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one. |
| Name | Required | Description |
|---|---|---|
| visitorId | No | For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one. |
| comparison | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, and the description adds genuinely new traits: it explains that the result lines up the union of attributes so sparse products still compare, and that visitorId must be echoed unchanged on follow-ups and never invented. These are behaviors not derivable from the annotations.
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 compare action and result shape, then the session rule. Slightly redundant: the visitorId sentence is repeated verbatim from the schema description rather than adding new framing, but nothing is truly wasteful.
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?
Covers prerequisite (ids from search), result semantics (shared attributes with each product's value), edge handling (sparse products), and session continuity. An output schema exists, so return formatting needn't be restated.
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% and the schema already states that ids are Nobi variant ids from a product search result and carries the same visitorId wording. The description adds no syntax or constraint detail beyond that baseline, so a 3 is appropriate.
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 — compares products side by side — and pins the scope to 'two or more' products drawn from a search. It is easily separable from siblings like search_products and 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?
Gives clear context: use it on ids that came out of a product search, and describes the first-vs-follow-up call distinction via visitorId. It does not explicitly contrast with find_alternatives or get_product_details, so an agent must infer when comparison beats alternatives or full details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds products like one found in a product search, from across the stores, leaving out that same product. It takes the product's id from a product search result, and an optional price ceiling. It returns products the same way a product search does, each with its price, whether it is in stock, an image and a link, and it collapses the same product sold by more than one store to one. For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The Nobi variant id from a search result; the same identity is named variantId. | |
| limit | No | How many alternatives to return, from 1 to 10. The default is 5. | |
| maxPrice | No | The most an alternative may cost, in the product's currency. Leave it out for no price limit. | |
| visitorId | No | For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one. |
| Name | Required | Description |
|---|---|---|
| products | Yes | |
| visitorId | No | For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered; the description still adds real behavior: exclusion of the source product and collapsing duplicates across stores into one result. It also carries the visitorId session-continuation rule, which is not in the annotations. Some space is spent re-listing return fields the output schema already documents, which caps it at 4 rather than 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?
Front-loaded with the core behavior and the exclusion constraint in the first clause, and it stays in a single dense paragraph with no filler. However, the enumeration of return fields duplicates the output schema and the visitorId sentence is copied from the parameter schema, so not 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 read-only, four-parameter lookup with a full output schema, the description covers everything an agent needs: the prerequisite input, the exclusion rule, deduplication behavior, an optional price filter, and the multi-turn visitorId lifecycle. Nothing required 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and every parameter is already described in the schema, including the id's origin, the limit range, and the currency basis for maxPrice. The description restates these at a high level and repeats the visitorId sentence almost verbatim, adding no syntax or edge-case meaning beyond the schema (e.g., what happens if maxPrice is in a different currency). 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 and resource ('Finds products like one found in a product search') and adds the defining constraint 'leaving out that same product,' which separates it from search_products and compare_products. An agent can tell what this returns 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?
Makes the prerequisite explicit: it takes an id from a prior product-search result and optionally a price ceiling, so an agent knows this is a follow-up call rather than a cold-start search. It never names sibling tools like compare_products or get_product_details as alternatives, so the routing guidance stops short of full exclusion rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | The product topic, in a few plain words, such as "leather boots". | |
| visitorId | No | For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one. |
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| found | Yes | |
| visitorId | No | For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive/closed-world, yet the description adds the matching contract that no structured field carries: same words with order, accent and plural tolerance, no fallback to broader pages, exactMatch always true, and an explicit 'says when no matching page exists' for the empty case. The visitorId continuation rule adds session-behavior context beyond the schema.
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 purpose and the key exclusion; every sentence carries matching, fallback, or return-shape information. The visitorId sentence is duplicated word-for-word from the schema, which is the one piece of pure waste.
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 tool with an output schema, everything needed is present: what it matches, what it refuses to do, the empty-result behavior, and the return fields. The visitorId lifecycle is spelled out for multi-turn use.
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 only restates the schema's own visitorId guidance verbatim ('send the visitorId returned by a previous result unchanged... do not invent one') and adds nothing on the topic format that the schema does not already supply.
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 ('Finds a Shop Nobi web page about a product topic') and immediately distinguishes it from the product-search siblings: 'It does not search products, so it is not the tool for a shopper's request to find or compare products.' An agent can place this tool without consulting any 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 an explicit use case ('to link to') and an explicit exclusion covering search_products and compare_products by function. It stops short of naming the sibling tools, so the agent must map 'find or compare products' onto the actual tool names itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads exact product or variant details from Shop Nobi's public catalog. Supply one selector: id or variantId for a Nobi variant, productId for a Nobi parent product, sourceVariantId or sourceProductId for the store's own catalog ID, sku, or productUrl for an exact stored URL. Shopify product or variant IDs must be paired with the selling merchant: send storeDomain, such as example.com, or a known Nobi merchantId. Source IDs and SKUs are never resolved globally. Nobi IDs accept a UUID or the Base62 ID returned by search. Shopify source IDs accept numeric IDs or correctly typed Shopify GIDs. A parent selection returns parent information and variant choices, with id, variantId, price, currency, stock, inventory and variant specifications unset until a variant is selected. Ambiguous or conflicting selectors are refused. The tool never fetches a supplied URL. Catalogs contain no reviews or ratings. For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Legacy alias for variantId, returned as id by search. | |
| sku | No | Literal exact SKU within one store. Duplicate matches are refused. Requires merchant context. | |
| productId | No | Nobi parent product UUID or Base62 product ID; selects no variant. | |
| variantId | No | Nobi variant UUID or Base62 variant ID. | |
| visitorId | No | For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one. | |
| merchantId | No | The store's Nobi merchant UUID, returned by search. | |
| productUrl | No | An exact HTTPS catalog product URL, optionally with its numeric Shopify variant selector. Never fetched. | |
| storeDomain | No | The store's exact hostname, such as example.com, or its HTTPS address. | |
| sourceProductId | No | The store's parent product ID, such as a Shopify numeric product ID or Product GID. Pair it with storeDomain (the selling merchant's hostname) or a known Nobi merchantId. | |
| sourceVariantId | No | The store's variant ID, such as a Shopify numeric variant ID or ProductVariant GID. Pair it with storeDomain (the selling merchant's hostname) or a known Nobi merchantId. |
| Name | Required | Description |
|---|---|---|
| found | Yes | |
| product | Yes | |
| visitorId | No | For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, and the description correctly stays consistent with them. It adds real behavioral context beyond the annotations: parent selections return variant fields unset, ambiguous selectors are refused, the supplied URL is never fetched, and catalogs contain no reviews or ratings. However, the visitorId sentence is copied verbatim from the schema, so part of the text adds no new signal.
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 purpose and the selector decision, then supporting constraints, so an agent can stop reading early. It is dense and largely waste-free, but the visitorId guidance duplicates the schema text word-for-word rather than summarizing it, which is the one sentence that does not earn its place twice.
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 ten-parameter, seven-way oneOf lookup tool, this covers everything an agent needs: purpose, selector selection, merchant pairing prerequisite, partial-result behavior for parent IDs, refusal behavior, and an explicit note on non-returned data. Since an output schema exists, it correctly does not spell out the response shape, and instead spends that space on the partial-parent caveat that the schema cannot express.
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% with per-property descriptions, so the baseline is 3. The description earns above that by grouping the ten properties into selector families and surfacing a cross-parameter rule the oneOf encodes only structurally: store-native selectors require merchant context, while Nobi id/variantId/productId do not. It also clarifies accepted ID formats (UUID vs Base62, numeric vs GID) that the schema states only in fragments.
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?
Opens with a precise verb+resource+scope: 'Reads exact product or variant details from Shop Nobi's public catalog.' The word 'exact' plus the enumerated selector set cleanly separates it from the sibling search_products, and the reader knows immediately this is a lookup, not a discovery, tool.
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 explicit routing rules: which selector to send for a Nobi variant vs parent product vs store-native ID vs SKU vs URL, plus the prerequisite that Shopify IDs must be paired with storeDomain or merchantId. It also states exclusions ('Ambiguous or conflicting selectors are refused', 'Source IDs and SKUs are never resolved globally'), which is the when-not half that most descriptions omit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches online stores' product catalogs for shopping requests such as product types, brands, budgets and gift ideas. Each result describes a selected variant, with its Nobi variant ID (id and variantId), parent productId, merchantId, source IDs, name, store, catalog price and currency, stock status, image and link. People buy from the store. When linkLabel is set, such as "We may earn a commission", show it beside that product's link. For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one.
| 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". | |
| visitorId | No | For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one. |
| Name | Required | Description |
|---|---|---|
| products | Yes | |
| visitorId | No | For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavioral context beyond them: results represent a selected variant, purchase happens at the store rather than through the tool, and linkLabel must be surfaced beside the link when present. It does not cover result count behavior or pagination beyond the schema's limit.
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, then the result shape, then the display rule and the visitorId protocol. The enumerated result fields are somewhat redundant given an output schema exists, but each sentence otherwise carries operational meaning.
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 an output schema present, the description need not explain return values, yet it still clarifies the variant-level granularity and the commission-disclosure requirement. The remaining gap is the absence of a routing hint versus the five sibling tools.
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% and the description largely restates the visitorId instruction already in the schema. The one addition is that visitorId originates from a prior result and must be passed unchanged, but it does not clarify `limit` or query composition beyond the schema examples.
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 ('searches online stores' product catalogs') and enumerates the request shapes it handles (product types, brands, budgets, gift ideas). It does not explicitly say how it differs from siblings like compare_products or get_product_details, so it falls short of a 5.
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 the use case (shopping requests described in plain words) and gives a rule for the follow-up visitorId flow, but never names an alternative or states when not to use this tool. An agent must infer that get_product_details or compare_products belong to a later stage.
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.
about_mcp5 fields changedOutput schema / properties / documentationRemoved value: -{
- "type": "string"
-}Output schema / properties / madeByRemoved value: -{
- "type": "string"
-}Output schema / properties / pricingRemoved value: -{
- "type": "string"
-}Output schema / properties / productsRemoved value: -{
- "items": {
- "properties": {
- "name": {
- "type": "string"
- },
- "whatItDoes": {
- "type": "string"
- }
- },
- "type": "object"
- },
- "type": "array"
-}Output schema / properties / whatNobiIsRemoved value: -{
- "type": "string"
-}about_mcpcheck_price_and_availability2 fields changedInput schema / properties / visitorIdAdded value: +{
+ "description": "For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one.",
+ "format": "uuid",
+ "maxLength": 36,
+ "minLength": 1,
+ "type": "string"
+}Output schema / properties / visitorIdAdded value: +{
+ "description": "For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one.",
+ "format": "uuid",
+ "maxLength": 36,
+ "minLength": 1,
+ "type": "string"
+}compare_products2 fields changedInput schema / properties / visitorIdAdded value: +{
+ "description": "For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one.",
+ "format": "uuid",
+ "maxLength": 36,
+ "minLength": 1,
+ "type": "string"
+}Output schema / properties / visitorIdAdded value: +{
+ "description": "For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one.",
+ "format": "uuid",
+ "maxLength": 36,
+ "minLength": 1,
+ "type": "string"
+}find_alternatives2 fields changedInput schema / properties / visitorIdAdded value: +{
+ "description": "For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one.",
+ "format": "uuid",
+ "maxLength": 36,
+ "minLength": 1,
+ "type": "string"
+}Output schema / properties / visitorIdAdded value: +{
+ "description": "For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one.",
+ "format": "uuid",
+ "maxLength": 36,
+ "minLength": 1,
+ "type": "string"
+}find_shop_nobi_page2 fields changedInput schema / properties / visitorIdAdded value: +{
+ "description": "For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one.",
+ "format": "uuid",
+ "maxLength": 36,
+ "minLength": 1,
+ "type": "string"
+}Output schema / properties / visitorIdAdded value: +{
+ "description": "For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one.",
+ "format": "uuid",
+ "maxLength": 36,
+ "minLength": 1,
+ "type": "string"
+}get_product_details2 fields changedInput schema / properties / visitorIdAdded value: +{
+ "description": "For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one.",
+ "format": "uuid",
+ "maxLength": 36,
+ "minLength": 1,
+ "type": "string"
+}Output schema / properties / visitorIdAdded value: +{
+ "description": "For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one.",
+ "format": "uuid",
+ "maxLength": 36,
+ "minLength": 1,
+ "type": "string"
+}search_products2 fields changedInput schema / properties / visitorIdAdded value: +{
+ "description": "For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one.",
+ "format": "uuid",
+ "maxLength": 36,
+ "minLength": 1,
+ "type": "string"
+}Output schema / properties / visitorIdAdded value: +{
+ "description": "For follow-up calls in this conversation, send the visitorId returned by a previous result unchanged. Omit it on the first call; do not invent one.",
+ "format": "uuid",
+ "maxLength": 36,
+ "minLength": 1,
+ "type": "string"
+}check_price_and_availability2 fields changedInput schema / properties / ids / descriptionPrevious value: -"The ids of the products, each from a product search result."New value: +"Nobi variant ids, each from a product search result."Input schema / properties / ids / items / descriptionPrevious value: -"The ids of the products, each from a product search result."New value: +"Nobi variant ids, each from a product search result."compare_products2 fields changedInput schema / properties / ids / descriptionPrevious value: -"The ids of the products, each from a product search result."New value: +"Nobi variant ids, each from a product search result."Input schema / properties / ids / items / descriptionPrevious value: -"The ids of the products, each from a product search result."New value: +"Nobi variant ids, each from a product search result."find_alternatives8 fields changedInput schema / properties / id / descriptionPrevious value: -"The id of the product, from a product search result."New value: +"The Nobi variant id from a search result; the same identity is named variantId."Output schema / properties / products / items / properties / id / descriptionAdded value: +"Legacy alias for the selected Nobi variantId; null for parent details. productId identifies the parent."Output schema / properties / products / items / properties / merchantIdAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / products / items / properties / productIdAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / products / items / properties / sourceProductIdAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / products / items / properties / sourceVariantIdAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / products / items / properties / variantIdAdded value: +{
+ "type": "string"
+}Output schema / properties / products / items / requiredPrevious value: -[
- "id",
- "name",
- "store",
- "price",
- "currency",
- "inStock",
- "imageUrl",
- "url",
- "paidLink",
- "linkLabel"
-]New value: +[
+ "id",
+ "name",
+ "store",
+ "price",
+ "currency",
+ "inStock",
+ "imageUrl",
+ "url",
+ "paidLink",
+ "linkLabel",
+ "productId",
+ "variantId",
+ "merchantId",
+ "sourceProductId",
+ "sourceVariantId"
+]get_product_details26 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / oneOfAdded value: +[
+ {
+ "not": {
+ "anyOf": [
+ {
+ "required": [
+ "variantId"
+ ]
+ },
+ {
+ "required": [
+ "productId"
+ ]
+ },
+ {
+ "required": [
+ "sourceVariantId"
+ ]
+ },
+ {
+ "required": [
+ "sourceProductId"
+ ]
+ },
+ {
+ "required": [
+ "sku"
+ ]
+ },
+ {
+ "required": [
+ "productUrl"
+ ]
+ }
+ ]
+ },
+ "required": [
+ "id"
+ ]
+ },
+ {
+ "not": {
+ "anyOf": [
+ {
+ "required": [
+ "id"
+ ]
+ },
+ {
+ "required": [
+ "productId"
+ ]
+ },
+ {
+ "required": [
+ "sourceVariantId"
+ ]
+ },
+ {
+ "required": [
+ "sourceProductId"
+ ]
+ },
+ {
+ "required": [
+ "sku"
+ ]
+ },
+ {
+ "required": [
+ "productUrl"
+ ]
+ }
+ ]
+ },
+ "required": [
+ "variantId"
+ ]
+ },
+ {
+ "not": {
+ "anyOf": [
+ {
+ "required": [
+ "id"
+ ]
+ },
+ {
+ "required": [
+ "variantId"
+ ]
+ },
+ {
+ "required": [
+ "sourceVariantId"
+ ]
+ },
+ {
+ "required": [
+ "sourceProductId"
+ ]
+ },
+ {
+ "required": [
+ "sku"
+ ]
+ },
+ {
+ "required": [
+ "productUrl"
+ ]
+ }
+ ]
+ },
+ "required": [
+ "productId"
+ ]
+ },
+ {
+ "anyOf": [
+ {
+ "required": [
+ "merchantId"
+ ]
+ },
+ {
+ "required": [
+ "storeDomain"
+ ]
+ }
+ ],
+ "not": {
+ "anyOf": [
+ {
+ "required": [
+ "id"
+ ]
+ },
+ {
+ "required": [
+ "variantId"
+ ]
+ },
+ {
+ "required": [
+ "productId"
+ ]
+ },
+ {
+ "required": [
+ "sourceProductId"
+ ]
+ },
+ {
+ "required": [
+ "sku"
+ ]
+ },
+ {
+ "required": [
+ "productUrl"
+ ]
+ }
+ ]
+ },
+ "required": [
+ "sourceVariantId"
+ ]
+ },
+ {
+ "anyOf": [
+ {
+ "required": [
+ "merchantId"
+ ]
+ },
+ {
+ "required": [
+ "storeDomain"
+ ]
+ }
+ ],
+ "not": {
+ "anyOf": [
+ {
+ "required": [
+ "id"
+ ]
+ },
+ {
+ "required": [
+ "variantId"
+ ]
+ },
+ {
+ "required": [
+ "productId"
+ ]
+ },
+ {
+ "required": [
+ "sourceVariantId"
+ ]
+ },
+ {
+ "required": [
+ "sku"
+ ]
+ },
+ {
+ "required": [
+ "productUrl"
+ ]
+ }
+ ]
+ },
+ "required": [
+ "sourceProductId"
+ ]
+ },
+ {
+ "anyOf": [
+ {
+ "required": [
+ "merchantId"
+ ]
+ },
+ {
+ "required": [
+ "storeDomain"
+ ]
+ }
+ ],
+ "not": {
+ "anyOf": [
+ {
+ "required": [
+ "id"
+ ]
+ },
+ {
+ "required": [
+ "variantId"
+ ]
+ },
+ {
+ "required": [
+ "productId"
+ ]
+ },
+ {
+ "required": [
+ "sourceVariantId"
+ ]
+ },
+ {
+ "required": [
+ "sourceProductId"
+ ]
+ },
+ {
+ "required": [
+ "productUrl"
+ ]
+ }
+ ]
+ },
+ "required": [
+ "sku"
+ ]
+ },
+ {
+ "not": {
+ "anyOf": [
+ {
+ "required": [
+ "id"
+ ]
+ },
+ {
+ "required": [
+ "variantId"
+ ]
+ },
+ {
+ "required": [
+ "productId"
+ ]
+ },
+ {
+ "required": [
+ "sourceVariantId"
+ ]
+ },
+ {
+ "required": [
+ "sourceProductId"
+ ]
+ },
+ {
+ "required": [
+ "sku"
+ ]
+ }
+ ]
+ },
+ "required": [
+ "productUrl"
+ ]
+ }
+]Input schema / properties / id / descriptionPrevious value: -"The id of the product, from a product search result."New value: +"Legacy alias for variantId, returned as id by search."Input schema / properties / id / maxLengthPrevious value: -22New value: +36Input schema / properties / id / minLengthPrevious value: -22New value: +1Input schema / properties / merchantIdAdded value: +{
+ "description": "The store's Nobi merchant UUID, returned by search.",
+ "maxLength": 36,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / productIdAdded value: +{
+ "description": "Nobi parent product UUID or Base62 product ID; selects no variant.",
+ "maxLength": 36,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / productUrlAdded value: +{
+ "description": "An exact HTTPS catalog product URL, optionally with its numeric Shopify variant selector. Never fetched.",
+ "maxLength": 2048,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / skuAdded value: +{
+ "description": "Literal exact SKU within one store. Duplicate matches are refused. Requires merchant context.",
+ "maxLength": 2048,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / sourceProductIdAdded value: +{
+ "description": "The store's parent product ID, such as a Shopify numeric product ID or Product GID. Pair it with storeDomain (the selling merchant's hostname) or a known Nobi merchantId.",
+ "maxLength": 2048,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / sourceVariantIdAdded value: +{
+ "description": "The store's variant ID, such as a Shopify numeric variant ID or ProductVariant GID. Pair it with storeDomain (the selling merchant's hostname) or a known Nobi merchantId.",
+ "maxLength": 2048,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / storeDomainAdded value: +{
+ "description": "The store's exact hostname, such as example.com, or its HTTPS address.",
+ "maxLength": 2048,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / variantIdAdded value: +{
+ "description": "Nobi variant UUID or Base62 variant ID.",
+ "maxLength": 36,
+ "minLength": 1,
+ "type": "string"
+}Input schema / requiredRemoved value: -[
- "id"
-]Output schema / properties / product / properties / currency / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / product / properties / id / descriptionAdded value: +"Legacy alias for the selected Nobi variantId; null for parent details. productId identifies the parent."Output schema / properties / product / properties / id / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / product / properties / inStock / typePrevious value: -"boolean"New value: +[
+ "boolean",
+ "null"
+]Output schema / properties / product / properties / merchantIdAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / product / properties / productIdAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / product / properties / sourceProductIdAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / product / properties / sourceVariantIdAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / product / properties / variantIdAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / product / properties / variants / items / properties / sourceVariantIdAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / product / properties / variants / items / requiredPrevious value: -[
- "id",
- "name",
- "price",
- "currency",
- "inStock",
- "inventoryQuantity",
- "specs"
-]New value: +[
+ "id",
+ "name",
+ "price",
+ "currency",
+ "inStock",
+ "inventoryQuantity",
+ "specs",
+ "sourceVariantId"
+]Output schema / properties / product / requiredPrevious value: -[
- "id",
- "name",
- "store",
- "brand",
- "description",
- "categoryPath",
- "price",
- "currency",
- "compareAtPrice",
- "inStock",
- "inventoryQuantity",
- "imageUrls",
- "specs",
- "variants"
-]New value: +[
+ "id",
+ "name",
+ "store",
+ "brand",
+ "description",
+ "categoryPath",
+ "price",
+ "currency",
+ "compareAtPrice",
+ "inStock",
+ "inventoryQuantity",
+ "imageUrls",
+ "specs",
+ "variants",
+ "productId",
+ "variantId",
+ "merchantId",
+ "sourceProductId",
+ "sourceVariantId"
+]search_products7 fields changedOutput schema / properties / products / items / properties / id / descriptionAdded value: +"Legacy alias for the selected Nobi variantId; null for parent details. productId identifies the parent."Output schema / properties / products / items / properties / merchantIdAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / products / items / properties / productIdAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / products / items / properties / sourceProductIdAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / products / items / properties / sourceVariantIdAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / products / items / properties / variantIdAdded value: +{
+ "type": "string"
+}Output schema / properties / products / items / requiredPrevious value: -[
- "id",
- "name",
- "store",
- "price",
- "currency",
- "inStock",
- "imageUrl",
- "url",
- "paidLink",
- "linkLabel"
-]New value: +[
+ "id",
+ "name",
+ "store",
+ "price",
+ "currency",
+ "inStock",
+ "imageUrl",
+ "url",
+ "paidLink",
+ "linkLabel",
+ "productId",
+ "variantId",
+ "merchantId",
+ "sourceProductId",
+ "sourceVariantId"
+]check_price_and_availabilitycompare_productsfind_alternativesget_product_detailssearch_products2 fields changedOutput schema / properties / products / items / properties / idAdded value: +{
+ "type": "string"
+}Output schema / properties / products / items / requiredPrevious value: -[
- "name",
- "store",
- "price",
- "currency",
- "inStock",
- "imageUrl",
- "url",
- "paidLink",
- "linkLabel"
-]New value: +[
+ "id",
+ "name",
+ "store",
+ "price",
+ "currency",
+ "inStock",
+ "imageUrl",
+ "url",
+ "paidLink",
+ "linkLabel"
+]find_shop_nobi_pagesearch_productsSearch products across independent online shops. Read-only; links go to each shop's own page.
Search 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.
Add one secure layer between your agents and this server.
