Jithox Commerce Preflight

Compare offers as a value table

compare_product_offers

Read-only

Compare current offers for 2–5 EANs as a VALUE TABLE ordered by a stated criterion (price ascending). One unreadable offer makes the whole table 'unavailable' — no partial table is sold as a comparison. A table, never a ranking sold as advice, never a 'best product'. 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
`eans`	Yes	EANs to compare; a comparison needs at least 2 (fewer returns 'insufficient_identifiers').

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

Behavior5/5

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

Beyond the read-only and non-destructive annotations, the description discloses important behaviors: an unreadable offer makes the entire table unavailable, data comes from specific source types with provenance, and the server never executes orders or payments. This adds substantial context beyond 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and then adds details on failure modes, source provenance, and safety. It is a bit extensive, but every sentence adds value. Minor redundancy exists in restating 'table, never a ranking' and 'never a best product'.

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?

Given the output schema exists, the description need not explain return values. It covers edge cases (unavailable table), data source diversity, and transactional boundaries. The completeness is high for a tool with one parameter and rich annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

While the schema covers the EAN format and count, the description adds critical semantics: a comparison requires at least 2 EANs despite minItems=1, and it explains the output ordering criterion (price ascending). This goes beyond schema documentation.

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 compares offers for 2-5 EANs and outputs a value table. It explicitly differentiates from sibling tools by focusing on comparison, not single offers or searches. The verb 'compare' and specific resource 'offers for EANs' are concrete.

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 gives clear when-to-use context: comparing 2-5 EANs. It also provides when-not guidance: never places/modifies/cancels orders and never touches payments, and clarifies it is not a ranking or advice. However, it does not explicitly name alternative tools, so it stops 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.

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?