Shop Nobi

Find alternatives to a product

find_alternatives

Read-onlyIdempotent

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.

Input Schema

Name	Required	Description
`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.

Output Schema

Name	Required	Description	Default
`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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 27, 2026

addedInput schema / properties / visitorId

Added 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"
+}

addedOutput schema / properties / visitorId

Added 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"
+}

Changed8 schema fields changedOct 27, 2026

changedInput schema / properties / id / description

Previous 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."

addedOutput schema / properties / products / items / properties / id / description

Added value: +"Legacy alias for the selected Nobi variantId; null for parent details. productId identifies the parent."

addedOutput schema / properties / products / items / properties / merchantId
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
addedOutput schema / properties / products / items / properties / productId
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
addedOutput schema / properties / products / items / properties / sourceProductId
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
addedOutput schema / properties / products / items / properties / sourceVariantId
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
addedOutput schema / properties / products / items / properties / variantId
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / properties / products / items / required

Previous 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"
+]

AddedOct 26, 2026

TDQS

A4.2/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All Shop Nobi tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?