Product search and price comparison for AI agents. Search 100M+ products across thousands of retailers by text or image, compare live offers and prices, and turn any merchant URL into structured product data. No API key required to start; add one for unlimited use and affiliate commission.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.9/5 across 6 of 6 tools scored. Lowest: 3.2/5.
The two search-related tools (browse_products, search_products) wrap in each other, and get_details/get_products both return product offer/detail data. The descriptions help mostly separate intended use ('browse' implies pagination, 'get_products' supports multiple IDs and comparison), but some boundary decisions remain.
Most tools consistently follow verb_noun and snake_case (browse_products, get_products, search_products, get_price_history). get_details and get_similar are minor deviations because their object nouns are vague or adjectival, but nothing is chaotic.
Six tools is a well-scoped number for product search: discovery, browsing, details, price history, comparison support, and similar products are covered. No tool feels like filler.
The tool covers the main product-search workflow end to end: query, browse, detail, compare, price history, and recommendations. There are small potential gaps like explicit compare or pagination controls, but agents can work around them.
browse_productsBrowse ProductsBSearch and page through products for the storefront UI.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | One product type and its constraints in natural language (brand, color, material, size, price, gender). Good: "red leather jacket under $200"; "leather golf glove under $40". Bad: "gift ideas for dad"; "cool sneakers"; "golf glove or rangefinder". | |
| device_id | No | ||
| image_url | No | Public image URL for visual search. Combine with `query` for text + image. | |
| thread_id | No | ||
| page_token | No | Token from a previous response's next_page_token. |
| Name | Required | Description |
|---|---|---|
| products | Yes | |
| next_page_token | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior, so the description does not need to repeat safety. It adds the pagination trait, but does not describe any other behavioral nuances like token expiry, pagination boundaries, or what the storefront UI search really reflects.
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 one efficient sentence with no wasted words. It is front-loaded and provides the core purpose immediately, though it lacks some behavioral and usage detail.
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 output schema and annotations, this is minimally callable for a list-and-pagination task. But with 6 parameters and 5 sibling tools, the description leaves ambiguity around product classification and parameter relationships.
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?
Six parameters exist but the description does not mention any of them. The schema covers query, image_url, and page_token with descriptions, but limit and device_id have none, so the tool description offers no extra parameter meaning. With only 50% schema coverage, some compensation was needed.
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 action (search and page through) on a clear resource (products) for a storefront UI context. It does not explicitly distinguish itself from sibling tools like search_products or get_products, so it misses the extra clarity needed for 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 storefront UI context gives some signal about where the tool belongs, so usage is vaguely implied. However, there is no guidance on when to choose this over search_products or get_products, nor any mention of exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_detailsGet Product DetailsAFetch a product with live offers, for the storefront UI.
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | No | ||
| thread_id | No | ||
| product_id | Yes | Canonical product ID. | |
| selected_options | No | Variant configuration as `{ optionName: label }` for re-resolving offers. |
| Name | Required | Description |
|---|---|---|
| product | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the safety profile, and “live offers” adds a small behavioral hint about data freshness (it is not just a static product lookup). The description does not, however, explain how “live” behaves — e.g., whether offers are re-resolved per request, cached, or require selected options.
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?
An single sentence with the core purpose, the behavioral_distinguisher (“live offers”), and the intended context (storefront UI) — all without roundabout explanation or redundant restatement of the name or title. Every word 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 product fetch, the description covers the basic task and leaves no missing required inputs (product_id is listed as required). However, there is no output schema and no description of what “live offers” means, and two params (device_id, thread_id) remain opaque, so an agent gets an useful but not debt, complete, complete target.
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?
product_id and selected_options are already described in the schema, so roughly half of the parameters have provenance. The description's storefront-UI framing gives only weak hints about device_id and thread_id (frontrount route context), but does not really compensate for the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (“fetch”) and resource (“product” with a distinctive “live offers” modifier, so an agent clearly knows what the tool returns. It does not name any sibling tools, so full differentiation from similar fetch/list tools is not explicit.
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?
“For the storefront UI” implies the intended context: use when serving the customer-facing product page. However, there is no explicit when-not-to-use condition, no prerequisite mention, and no alternative tool is named, so routing falls to agent inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_price_historyGet Price HistoryAFetch 30-day price history for a product, for the storefront UI.
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | No | ||
| thread_id | No | ||
| product_id | Yes | Canonical product ID. | |
| selected_options | No | Variant configuration as `{ optionName: label }` for re-resolving offers. |
| Name | Required | Description |
|---|---|---|
| history | Yes | |
| statistics | Yes | |
| canonical_product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already communicate that this is a read-only, idempotent, non-destructive operation. The description adds the useful '30-day' scoping restriction and 'storefront UI' context, but goes no further into behavior such as how response handles missing data or how selected_options are resolved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. The core action and scoping are placed at the beginning, and the storefront context is appended without repetition.
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, annotations, and only one required parameter, this description is largely sufficient for an agent to call the tool correctly. It could better for-resee sibling ambiguity and say what makes the storefront UI price scope special, but nothing critical gets stuck.
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 only 50%, so the description must compensate. It maps only loosely to product_id by saying 'for a product', and it gives no meaning for device_id, thread_id, or selected_options. The schema already describes product_id as canonical and selected_options as variant configuration, so the description adds little parameter-level value.
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 verb ('Fetch'), a concrete resource ('30-day price history for a product'), and the context ('storefront UI'). This clearly distinguishes the tool from siblings focused on browsing, searching, details, and similar products.
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 provides clear context: use it when the request is for the 30-day price history of a product in the storefront UI. It does not explicitly name alternatives or say when not to use it, but the intended use case is still apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_productsGet ProductsAGet full product data (offers, description, attributes, images) by product ID from a search result, or by retailer URL. Pass several IDs in one call to compare.
Use search_products to find products. Returns details in the storefront UI. The result includes a thread_id. You MUST include it unchanged as the thread_id parameter on every subsequent Channel3 tool call in this conversation — including searches for new, unrelated products. Never omit it once you have one.
| Name | Required | Description | Default |
|---|---|---|---|
| thread_id | No | Conversation thread ID. Omit ONLY on the very first Channel3 call of a conversation. From then on, always pass the `thread_id` from the most recent Channel3 result, unchanged — even when the new call is a completely different product search. | |
| product_ids | Yes | Products to fetch in parallel. |
| Name | Required | Description |
|---|---|---|
| as_of | Yes | ISO timestamp of when this result was produced; prices are live as of this moment. |
| products | Yes | |
| thread_id | Yes | Conversation thread ID. Pass it back unchanged as `thread_id` on every follow-up call in this conversation. |
| session_id | No | PostHog MCP session ID for analytics correlation. |
| unresolved | No | |
| server_origin | No | Origin of this MCP server; the storefront UI posts analytics events here. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and idempotent, but the description adds a crucial behavioral constraint: the `thread_id` from the result must be passed unchanged on every subsequent Channel3 call. It also notes that results are returned in the storefront UI, providing context beyond annotations. 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?
Three sentences efficiently convey purpose, workflow, and a critical state requirement. The description is front-loaded with the core functionality, and the thread_id instructions are necessary and clearly stated without unnecessary 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?
For a tool with only two parameters, full schema coverage, and annotations, the description is comprehensive. It covers the tool's purpose, usage guidance, and the vital thread_id contract. The presence of an output schema means return values need not be elaborated, making the description complete.
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 input schema provides full descriptions for both parameters with 100% coverage. The description reinforces that product_ids can be a product ID or URL and supports batching, but adds no substantive new meaning beyond the schema, so the baseline 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?
The description clearly states the tool fetches full product data (offers, description, attributes, images) by product ID or retailer URL. It also distinguishes it from search_products by explicitly pointing users to that tool for finding products, making the purpose 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?
The description explicitly instructs to use search_products to find products, establishing a clear workflow. It also advises passing multiple IDs for comparison. However, it does not address when to use or avoid other sibling tools like get_details or browse_products, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_similarGet Similar ProductsAFind products similar to a given product, for the storefront UI.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| device_id | No | ||
| thread_id | No | ||
| product_id | Yes | Canonical product ID to find similar products for. |
| Name | Required | Description |
|---|---|---|
| products | Yes | |
| next_page_token | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive. The description adds the storefront UI context but does not disclose how similar products are determined, whether results are ordered, or how device_id and thread_id affect behavior. It does not contradict annotations, but the extra behavior context is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the action, target, and context. There is no wasteful or repetitive content.
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?
Required invocation with product_id is documented and an output schema exists, so the definition is usable. However, optional parameters lack meaning, and there’s no guidance about choosing between this tool and similar sibling tools. Complete enough for basic use but with real gaps.
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 only 25%, and the description does not compensate. product_id is the only parameter with semantic explanation in schema; limit, device_id, and thread_id receive no meaningful description in either the schema or the tool description. A real semantic gap remains for those optional parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Find' and names the resource, 'products similar to a given product,' along with the storefront UI context. This clearly distinguishes it from siblings like browse_products and search_products, which are about browsing or searching rather than similarity recommendations.
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 statement 'for the storefront UI' gives a context, but it does not explicitly say when to prefer this tool over get_products or search_products, nor does it give any when-not-to-use guidance. The usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_productsSearch ProductsASearch 100M+ products across thousands of retailers for one product type. Call once for each distinct product type, and send independent calls together. Put relevant constraints in query.
Returns up to 8 product cards plus structured product data. The result includes a thread_id. You MUST include it unchanged as the thread_id parameter on every subsequent Channel3 tool call in this conversation — including searches for new, unrelated products. Never omit it once you have one.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | One product type and its constraints in natural language (brand, color, material, size, price, gender). Good: "red leather jacket under $200"; "leather golf glove under $40". Bad: "gift ideas for dad"; "cool sneakers"; "golf glove or rangefinder". | |
| image_url | No | Public image URL for visual search. Combine with `query` for text + image. | |
| thread_id | No | Conversation thread ID. Omit ONLY on the very first Channel3 call of a conversation. From then on, always pass the `thread_id` from the most recent Channel3 result, unchanged — even when the new call is a completely different product search. |
| Name | Required | Description |
|---|---|---|
| seq | No | |
| as_of | Yes | ISO timestamp of when this result was produced; prices are live as of this moment. |
| query | No | The text query this result answers. |
| products | Yes | |
| image_url | No | The image URL this result answers. |
| thread_id | Yes | Conversation thread ID. Pass it back unchanged as `thread_id` on every follow-up call in this conversation. |
| session_id | No | PostHog MCP session ID for analytics correlation. |
| server_origin | No | Origin of this MCP server; the storefront UI posts analytics events here. |
| next_page_token | Yes | Opaque pagination token used by the storefront UI; not usable via this tool. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds critical behavioral context: it mentions that results include a thread_id, and the agent MUST include it unchanged on every subsequent Channel3 call, even for unrelated searches. This is a non-obvious stateful behavior beyond the annotations, and it is clearly disclosed.
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 concise and well-structured: it opens with the primary purpose, then gives usage batching advice, notes the output format, and finishes with the mandatory thread_id rule. Every sentence is information-dense and contributes to correct invocation; there is no redundancy or 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 an output schema present to handle return-value details, the description covers all essential operational context: scope of search, call batching, constraint placement, and the persistent thread_id requirement. It is fully sufficient for an agent to use the tool correctly, including across multiple calls.
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 input schema already provides comprehensive descriptions for all three parameters (100% coverage), so the description does not need to add much. It only reinforces that constraints go into `query` and that thread_id is required after the first call. This meets the baseline for high schema coverage but adds no new parameter-level semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search 100M+ products across thousands of retailers for one product type.' It specifies the resource (products), the action (search), and the scope (one product type), and distinguishes from sibling tools by emphasizing single-type search. The return of 'up to 8 product cards plus structured product data' further clarifies the purpose.
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 provides explicit usage instructions: 'Call once for each distinct product type, and send independent calls together' and 'Put relevant constraints in `query`.' It also mandates the thread_id propagation. However, it does not explicitly name alternative tools or describe when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
