Provider-neutral, read-only commerce preflight with UCP/ACP checkout evidence. Never orders.
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 4.5/5 across 5 of 5 tools scored.
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.
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.
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.
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.
build_affiliate_buy_linkBuild an official buy link for a humanAReturn the provider's OFFICIAL product link for a record — no network call, nothing ordered, never a checkout-completion URL. A HUMAN clicks it; any commission accrues at the provider's own partner programme, never through this server. 'ready' when the provider publishes a link; 'unsupported' when it does not; truthful 'not_configured' (costs nothing) without a provider. Preflight evidence only — this server never places, modifies or cancels an order and never touches a payment; the merchant stays merchant of record.
| Name | Required | Description | Default |
|---|---|---|---|
| publicRecordId | Yes | The public record id to link to. |
| Name | Required | Description |
|---|---|---|
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it readOnly and non-destructive, and the description adds substantial context: no network call, no order placement, no payment handling, provider remains merchant of record, and truthful not_configured status. This goes far beyond what annotations provide and contains no contradictions.
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 main action is front-loaded, and every caveat serves a safety/commerce purpose. There is minor redundancy (e.g., 'no network call' and later 'never places, modifies or cancels an order'), but it remains efficient for a tool with financial implications.
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 description covers purpose, usage boundaries, status values ('ready', 'unsupported', 'not_configured'), and provider-of-record behavior. An output schema exists, and return values are even explained, making the description sufficient for 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?
The single parameter publicRecordId is fully documented in the schema with a clear description. The tool description adds only the generic context of 'record' but no new parameter-specific syntax or format information. With 100% schema coverage, 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 opens with 'Return the provider's OFFICIAL product link for a record'—a specific verb plus resource—and clears up potential confusion by explicitly stating this is not a checkout-completion URL. This distinguishes it from sibling tools like search_retail_products or compare_product_offers.
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 gives clear context: this is for human-click buy links, is preflight-only, and never places or modifies orders. However, it does not explicitly name sibling alternatives or state 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.
compare_product_offersCompare offers as a value tableACompare 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.
| Name | Required | Description | Default |
|---|---|---|---|
| eans | Yes | EANs to compare; a comparison needs at least 2 (fewer returns 'insufficient_identifiers'). |
| Name | Required | Description |
|---|---|---|
| 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 |
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.
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.
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.
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.
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.
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.
get_commerce_readinessCommerce readiness snapshotAOne plain state of THIS server: which commerce provider is configured, which protocols this deployment speaks (UCP profile discovery + negotiation; the ACP REST checkout format), what each protocol still needs before live evidence exists, and the affiliate state. 'ready' / 'not_configured'. Truthful self-description, never a claim about any merchant. Preflight evidence only — this server never places, modifies or cancels an order and never touches a payment; the merchant stays merchant of record.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and destructiveHint annotations, the description explicitly states that this server never places, modifies, or cancels orders and never touches payments, and that the merchant remains merchant of record. This adds valuable behavioral disclosure that is not present in the structured 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, dense paragraph that packs in a lot of information without being overly long. It is front-loaded with the core purpose ('One plain state of THIS server') and each clause contributes meaningful detail. Slightly less concise than a two-sentence example but appropriate for the complexity.
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 has no parameters, rich annotations, and an output schema, the description is complete. It covers the tool's scope (what it reports), its safety guarantees, and its role as a preflight check. It does not need to enumerate return values because the output schema exists, and the description fully compensates for any missing details.
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 tool has zero parameters, so the baseline is 4. The description adds meaning by explaining what the tool reports (provider, protocols, needs, affiliate state, ready status), even though no parameter details are needed. It helps the agent understand the output's conceptual structure.
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 purpose: to report the server's commerce readiness state, including provider configuration, protocols, and affiliate state. It uses specific terminology (UCP, ACP) and distinguishes itself from sibling tools (e.g., build_affiliate_buy_link, compare_product_offers) by focusing on server-level status rather than product/offer actions.
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 context: use before live evidence is available ('preflight evidence only') and as a read-only check. It does not explicitly name alternatives or when not to use, but the scope is clear enough to infer that it's for assessing the server's readiness rather than performing merchant actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_product_offerGet one product's current offer or checkout evidenceAReport one product's current offer from the queried source (price in integer minor units, availability, provenance) — or, given a merchant host plus the merchant's own itemId, prepare/re-check NORMALIZED CHECKOUT EVIDENCE over the merchant's declared UCP/ACP checkout data: items, currency, subtotal, discount, tax, fees, shipping, total, fulfillment, policy links, expiry and an evidence hash, with bounded truth states 'verified' / 'changed' / 'unsupported' / 'unavailable' / 'unverified'. Pass priorEvidence (component hashes from an earlier answer) to detect price/stock/shipping/terms changes between preparation and re-check. 'verified' means fetched, parsed and internally consistent — never 'safe', never 'approved', never a guarantee the merchant honors the quote. A price is never guessed. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| ean | No | EAN/GTIN of the product. | |
| itemId | No | The merchant's own item id (required with merchant). | |
| merchant | No | A merchant hostname for checkout evidence (must be on this deployment's allowlist or served by a configured provider). | |
| quantity | No | Quantity for the checkout evidence quote (default 1). | |
| priorEvidence | No | componentHashes from a prior evidence answer — presence turns this call into a re-check with per-component change detection. | |
| publicRecordId | No | A public record id from a prior search. |
| Name | Required | Description |
|---|---|---|
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only, open-world, non-destructive; the description adds meaningful behavioral context: bounded truth states, 'never safe/approved/guarantee', price never guessed, provenance source naming, and server-side limitations (no order/payment actions). This goes well 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph with many clauses; it leads with the main action but packs in caveats (truth states, provenance, safety) that could be structured. It remains informative and not redundant with schema.
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 complex tool with 6 params, nested objects, and an output schema, the description covers the tool's dual modes, expectations, safety boundaries, and change-detection behavior, leaving little ambiguity. Output schema covers return values.
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 covers 100% of params with descriptions. The tool description adds context on priorEvidence's role (re-check with change detection) and merchant allowlist requirement, but otherwise relies on schema for individual parameter semantics—a solid improvement over the baseline.
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 explicitly states the tool reports one product's current offer or prepares/re-checks normalized checkout evidence, with specific data points (price, availability, provenance, truth states). This clearly distinguishes it from siblings like search_retail_products (searching) and compare_product_offers (comparing).
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 explains two distinct invocation modes (offer vs checkout evidence) and the condition for re-check (passing priorEvidence). It provides context for preflight use and states the server never places orders, but it does not explicitly contrast with sibling tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_retail_productsSearch retail productsASearch 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.
| Name | Required | Description | Default |
|---|---|---|---|
| ean | No | EAN/GTIN for an exact lookup. | |
| query | No | Free-text search (title/brand). |
| Name | Required | Description |
|---|---|---|
| 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 |
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.
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.
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.
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.
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.
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.
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!