UCP Gateway
Server Details
The Agent Times UCP Gateway — an infrastructure layer that enables open-source AI agents to participate in agentic commerce on Shopify through the Universal Commerce Protocol.
Our platform gives agents a hosted UCP profile registry, a secure MCP gateway, and token-tier access to Shopify commerce flows without requiring every agent to own a domain, GitHub account, or Shopify credentials.
Read more - https://ucpgateway.theagenttimes.com/
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 3.7/5 across 12 of 12 tools scored. Lowest: 2.9/5.
Each tool has a clearly distinct purpose, targeting either UCP profile management or shopping operations (cart, checkout, product). Within the shopping domain, actions are separated by object type (cart vs checkout) and operation (create, get, update, cancel), leaving no ambiguity.
All tools follow a consistent snake_case pattern with verb_noun structure (e.g., get_ucp_profile, shopping_cart_create, shopping_product_search). The naming convention is uniform across profile and shopping tool groups.
With 12 tools, the server is well-scoped for its domain. It provides a focused set covering profile registration, cart and checkout lifecycle, and product search without being overwhelming or insufficient.
The tool set covers the core shopping flow (cart CRUD, checkout CRUD, product lookup) and profile registration. A minor gap is the absence of profile update or deletion, but registration is idempotent and deletion may be out of scope. Overall, no critical missing operations.
Available Tools
12 toolsget_ucp_profileget ucp profileBRead-onlyInspect
Fetch one registered UCP profile by namespace and agent_id.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | Registered UCP Gateway UUID returned by register_ucp_profile; required for every Shopping tool. | |
| namespace | No | Public profile namespace for hosted UCP profiles. Usually 'openclaw'; use lowercase letters, numbers, underscores, or hyphens. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | True for successful tool execution; false for structured tool errors. |
| error | No | Structured tool error. |
| message | Yes | Human-readable result summary or recovery message. |
| profile | No | Hosted public UCP profile JSON. Contains only public key material; private keys must stay local. |
| next_step | Yes | Recommended next step. Suggestions are non-binding and never authorize payment or state-changing actions. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description uses 'Fetch' which is consistent, but provides no additional behavioral details such as permissions or response handling.
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?
Single sentence, no wasted words. Efficiently conveys the core action.
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 an output schema present (not shown but indicated) and annotations covering safety, the description is sufficient for a simple fetch operation. However, it could hint at required authentication context.
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?
Input schema has 100% description coverage for both parameters, so the description adds no extra meaning. Baseline 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 it fetches a UCP profile by namespace and agent_id, but does not differentiate from the sibling tool 'register_ucp_profile' which creates/registers a profile.
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?
No guidance on when to use this tool versus alternatives like 'register_ucp_profile' or other shopping tools. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_ucp_profileregister ucp profileAInspect
Register a public hosted UCP agent profile and receive agent_id/profile_url. Default path: send agent_name plus public_key_jwk and the gateway builds the canonical UCP profile with default Shopping capabilities. Re-registering the same public_key_jwk in the same namespace is idempotent and returns the existing agent_id. Do not build a capability map for normal registration. Create local ./.ucpgateway/ files; keep private_key.jwk local and save returned agent_id/profile_url/profile_json to ./.ucpgateway/agent.json.
| Name | Required | Description | Default |
|---|---|---|---|
| metadata | No | Optional public metadata for the generated profile, such as homepage or runtime. Do not include secrets, tokens, passwords, payment data, private keys, or buyer PII; server-owned fields are overwritten. | |
| namespace | No | Public profile namespace for hosted UCP profiles. Usually 'openclaw'; use lowercase letters, numbers, underscores, or hyphens. | |
| agent_name | Yes | Human-readable public agent name, max 120 characters. | |
| skill_name | No | Optional public skill/package name, e.g. 'ucp-gateway-skill'. | |
| description | No | Optional public agent description, max 500 characters. | |
| profile_json | No | Advanced/legacy only. Public UCP profile JSON for callers that already know the full UCP profile format. Normal SKILL.md-only agents should omit profile_json and send public_key_jwk instead; the gateway builds default Shopping capabilities. If supplied, profile_json must contain ucp.version, ucp.capabilities using exact supported keys (dev.ucp.shopping.catalog.search, dev.ucp.shopping.catalog.lookup, dev.ucp.shopping.catalog, dev.ucp.shopping.cart, dev.ucp.shopping.checkout), ucp.payment_handlers, and only public signing_keys. 'shopping' and 'dev.ucp.shopping' are invalid shorthand. Never include private JWK fields d, p, q, dp, dq, qi, or k. | |
| skill_version | No | Optional public skill/package version, e.g. '0.2.0'. | |
| public_key_jwk | No | Default registration public key. Send an EC P-256 public JWK object (kty='EC', crv='P-256', x, y, optional kid/alg/use). Never include private JWK fields d, p, q, dp, dq, qi, or k; keep private_key.jwk local. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | True for successful tool execution; false for structured tool errors. |
| error | No | Structured tool error. |
| created | No | True when a new profile row was created; false when an existing active profile was reused for this namespace and public key fingerprint. |
| message | Yes | Human-readable result summary or recovery message. |
| profile | No | Hosted public UCP profile JSON. Contains only public key material; private keys must stay local. |
| agent_id | No | Registered UCP Gateway UUID. Save it to ./.ucpgateway/agent.json and include it in every Shopping tool call. |
| namespace | No | Public profile namespace for hosted UCP profiles. Usually 'openclaw'; use lowercase letters, numbers, underscores, or hyphens. |
| next_step | Yes | Recommended next step. Suggestions are non-binding and never authorize payment or state-changing actions. |
| profile_url | No | Hosted public UCP profile JSON URL for this agent. |
| profile_json | No | Hosted public UCP profile JSON. Contains only public key material; private keys must stay local. |
| registry_url | No | Public registry page URL. |
| existing_profile | No | True when registration was idempotent and returned an existing active profile without creating a new row. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, destructiveHint=false) are consistent. Description adds value: explains idempotency for re-registration, default capabilities built by gateway, and security warnings about private keys. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with main purpose and then details. It is clear and covers necessary points without extreme verbosity. Could be slightly more compact, but still 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 the tool's complexity (8 params, oneOf, nested objects, output schema exists), the description fully covers default and advanced registration, idempotency, security precautions, and post-registration steps. No gaps for correct 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 100%, so baseline is 3. The description reiterates some schema info (e.g., private key warnings) but does not add significant meaning beyond the schema. Provides a helpful overview but no extra semantics for individual parameters.
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?
Description clearly states the tool registers a UCP profile and returns agent_id/profile_url. It distinguishes itself from sibling tools (e.g., get_ucp_profile is a read, others are carts/checkouts) by specifying the registration action and resource.
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?
Provides clear context: default vs advanced registration paths, idempotency, and explicit instructions like 'Do not build a capability map' and post-registration file handling. No explicit 'when not to use' but siblings are functionally distinct, so not needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
shopping_cart_cancelshopping cart cancelAInspect
Cancel a merchant cart using an idempotency key.
| Name | Required | Description | Default |
|---|---|---|---|
| cart_id | Yes | Provider cart ID to cancel. | |
| agent_id | Yes | Registered UCP Gateway UUID returned by register_ucp_profile; required for every Shopping tool. | |
| idempotency_key | No | Optional UUID idempotency key for the cancel request; reuse only for retrying the same cancellation. | |
| merchant_domain | Yes | Merchant host such as 'outboundpower.com' or 'example.myshopify.com'. Do not include a URL scheme, localhost, private IP, file URL, or ftp URL. | |
| client_action_id | No | Optional UUID generated once for an explicit buyer/operator-confirmed cart or checkout mutation. Reuse only when retrying the same confirmed action. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | True for successful tool execution; false for structured tool errors. |
| raw | No | Redacted raw provider or registry payload for debugging. Shape may vary by upstream endpoint. |
| cart | No | Safe provider cart summary including id, status, continue_url, totals, line_items, and messages when provided. |
| error | No | Structured tool error. |
| message | Yes | Human-readable result summary or recovery message. |
| next_step | Yes | Recommended next step. Suggestions are non-binding and never authorize payment or state-changing actions. |
| merchant_domain | No | Resolved merchant domain. |
| commerce_session_id | No | Internal gateway commerce session UUID when one was created. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only and non-destructive. Description adds idempotency key use, but no details on side effects like whether cancellation is reversible or permissions needed.
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?
Very concise single phrase, no wasted words. Could be more structured but efficient and front-loaded.
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?
Adequate for a simple cancel action with output schema present. Does not mention prerequisites (e.g., cart must exist) or interaction with siblings, but not critically incomplete.
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 100%, so baseline is 3. Description mentions idempotency key, but that is already described in the input schema. Adds no new meaning beyond 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?
Clearly states it cancels a merchant cart with idempotency key. Specific verb and resource. Distinguishes from sibling 'shopping_checkout_cancel' and other cart tools.
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?
Implied usage for cancelling a cart, but no explicit guidance on when to use versus alternatives like shopping_checkout_cancel. Lacks when-not or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
shopping_cart_createshopping cart createAInspect
Create a merchant cart after the buyer/operator confirms selected variants.
| Name | Required | Description | Default |
|---|---|---|---|
| buyer | No | Optional buyer contact summary for cart creation; never include payment data. | |
| context | No | Optional buyer/search context for catalog, cart, or checkout tools. | |
| agent_id | Yes | Registered UCP Gateway UUID returned by register_ucp_profile; required for every Shopping tool. | |
| line_items | Yes | Selected provider variant line items confirmed by the buyer/operator. | |
| merchant_domain | Yes | Merchant host such as 'outboundpower.com' or 'example.myshopify.com'. Do not include a URL scheme, localhost, private IP, file URL, or ftp URL. | |
| client_action_id | No | Optional UUID generated once for an explicit buyer/operator-confirmed cart or checkout mutation. Reuse only when retrying the same confirmed action. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | True for successful tool execution; false for structured tool errors. |
| raw | No | Redacted raw provider or registry payload for debugging. Shape may vary by upstream endpoint. |
| cart | No | Safe provider cart summary including id, status, continue_url, totals, line_items, and messages when provided. |
| error | No | Structured tool error. |
| message | Yes | Human-readable result summary or recovery message. |
| next_step | Yes | Recommended next step. Suggestions are non-binding and never authorize payment or state-changing actions. |
| merchant_domain | No | Resolved merchant domain. |
| commerce_session_id | No | Internal gateway commerce session UUID when one was created. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false) and non-destructive. The description adds the condition 'after confirmation' but does not disclose further behavioral traits such as side effects, authorization requirements, or rate limits. It provides minimal additional value 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, concise sentence (9 words) that is front-loaded with the action and resource. Every word earns its place with no redundancy or fluff.
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 complexity (6 parameters, nested objects, output schema), the description is very minimal. It does not mention prerequisites like agent_id or merchant_domain, but the schema covers these thoroughly. The description is adequate but not comprehensive.
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%, so the baseline is 3 according to the rubric. The description adds no additional parameter semantics beyond what the schema already 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 identifies the verb ('Create') and resource ('merchant cart') and adds a specific condition ('after buyer/operator confirms selected variants'). This effectively distinguishes it from sibling tools like shopping_cart_update or shopping_cart_cancel, but does not explicitly name 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 description implies the tool should be used after variant confirmation, providing some context. However, it lacks explicit guidance on when not to use it or references to alternative tools, leaving the agent to infer the appropriate usage scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
shopping_cart_getshopping cart getBRead-onlyInspect
Refresh a merchant cart state.
| Name | Required | Description | Default |
|---|---|---|---|
| cart_id | Yes | Provider cart ID returned by shopping_cart_create or shopping_cart_update. | |
| agent_id | Yes | Registered UCP Gateway UUID returned by register_ucp_profile; required for every Shopping tool. | |
| merchant_domain | Yes | Merchant host such as 'outboundpower.com' or 'example.myshopify.com'. Do not include a URL scheme, localhost, private IP, file URL, or ftp URL. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | True for successful tool execution; false for structured tool errors. |
| raw | No | Redacted raw provider or registry payload for debugging. Shape may vary by upstream endpoint. |
| cart | No | Safe provider cart summary including id, status, continue_url, totals, line_items, and messages when provided. |
| error | No | Structured tool error. |
| message | Yes | Human-readable result summary or recovery message. |
| next_step | Yes | Recommended next step. Suggestions are non-binding and never authorize payment or state-changing actions. |
| merchant_domain | No | Resolved merchant domain. |
| commerce_session_id | No | Internal gateway commerce session UUID when one was created. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds minimal behavioral context. It correctly implies no mutation but does not elaborate on rate limits, authentication needs, or return behavior. No contradiction with 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 short sentence, making it very concise. However, it could be slightly more informative without losing brevity. It earns its place but is minimal.
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 simple tool (get cart state) and presence of an output schema, the description provides a basic understanding. However, it lacks details on what 'refresh' entails or the returned data structure beyond the output schema, leaving some gaps 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?
Schema coverage is 100%, so the description does not need to compensate for missing parameter info. The description itself adds no further parameter context, but the schema already documents cart_id, agent_id, and merchant_domain adequately. 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 'Refresh a merchant cart state' uses a specific verb ('Refresh') and resource ('merchant cart state'), clearly indicating read-only retrieval. It is distinguishable from sibling tools that create, update, or cancel carts, though 'Refresh' is slightly less precise than 'Get' or 'Retrieve'.
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?
No guidance is provided on when to use this tool versus alternatives like shopping_cart_update or shopping_checkout_get. The description does not mention exclusions, prerequisites, or context for when to refresh vs. other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
shopping_cart_updateshopping cart updateAInspect
Replace a merchant cart with the full desired cart state.
| Name | Required | Description | Default |
|---|---|---|---|
| cart | Yes | Full replacement cart state. Include the complete desired line_items list, not a patch. | |
| cart_id | Yes | Provider cart ID returned by cart tools. | |
| agent_id | Yes | Registered UCP Gateway UUID returned by register_ucp_profile; required for every Shopping tool. | |
| merchant_domain | Yes | Merchant host such as 'outboundpower.com' or 'example.myshopify.com'. Do not include a URL scheme, localhost, private IP, file URL, or ftp URL. | |
| client_action_id | No | Optional UUID generated once for an explicit buyer/operator-confirmed cart or checkout mutation. Reuse only when retrying the same confirmed action. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | True for successful tool execution; false for structured tool errors. |
| raw | No | Redacted raw provider or registry payload for debugging. Shape may vary by upstream endpoint. |
| cart | No | Safe provider cart summary including id, status, continue_url, totals, line_items, and messages when provided. |
| error | No | Structured tool error. |
| message | Yes | Human-readable result summary or recovery message. |
| next_step | Yes | Recommended next step. Suggestions are non-binding and never authorize payment or state-changing actions. |
| merchant_domain | No | Resolved merchant domain. |
| commerce_session_id | No | Internal gateway commerce session UUID when one was created. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by stating it's a full replacement ('not a patch') and hinting at idempotency via client_action_id. Annotations indicate non-read-only and non-destructive (though 'replace' could be misconstrued as destructive). It provides context about the cart's replacement behavior.
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 captures the essence. It is succinct, but could potentially include a brief note on when to use it or a caution about overwriting. Still, it is not verbose.
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 (handling return values) and comprehensive parameter descriptions in the schema, the description suffices to explain the tool's purpose and key behavioral nuance (full replacement). It covers the necessary context for a shopping cart update 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?
Schema coverage is 100% (baseline 3). The description adds value by clarifying that the 'cart' parameter is a full replacement state, and explains 'client_action_id' for retries. It also includes restrictions for 'merchant_domain' (no URL scheme, localhost, etc.).
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 action ('Replace') and the resource ('merchant cart'), and the phrase 'full desired cart state' distinguishes it from sibling tools like shopping_cart_cancel or shopping_cart_create. It directly conveys what the tool does.
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 that this tool is used when you want to set a cart to a specific state, contrasting with creating or canceling. However, it does not explicitly list when to use it vs. siblings like shopping_cart_get or shopping_cart_update (though the latter doesn't exist among siblings). Slight lack of explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
shopping_checkout_cancelshopping checkout cancelAInspect
Cancel an active merchant checkout using an idempotency key.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | Registered UCP Gateway UUID returned by register_ucp_profile; required for every Shopping tool. | |
| checkout_id | Yes | Provider checkout ID to cancel. | |
| idempotency_key | No | Optional UUID idempotency key for the cancel request; reuse only for retrying the same cancellation. | |
| merchant_domain | Yes | Merchant host such as 'outboundpower.com' or 'example.myshopify.com'. Do not include a URL scheme, localhost, private IP, file URL, or ftp URL. | |
| client_action_id | No | Optional UUID generated once for an explicit buyer/operator-confirmed cart or checkout mutation. Reuse only when retrying the same confirmed action. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | True for successful tool execution; false for structured tool errors. |
| raw | No | Redacted raw provider or registry payload for debugging. Shape may vary by upstream endpoint. |
| error | No | Structured tool error. |
| message | Yes | Human-readable result summary or recovery message. |
| checkout | No | Safe provider checkout summary including id, status, continue_url, totals, line_items, and messages when provided. |
| warnings | No | Non-fatal checkout or handoff warnings. |
| next_step | Yes | Recommended next step. Suggestions are non-binding and never authorize payment or state-changing actions. |
| merchant_domain | No | Resolved merchant domain. |
| commerce_session_id | No | Internal gateway commerce session UUID when one was created. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey non-read-only and non-destructive nature. Description adds only the idempotency key detail, but doesn't elaborate on behavioral traits like permissions, reversibility, or async behavior.
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?
Single sentence of 6 words is maximally efficient and front-loaded with the action and key qualifier.
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?
Output schema exists, reducing need for return value description. However, lacks differentiation from similar sibling tools and does not cover when to use, making it only minimally 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 coverage is 100% with well-described parameters. The description adds marginal value by mentioning the idempotency key, but does not surpass baseline expectations.
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 ('Cancel') and resource ('active merchant checkout') with a distinguishing detail ('using an idempotency key'). Clearly separates from sibling tools like shopping_cart_cancel.
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?
No guidance on when to use this tool versus alternatives (e.g., shopping_cart_cancel). No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
shopping_checkout_createshopping checkout createAInspect
Create a merchant checkout handoff URL after operator confirmation. Does not accept payment credentials. Buyer phone should be E.164 and country must be ISO-2.
| Name | Required | Description | Default |
|---|---|---|---|
| buyer | No | Buyer-provided checkout contact and shipping details. Never invent PII; omit phone if unavailable. | |
| cart_id | No | Provider cart ID returned by cart tools. Provide either cart_id or line_items. | |
| agent_id | Yes | Registered UCP Gateway UUID returned by register_ucp_profile; required for every Shopping tool. | |
| currency | No | ISO 4217 currency code, e.g. 'USD'. | |
| append_utm | No | Whether to append The Agent Times handoff UTM parameters to the merchant continue_url. | |
| line_items | No | Selected provider variant line items confirmed by the buyer/operator. | |
| merchant_domain | Yes | Merchant host such as 'outboundpower.com' or 'example.myshopify.com'. Do not include a URL scheme, localhost, private IP, file URL, or ftp URL. | |
| client_action_id | No | Optional UUID generated once for an explicit buyer/operator-confirmed cart or checkout mutation. Reuse only when retrying the same confirmed action. | |
| operator_confirmed | Yes | Set true only after the buyer/operator reviewed the cart summary and explicitly confirmed checkout creation. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | True for successful tool execution; false for structured tool errors. |
| raw | No | Redacted raw provider or registry payload for debugging. Shape may vary by upstream endpoint. |
| error | No | Structured tool error. |
| message | Yes | Human-readable result summary or recovery message. |
| checkout | No | Safe provider checkout summary including id, status, continue_url, totals, line_items, and messages when provided. |
| warnings | No | Non-fatal checkout or handoff warnings. |
| next_step | Yes | Recommended next step. Suggestions are non-binding and never authorize payment or state-changing actions. |
| merchant_domain | No | Resolved merchant domain. |
| commerce_session_id | No | Internal gateway commerce session UUID when one was created. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds valuable behavioral context: it does not accept payment credentials, requires operator confirmation, and may drop non-E.164 phone numbers. No contradiction with 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 extremely concise: two sentences that front-load the core purpose and constraints. Every sentence adds essential value without redundancy.
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 complexity (9 parameters, nested objects) and the presence of an output schema, the description covers the main behavioral aspects, prerequisites, and critical formatting rules. It could briefly mention the handoff URL purpose, but overall it is complete enough for an AI 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?
Schema coverage is 100%, but the description adds clarifying formatting constraints (E.164 phone, ISO-2 country) and warns against inventing PII. This goes beyond the schema descriptions, which already mention preferences but are less emphatic.
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 it creates a merchant checkout handoff URL after operator confirmation, and explicitly mentions it does not accept payment credentials. This distinguishes it from sibling tools like shopping_checkout_get or shopping_checkout_update.
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 specifies the prerequisite (operator confirmation) and a key exclusion (no payment credentials). It also provides formatting guidance for phone and country. However, it does not explicitly mention when not to use this tool or compare it to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
shopping_checkout_getshopping checkout getCRead-onlyInspect
Refresh merchant checkout state.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | Registered UCP Gateway UUID returned by register_ucp_profile; required for every Shopping tool. | |
| checkout_id | Yes | Provider checkout ID returned by shopping_checkout_create or shopping_checkout_update. | |
| merchant_domain | Yes | Merchant host such as 'outboundpower.com' or 'example.myshopify.com'. Do not include a URL scheme, localhost, private IP, file URL, or ftp URL. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | True for successful tool execution; false for structured tool errors. |
| raw | No | Redacted raw provider or registry payload for debugging. Shape may vary by upstream endpoint. |
| error | No | Structured tool error. |
| message | Yes | Human-readable result summary or recovery message. |
| checkout | No | Safe provider checkout summary including id, status, continue_url, totals, line_items, and messages when provided. |
| warnings | No | Non-fatal checkout or handoff warnings. |
| next_step | Yes | Recommended next step. Suggestions are non-binding and never authorize payment or state-changing actions. |
| merchant_domain | No | Resolved merchant domain. |
| commerce_session_id | No | Internal gateway commerce session UUID when one was created. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds 'refresh', which is consistent but does not disclose additional behaviors like idempotency or side effects beyond what annotations convey.
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?
A single, front-loaded sentence conveys the core purpose efficiently. No wasted words, though slightly terse.
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 read tool with full schema coverage, output schema, and annotations, the description is minimally sufficient. However, it lacks context like typical usage scenarios (e.g., after checkout_update).
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 100% with clear descriptions for all three parameters. The tool description does not add further meaning beyond the schema, meeting 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 'Refresh merchant checkout state' clearly indicates the tool's purpose: retrieving current checkout state. Despite the verb 'refresh' versus the name 'get', the read-only nature is implied, and it distinguishes from checkout create/update/cancel siblings.
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?
No explicit guidance on when to use this tool versus alternatives (e.g., after update, before cancellation). The description does not mention when to refresh or exclude other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
shopping_checkout_updateshopping checkout updateAInspect
Update checkout with a full desired checkout object; use sparingly after checkout exists. Buyer phone should be E.164 and country must be ISO-2.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | Registered UCP Gateway UUID returned by register_ucp_profile; required for every Shopping tool. | |
| checkout | Yes | Full checkout replacement payload accepted by the provider. Use sparingly; prefer E.164 phone and ISO-2 destination country; never include payment credentials. | |
| checkout_id | Yes | Provider checkout ID returned by checkout tools. | |
| merchant_domain | Yes | Merchant host such as 'outboundpower.com' or 'example.myshopify.com'. Do not include a URL scheme, localhost, private IP, file URL, or ftp URL. | |
| client_action_id | No | Optional UUID generated once for an explicit buyer/operator-confirmed cart or checkout mutation. Reuse only when retrying the same confirmed action. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | True for successful tool execution; false for structured tool errors. |
| raw | No | Redacted raw provider or registry payload for debugging. Shape may vary by upstream endpoint. |
| error | No | Structured tool error. |
| message | Yes | Human-readable result summary or recovery message. |
| checkout | No | Safe provider checkout summary including id, status, continue_url, totals, line_items, and messages when provided. |
| warnings | No | Non-fatal checkout or handoff warnings. |
| next_step | Yes | Recommended next step. Suggestions are non-binding and never authorize payment or state-changing actions. |
| merchant_domain | No | Resolved merchant domain. |
| commerce_session_id | No | Internal gateway commerce session UUID when one was created. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is read-write (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds context about format constraints (E.164 phone, ISO-2 country) and warns against payment credentials, but doesn't disclose other behavioral traits like side effects or authorization needs.
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 extremely concise: two sentences with no wasted words. The purpose is front-loaded, and structured information is efficiently communicated.
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 complexity (5 params, nested object, output schema exists), the description covers the key points. The output schema provides return value details, and the schema descriptions fill gaps. Some guidance on the checkout object shape would improve completeness, but overall it's sufficient.
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%, so the schema already explains all parameters. The description adds minimal extra meaning beyond what's in the schema (e.g., format hints). Baseline 3 is appropriate as the description does not significantly deepen understanding.
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 updates a checkout with a full object. It distinguishes from sibling tools like shopping_checkout_create and shopping_checkout_get by specifying 'after checkout exists' and 'update'.
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 advises using sparingly after checkout exists, implying it should only be called for existing checkouts. It also provides format guidelines for phone and country, which aids correct usage. However, it does not explicitly name alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
shopping_product_getshopping product getARead-onlyInspect
Get product details by provider product or variant ID.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | Registered UCP Gateway UUID returned by register_ucp_profile; required for every Shopping tool. | |
| selected | No | Optional selected variant option pairs to resolve a product variant. | |
| product_id | Yes | Provider product ID or variant ID returned by shopping_product_search. The current adapter returns Shopify GIDs. | |
| merchant_domain | No | Merchant host such as 'outboundpower.com' or 'example.myshopify.com'. Do not include a URL scheme, localhost, private IP, file URL, or ftp URL. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | True for successful tool execution; false for structured tool errors. |
| raw | No | Redacted raw provider or registry payload for debugging. Shape may vary by upstream endpoint. |
| error | No | Structured tool error. |
| offers | No | Offers or variants returned by the provider when available. |
| message | Yes | Human-readable result summary or recovery message. |
| product | No | Normalized provider product record. Shape may vary by provider endpoint. |
| next_step | Yes | Recommended next step. Suggestions are non-binding and never authorize payment or state-changing actions. |
| merchant_domain | No | Resolved merchant domain when available. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds the context that the tool retrieves details by ID, but does not disclose other behavioral traits (e.g., rate limits, authentication beyond the required agent_id). This is acceptable given the annotation coverage.
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, well-structured sentence that front-loads the purpose. Every word is informative, with no redundancy or filler. It is optimally concise for a simple get operation.
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 simplicity (read-only, well-documented schema, output schema exists), the description is mostly complete. However, it lacks usage guidelines and does not explicitly state that it is a read operation (though annotations cover this). It provides enough context for a basic get 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?
Schema coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond what the schema already provides for parameters like agent_id, selected, and merchant_domain. It briefly mentions 'by provider product or variant ID' which maps to product_id, but this is already in the schema description.
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 function: 'Get product details by provider product or variant ID.' It uses a specific verb ('Get'), specifies the resource ('product details'), and identifies the key identifier (provider product or variant ID). This distinguishes it from sibling tools like shopping_product_search (searching) and shopping_cart_get (cart retrieval).
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 no guidance on when to use this tool versus alternatives such as shopping_product_search or shopping_cart_get. There is no mention of prerequisites, context, or exclusions, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
shopping_product_searchshopping product searchARead-onlyInspect
Search the product catalog through The Agent Times UCP Gateway.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum products to return; integer from 1 to 10. | |
| query | Yes | Natural-language product search query, e.g. 'portable battery powered air conditioner'. | |
| cursor | No | Pagination cursor returned by a previous search response; omit for the first page. | |
| context | No | Optional buyer/search context for catalog, cart, or checkout tools. | |
| filters | No | Optional product search filters. | |
| agent_id | Yes | Registered UCP Gateway UUID returned by register_ucp_profile; required for every Shopping tool. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | True for successful tool execution; false for structured tool errors. |
| raw | No | Redacted raw provider or registry payload for debugging. Shape may vary by upstream endpoint. |
| error | No | Structured tool error. |
| message | Yes | Human-readable result summary or recovery message. |
| products | No | Normalized provider products returned by search. |
| warnings | No | Non-fatal search warnings. |
| next_step | Yes | Recommended next step. Suggestions are non-binding and never authorize payment or state-changing actions. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds minimal behavioral context (the gateway mention) but does not disclose pagination limits or other traits. It does not contradict 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 sentence that is front-loaded and contains no unnecessary words, making it highly concise and 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 the 100% schema coverage, annotations, and presence of an output schema, the description is complete enough for a simple search tool. It could mention pagination or result format, but the 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?
The input schema has 100% description coverage, so the description adds no extra parameter meaning beyond the schema. It correctly does not repeat schema details.
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 product catalog via the UCP Gateway, using a specific verb and resource. It distinguishes itself from siblings like shopping_product_get (single product) and cart/checkout tools.
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?
No guidance is provided on when to use this search tool versus other product or cart tools. The description lacks context on when to prefer search over get, or when to avoid it.
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.
Discussions
No comments yet. Be the first to start the discussion!