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.
Most tools are distinct, but browse_products and search_products both return product lists, and get_details and get_products both fetch product data. The descriptions clarify some differences (e.g., get_products supports multiple IDs and full data, get_details focuses on live offers), but the overlap creates moderate ambiguity.
All tool names are lowercase with underscores and generally follow a verb_noun pattern (browse_products, search_products, get_details, etc.). The minor exception is get_similar, where 'similar' is an adjective rather than a noun, but this is still understandable and consistent with the get_ prefix convention.
With 6 tools, the server is well-scoped for a product search API. Each tool covers a distinct aspect: searching, browsing, fetching details, comparing, viewing price history, and finding similar products. The count is neither sparse nor bloated.
The tool set provides comprehensive coverage for product search and retrieval: search, browse, details, price history, and similar items. There are no obvious dead ends; core workflows like search-to-details and search-to-compare are fully supported. The only minor gap might be a dedicated review tool, but that's beyond the apparent purpose.
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". | |
| 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 readOnlyHint, openWorldHint, and idempotentHint, covering safety and consistency. The description adds minimal behavioral context—'page through' implies pagination, and 'storefront UI' suggests customer-facing use—but doesn't disclose additional traits like result limits or error behavior. This is acceptable given 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?
The description is a single concise sentence that directly states the tool's function without filler or redundancy. 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?
Given the tool's read-only nature, the presence of an output schema, and reasonable annotations, the description is mostly complete. The main gap is the lack of differentiation from search_products, but the phrase 'storefront UI' helps. Overall, it provides enough context for an agent to understand basic usage.
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 60%, with query, image_url, and page_token described in the schema. The tool description itself adds no parameter-level detail beyond implying 'page through' relates to page_token. It doesn't compensate for undocumented parameters (limit, thread_id), and no meaning is added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Search and page through products') with a clear target resource ('products') and context ('for the storefront UI'). This distinguishes it from siblings like get_products (likely retrieval by ID) and search_products (possibly broader search), though it doesn't explicitly name the alternatives.
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 phrase 'for the storefront UI' provides some context on when to use this tool, and the query parameter examples in the schema hint at its intended use for natural-language product queries. However, the description itself gives no explicit guidance on choosing this tool over siblings like search_products or get_similar, nor any exclusions.
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 |
|---|---|---|---|
| thread_id | No | ||
| product_id | Yes | Canonical product ID. |
| Name | Required | Description |
|---|---|---|
| product | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and variability. The description adds 'live offers' which aligns with openWorldHint, but does not disclose additional behavioral traits such as rate limits or return format nuances. It adds some context but is not rich.
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 conveys the core purpose without wasted words. It is highly concise and well-structured.
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 low complexity, a simple tool like this, the description is fairly adequate. The output schema presumably covers return values, and annotations cover safety. However, it is incomplete regarding thread_id semantics and lacks explicit guidance on when to use it over siblings.
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 50% (product_id described, thread_id not). The description does not mention either parameter, so it fails to compensate for the undocumented thread_id. It adds no meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Fetch') and resource ('a product'), and adds a distinguishing attribute 'with live offers.' This distinguishes it from siblings like 'get_products' (plural) and 'get_similar'.
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 phrase 'for the storefront UI' implies a usage context, but there are no explicit statements about when to use this tool versus alternatives, nor any exclusions. Usage guidance is only implied, not clearly stated.
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 |
|---|---|---|---|
| thread_id | No | ||
| product_id | Yes | Canonical product ID. |
| Name | Required | Description |
|---|---|---|
| history | Yes | |
| statistics | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly, idempotent, and openWorld behavior, so the description does not need to repeat these. It adds the specific 30-day window context, which is useful beyond the annotations. However, it does not disclose any other behavioral traits such as response format, rate limits, or whether historical data is aggregated. This is consistent with annotations, but the added value is limited.
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, concise sentence that front-loads the key information (fetch action, time window, resource, context). It contains no unnecessary words or repetition. Every clause earns its place, making it highly efficient.
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 presence of an output schema, annotations, and a clear description, the tool definition is mostly complete. The description adequately explains the core functionality and scope. However, it lacks explicit usage guidance for alternative tools, which prevents a perfect score. Still, the definition is sufficient for an agent to understand what the tool does and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers 50% of parameters (product_id is described), but thread_id is left undocumented and the description does not provide any clarification. The description only says 'for a product', which adds no additional meaning beyond the schema's product_id description. With low-to-medium schema coverage, the description fails to compensate for the missing parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches 30-day price history for a product, with a specific scope ('for the storefront UI'). This distinguishes it from sibling tools like search_products or get_details, which cover different functions. The verb 'Fetch' and resource 'price history' make 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 implies usage when price history data is needed, but it does not explicitly compare against alternatives or provide exclusions. There is no mention of when not to use this tool or which sibling tool might be more appropriate in other scenarios. The context is clear but the guidance is implicit rather than explicit.
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?
The description discloses a critical behavioral trait: the returned thread_id must be included unchanged in all subsequent Channel3 calls, even for unrelated searches. This goes well beyond the annotations (readOnly, openWorld, idempotent) and prevents a likely usage error. It also notes that results are returned in the storefront UI, adding useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the main purpose, the second clarifies the prerequisite and output, and the final sentence delivers the crucial thread_id instruction. Every sentence is necessary and worth its place, with no wasted words.
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 annotations declaring read-only, open-world, and idempotent behavior, and an output schema explaining return values, the description only needs to fill the gaps. It does so by explaining the thread_id requirement, the ability to pass multiple IDs, and the relationship to search_products. This makes the tool fully actionable for an agent.
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 thorough descriptions for both parameters, including the thread_id lifecycle and the product_ids format. The description reinforces that multiple IDs can be passed for comparison, but strictly speaking it adds little new semantic meaning beyond what the schema already covers, so a baseline of 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's function: getting full product data (offers, description, attributes, images) by product ID or retailer URL. It also differentiates from the search workflow by explicitly instructing 'Use search_products to find products,' making the tool's role in the overall process 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?
It provides clear context on when to use the tool: after a search, for fetching full product details, and for comparing multiple products in one call. However, it does not explicitly mention alternatives like get_details or get_similar, nor does it give 'when-not-to-use' guidance, so it falls short of a full 5.
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 | ||
| 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 declare readOnlyHint, openWorldHint, and idempotentHint, which cover the safety profile. The description adds only the storefront UI context, not additional behavioral details such as algorithmic notion of similarity or side effects. This is acceptable but not enriching beyond 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?
The description is a single, front-loaded sentence with no waste. It conveys the core purpose efficiently and is appropriately sized for a simple tool.
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?
The output schema exists, so return values need not be described. However, the description lacks guidance on parameter usage (limit, thread_id) and does not clarify how 'similar' is determined. For a simple tool with annotations, it is minimally viable but not fully 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?
Schema description coverage is only 33% (product_id has a description). The tool description adds no meaning for 'limit' or 'thread_id' beyond the schema's type constraints. With low coverage, the description should compensate but does not, leaving parameter semantics incomplete.
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') with a clear resource ('products similar to a given product'). It differentiates from siblings like search_products (search by query) and get_products (list products) by specifying the similarity use case.
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 phrase 'for the storefront UI' provides some context, but there is no explicit guidance on when to use this tool versus alternatives like search_products or get_products. Usage is implied by the 'similar' nature but not stated as a recommendation or exclusion.
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?
The description goes well beyond the readOnly/openWorld/idempotent annotations by disclosing the return limit ('up to 8 product cards'), the presence of structured product data, and the critical mandatory thread_id propagation rule. This is useful behavioral context that annotations alone do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, front-loading the core purpose and batching instruction first. Every sentence carries needed guidance, especially the thread_id rule, with no fluff or 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?
Given the rich annotations, complete parameter schema, and output schema, the description fully covers necessary context: batching behavior, expected result size, and the mandatory thread_id requirement. There are no obvious gaps that would impede correct invocation.
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 mostly restates the query and thread_id guidance already present in the schema. It doesn't add new parameter-level semantics beyond what the schema provides, so the baseline score of 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?
The description clearly states 'Search 100M+ products across thousands of retailers for one product type', giving a specific verb, resource, and scope. It also differentiates from sibling tools like browse_products and get_products by emphasizing query-based search for a single product type and by providing batch-call guidance.
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 provides explicit instructions: 'Call once for each distinct product type, and send independent calls together' and 'Put relevant constraints in query.' However, it does not explicitly mention when to prefer this tool over siblings or when not to use it, so it lacks the 'when-not/alternatives' element needed for 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!
