Jithox Commerce Preflight

Search retail products

search_retail_products

Read-only

Search the queried retail source by free text or EAN. Returns CANDIDATE public records with deterministic match kinds and visible ambiguity: 'exact_public_record' / 'possible_match' / 'multiple_matches' / 'no_match_in_queried_source' — a no-match is never 'not sold', only 'not in the source we queried'. A provider without a search surface → 'unsupported'; outage → 'unavailable'; unconfigured source → 'not_configured' (costs nothing). Answers come from the queried source at the stated retrieval time — a UCP or ACP merchant, a partner catalog source, or a clearly-labelled synthetic fixture in dev/test; provenance.sourceAuthority names which, and every answer carries the markets that source declares. Preflight evidence only — this server never places, modifies or cancels an order and never touches a payment; the merchant stays merchant of record.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`ean`	No	EAN/GTIN for an exact lookup.
`query`	No	Free-text search (title/brand).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes
`billing`	Yes
`product`	Yes
`receipt`	Yes
`decision`	Yes
`retryable`	Yes
`capability`	Yes
`provenance`	Yes
`generatedAt`	Yes
`limitations`	Yes
`schemaVersion`	Yes
`receiptEnvelope`	No
`decisionCategory`	Yes

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description greatly exceeds the annotations by detailing match kinds, special statuses (unsupported/unavailable/not_configured), provenance via sourceAuthority, market declarations, retrieval time, and a clear guarantee that no orders or payments are ever placed. This adds significant behavioral context beyond readOnlyHint and openWorldHint.

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?

The description is long but each sentence contributes substantive information about edge cases and behaviors. It is front-loaded with the core action and then organizes details logically. A minor parenthetical like '(costs nothing)' could be trimmed, but there is no redundancy or wasted prose.

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?

The description comprehensively covers return types, status conditions, provenance, safety scope, and source behavior. Given the presence of an output schema, the description does not need to reiterate return fields. It leaves no significant gaps for an AI agent to misuse the tool.

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 schema already documents both parameters (ean and query) with full coverage (100%). The description only mentions 'free text or EAN' which repeats the schema, without adding deeper semantics like when to prefer one over the other or accepted formats. Baseline 3 is appropriate since the schema carries the burden.

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 searches the queried retail source by free text or EAN, and specifies the deterministic match kinds returned. It distinguishes itself from siblings by focusing on preflight candidate search rather than offer comparison or link building.

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 provides clear context on when to use the tool: for searching a retail source and obtaining candidate public records, with explicit note that 'no_match' means 'not in the queried source' rather than 'not sold'. It does not explicitly name alternatives, but the preflight-evidence scope implies it is for initial search before other commerce operations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Jithox Commerce Preflight 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

A4.7/5.0

Disambiguation5/5

Each tool addresses a distinct concern: search, single-offer retrieval, offer comparison, affiliate link building, and readiness self-description. Even the dual-role get_product_offer (offer or checkout evidence) is clearly separated by input pattern, not overlapping with other tools.

Naming Consistency5/5

All tool names follow the consistent verb_noun pattern in lowercase snake_case: search_, get_, compare_, build_. This makes the toolset predictable and easy to navigate.

Tool Count5/5

Five tools is a well-scoped size for a preflight commerce evidence server. Each tool earns its place and there is no bloat or redundancy.

Completeness5/5

The domain is preflight evidence (no ordering/payment), and the set covers search, offer lookup, comparison, affiliate link, and readiness introspection. This is a complete lifecycle for the stated purpose with no obvious gaps.

Resources

Need Help?