Channel3 Product Search

Get Products

get_products

Read-onlyIdempotent

Get 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.

Input Schema

TableJSON Schema

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.

Output Schema

TableJSON Schema

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.

TDQS

A4.5/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All Channel3 Product Search tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0

Disambiguation3/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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Resources

Need Help?