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. |
| gateway_mcp_url | No | Canonical UCP Gateway MCP endpoint URL to save in ./.ucpgateway/agent.json. |
| 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?
Beyond annotations (readOnlyHint=false, destructiveHint=false), the description adds idempotency, side effects (creates local files), security warnings about private keys, and re-registration behavior. This provides rich behavioral context.
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 concise (4 sentences), front-loaded with the main action, and free of unnecessary words. Every sentence adds necessary information.
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, output schema exists), the description covers registration flow, idempotency, local file creation, security, and mode selection. No major gaps remain.
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. The description adds value by explaining the two registration paths and how parameters relate (e.g., 'Default path: send agent_name plus public_key_jwk'), but some parameter warnings duplicate schema descriptions.
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 registers a hosted UCP agent profile and returns agent_id/profile_url, distinguishing it from sibling tools like get_ucp_profile (retrieval) and shopping 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?
It explains two registration modes (default with public_key_jwk vs. advanced with profile_json), provides context for when to use each (normal SKILL.md-only agents omit profile_json), and mentions idempotency. However, it does not explicitly contrast with sibling tools beyond the obvious.
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 cancelBInspect
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. |
| partial_success | No | True when Shopify flagged the upstream result as an error but returned a usable checkout payload (id plus continue_url or recognized status). The gateway result is still actionable; this is not an order confirmation. |
| upstream_is_error | No | True when the upstream Shopify MCP response set isError/ok:false while still returning a usable checkout payload. Present for debugging; does not make the gateway tool result an error. |
| commerce_session_id | No | Internal gateway commerce session UUID when one was created. |
| requires_escalation | No | True when Shopify requires the buyer to finish a step on the merchant-hosted checkout page (status requires_escalation/requires_buyer_input or escalation warnings). The continue_url is still actionable. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which indicate non-read-only, non-destructive), the description only states it 'cancels' a checkout. It does not disclose side effects, reversibility, authorization needs, or error behaviors. The term 'cancel' implies state mutation, but existing annotations do not clarify if this is destructive or what happens to associated data.
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, very concise with no wasted words. However, it is perhaps too terse, lacking explanatory context that could improve understanding. Still, it earns its single sentence.
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 5 parameters, an output schema, and several related siblings, the description is insufficiently complete. It does not explain how to use idempotency key for retries, what happens on cancellation (e.g., state changes, refunds?), or error handling. The agent lacks enough context to use the tool confidently.
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. The description mentions 'idempotency key' but does not add new parameter semantics beyond what the schema already provides. No additional value is provided for the remaining 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?
The description uses the specific verb 'cancel' and identifies the resource as 'active merchant checkout', which clearly distinguishes it from sibling tools like shopping_cart_cancel (cart vs checkout) and shopping_checkout_create/get/update (different operations). The mention of 'idempotency key' adds specificity.
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 (e.g., shopping_checkout_update or shopping_cart_cancel). It does not mention prerequisites, conditions, or situations where cancellation is inappropriate.
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. |
| partial_success | No | True when Shopify flagged the upstream result as an error but returned a usable checkout payload (id plus continue_url or recognized status). The gateway result is still actionable; this is not an order confirmation. |
| upstream_is_error | No | True when the upstream Shopify MCP response set isError/ok:false while still returning a usable checkout payload. Present for debugging; does not make the gateway tool result an error. |
| commerce_session_id | No | Internal gateway commerce session UUID when one was created. |
| requires_escalation | No | True when Shopify requires the buyer to finish a step on the merchant-hosted checkout page (status requires_escalation/requires_buyer_input or escalation warnings). The continue_url is still actionable. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it requires operator confirmation, does not accept payment credentials, and specifies expected formats. Annotations show it's a write operation (readOnlyHint=false) but not destructive (destructiveHint=false). The description aligns with this and provides additional guardrails.
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 main purpose and key constraints. No filler or redundancy; every word earns its place.
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 (9 params, nested objects, output schema), the description is minimal. It covers the essentials but does not explain the checkout workflow, the meaning of 'handoff URL', or how to use cart_id vs line_items. The output schema exists, so return values are not required, but more process context would help.
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. The description reinforces schema constraints (e.g., 'Buyer phone should be E.164 and country must be ISO-2') but does not add substantial new meaning beyond what the property descriptions already provide.
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 main action: 'Create a merchant checkout handoff URL after operator confirmation.' It includes constraints ('Does not accept payment credentials.') that differentiate it from payment-related tools, and 'operator confirmation' distinguishes it from other shopping checkout tools like update or 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?
The description provides clear context for when to use the tool: after operator confirmation, and with specific format requirements for phone and country. It does not explicitly compare with sibling tools or state when not to use it, but the name and constraints imply the use case.
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 getARead-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. |
| partial_success | No | True when Shopify flagged the upstream result as an error but returned a usable checkout payload (id plus continue_url or recognized status). The gateway result is still actionable; this is not an order confirmation. |
| upstream_is_error | No | True when the upstream Shopify MCP response set isError/ok:false while still returning a usable checkout payload. Present for debugging; does not make the gateway tool result an error. |
| commerce_session_id | No | Internal gateway commerce session UUID when one was created. |
| requires_escalation | No | True when Shopify requires the buyer to finish a step on the merchant-hosted checkout page (status requires_escalation/requires_buyer_input or escalation warnings). The continue_url is still actionable. |
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 beyond 'refresh', which might imply a fetch operation. No contradictions, but also no additional disclosure of side effects or safety considerations.
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 of three words, efficiently conveying the core purpose without any extraneous information. It is front-loaded and earns its place.
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, full parameter descriptions, and sibling context, the description is largely complete for a simple read-only tool. However, it lacks usage guidance, but this is partly compensated by the tool's straightforward nature.
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 each parameter having a clear description. The tool description does not add any further meaning beyond the schema, so baseline score of 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 'Refresh merchant checkout state' uses a specific verb ('refresh') and resource ('checkout state'), clearly indicating the tool's read-only nature, which distinguishes it from siblings like create, update, and 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?
The description provides no explicit guidance on when to use this tool versus alternatives. While the name and sibling list imply it's for retrieving current checkout state, there is no mention of when not to use it or which other tools might be more appropriate.
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 typed buyer (recommended for address/phone corrections) and/or a full checkout object. 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. | |
| agent_id | Yes | Registered UCP Gateway UUID returned by register_ucp_profile; required for every Shopping tool. | |
| checkout | No | Optional full checkout replacement payload accepted by the provider. Prefer typed buyer for address/phone corrections; buyer address fields placed here are canonicalized into buyer/context/fulfillment with phone_number. 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. |
| partial_success | No | True when Shopify flagged the upstream result as an error but returned a usable checkout payload (id plus continue_url or recognized status). The gateway result is still actionable; this is not an order confirmation. |
| upstream_is_error | No | True when the upstream Shopify MCP response set isError/ok:false while still returning a usable checkout payload. Present for debugging; does not make the gateway tool result an error. |
| commerce_session_id | No | Internal gateway commerce session UUID when one was created. |
| requires_escalation | No | True when Shopify requires the buyer to finish a step on the merchant-hosted checkout page (status requires_escalation/requires_buyer_input or escalation warnings). The continue_url is still actionable. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds constraints (E.164 phone, ISO-2 country) beyond annotations (readOnlyHint=false, destructiveHint=false), but does not disclose whether updates are merge or replace, any side effects, or error behavior. The description is adequate but not rich.
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 concise with two short sentences. It front-loads the main purpose and includes a usage note, but could be slightly more structured to separate modes of 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 has 6 parameters, nested objects, and an output schema, the description is sparse. It does not explain update semantics (merge vs replace) or error scenarios, though the output schema partially compensates for return value 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?
With 100% schema description coverage, the description reinforces key constraints (E.164, ISO-2) and adds the recommendation to prefer the typed buyer for corrections. This adds marginal value beyond the 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?
The description clearly states the tool updates a checkout with a typed buyer or full checkout object, and is recommended for address/phone corrections. However, it does not explicitly distinguish this from sibling tools like shopping_checkout_create or shopping_checkout_get, leaving room for ambiguity.
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 some guidance by recommending use for address/phone corrections, but lacks explicit when-not-to-use conditions and does not mention alternatives. Sibling names are present in context but not referenced in the description.
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 searchBRead-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, indicating a safe read operation. The description adds no behavioral details beyond that, such as pagination or side effects, but 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 efficient sentence with no wasted words. However, it could include a brief note on key capabilities like filtering or pagination without harming conciseness.
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?
Despite having an output schema and detailed input schema, the description fails to hint at important features like pagination (cursor), filtering, or context parameters. The agent must examine the schema for basic understanding, which is insufficient for a tool with 6 parameters and nested objects.
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 does not add extra meaning beyond the basic search function, meeting the baseline adequately.
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, with a specific verb 'Search' and resource 'product catalog'. It distinguishes from siblings like shopping_product_get (single product retrieval) 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?
The description provides no explicit guidance on when to use this tool versus alternatives like shopping_product_get. No mention of use cases, prerequisites, or exclusions is present.
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!