Estroni Storefront
Server Details
UCP agentic-commerce proxy for Estroni: merino & low-tox women's activewear catalogue.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- estroni/storefront-mcp
- GitHub Stars
- 0
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.9/5 across 5 of 5 tools scored. Lowest: 3.2/5.
Each tool targets a distinct operation: cart retrieval, product details, catalog search, policies/FAQs, and cart updates. No overlap in purpose.
All tool names follow a consistent verb_noun pattern in snake_case, such as get_cart, search_catalog, update_cart.
5 tools is well-scoped for a storefront, covering essential operations without being overly numerous or sparse.
The tool set covers product discovery, cart management, and policies. Minor gap: no direct tool for listing all products without search, but search serves that purpose.
Available Tools
5 toolsget_cartAInspect
Get the cart including items, shipping options, discount info, and checkout url for a given cart id
| Name | Required | Description | Default |
|---|---|---|---|
| cart_id | Yes | Shopify cart id, formatted like: gid://shopify/Cart/c1-66330c6d752c2b242bb8487474949791?key=fa8913e951098d30d68033cf6b7b50f3 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates a read operation (get), but does not explicitly state that the tool is read-only, has no side effects, or requires specific authorization. The description is straightforward but lacks explicit behavioral disclosure.
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 immediately states the tool's purpose and scope. No unnecessary words or 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 simplicity of the tool (1 required parameter, no output schema), the description adequately covers what the tool returns (items, shipping, discounts, checkout URL). It could mention that the cart ID must be valid, but schema already marks it required.
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% for the single parameter, and the schema already provides a detailed format example. The description adds context about what the cart includes but does not add meaning beyond the parameter's purpose.
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 uses the verb 'Get' and specifies the resource 'cart' along with its contents (items, shipping options, discount info, checkout url). It distinguishes from siblings like get_product_details and search_catalog which target different resources or use different retrieval methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a cart ID, but does not explicitly state when to use this tool over siblings like search_catalog or get_product_details. No exclusion criteria or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_product_detailsAInspect
Look up a product by ID. Pass the 'options' parameter to select a specific variant for the product card. Without options, the first available variant is returned.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | ISO 3166-1 alpha-2 country code for which to return localized results (e.g., 'US', 'CA', 'GB'). | |
| options | No | Variant options to select a specific variant, e.g. {"Size": "10", "Color": "Black"}. Without options, the first available variant is returned. Option matching is case-insensitive and partial options are accepted. | |
| language | No | ISO 639-1 language code for which to return localized results (e.g., 'EN', 'FR', 'DE'). | |
| product_id | Yes | The product ID, e.g. gid://shopify/Product/123 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey all behavioral traits. It explains that without options, the first available variant is returned, and the schema details case-insensitivity and partial matching. However, it does not explicitly state that the operation is read-only or describe any side effects.
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 the main action stated first, followed by a key detail. Every sentence is necessary and no superfluous 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 absence of an output schema and annotations, the description covers the basic lookup and variant selection but does not explain what information is returned or any constraints. It is adequate but leaves gaps for the 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?
The input schema already has 100% parameter descriptions, setting a baseline of 3. The description adds value by explaining the 'options' parameter's role in variant selection and default behavior, exceeding 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 clearly states the tool's purpose: 'Look up a product by ID.' This is a specific verb and resource, and it distinguishes itself from sibling tools (get_cart, search_catalog, etc.) which serve different functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (when you have a product ID and need details) but does not explicitly mention when not to use it or compare it to alternatives like search_catalog.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_catalogAInspect
Search for products from the online store, hosted on Shopify.
This tool can be used to search for products using natural language queries, specific filter criteria, or both. At least one of query or filters must be provided.
Results are paginated, with initial results limited to improve experience. Use the pagination.cursor from the response to fetch additional pages when users request more results.
Response conforms to the UCP catalog search capability (dev.ucp.shopping.catalog.search).
| Name | Required | Description | Default |
|---|---|---|---|
| meta | No | MCP transport metadata for UCP agent discovery. | |
| catalog | No | Catalog search parameters. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses pagination behavior and the need for a cursor to fetch more pages. It does not explicitly state that the tool is read-only, but the context implies it. Provides good 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 reasonably concise with 9 sentences, front-loading the purpose. Some slight redundancy (e.g., repeating 'search'), but overall efficient and 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 complex nested schema, the description adequately covers usage requirements and pagination. No output schema exists, but the description references the response format via UCP capability. Sufficient for an agent to use the tool correctly.
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 that at least one of query or filters is required and how pagination cursor works, enhancing understanding 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 verb 'Search' and the resource 'products from the online store, hosted on Shopify'. It effectively distinguishes from sibling tools like get_product_details and search_shop_policies_and_faqs.
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 when to use the tool and requires at least one of query or filters. However, it does not explicitly state when not to use it or mention alternatives, though the purpose is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_shop_policies_and_faqsBInspect
Used to get facts about the stores policies, products, or services. Some examples of questions you can ask are:
What is your return policy?
What is your shipping policy?
What is your phone number?
What are your hours of operation?"
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A natural language query. | |
| context | No | Additional information about the request such as user demographics, mood, location, or other relevant details that could help in tailoring the response appropriately. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as authentication requirements, rate limits, or side effects. For a presumably read-only query tool, minimal transparency.
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?
Concise with one main sentence and bulleted examples. Easy to scan. Could be slightly more structured, but effective.
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 no output schema, the description partially covers what is returned ('facts') but lacks detail on response format, pagination, or error handling. Examples help, but overall incomplete for a tool with no output schema.
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 sufficient descriptions. The main description adds example queries but does not deepen understanding of parameter purpose or constraints beyond the schema. 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 the tool retrieves facts about policies, products, or services, with specific examples. The name 'search_shop_policies_and_faqs' aligns well. It is differentiated from sibling tools like 'search_catalog', which likely handles product search, though not explicitly stated.
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?
Examples provide context but no explicit guidance on when to use versus alternatives or when not to use. It implies applicability for policy/FAQ queries but does not exclude cases better suited for other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_cartAInspect
Perform updates to a cart, including adding/removing/updating line items, buyer information, shipping details, discount codes, gift cards and notes in one consolidated call. Shipping options become available after adding items and delivery address. When creating a new cart, only addItems is required.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | A note or special instructions for the cart. Optional - can ask if customer wants to add special instructions. | |
| cart_id | No | Identifier for the cart being updated. If not provided, a new cart will be created. | |
| add_items | No | Items to add to the cart. Required when creating a new cart. | |
| update_items | No | Existing cart line items to update quantities for. Use quantity 0 to remove an item. | |
| buyer_identity | No | Information about the buyer including email, phone, and delivery address. | |
| discount_codes | No | Discount or promo codes to apply to the cart. Only prompt if customer mentions having a discount code. | |
| gift_card_codes | No | Gift card codes to apply to the cart. Only prompt if customer mentions having a gift card. | |
| remove_line_ids | No | List of line item IDs to remove explicitly. | |
| delivery_addresses_to_add | No | Information about the delivery addresses to add. | |
| selected_delivery_options | No | The delivery options to select for the cart. | |
| delivery_addresses_to_replace | No | Delivery addresses to apply to the cart, replaces all existing cart delivery addresses. Removes all delivery addresses when empty. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains that shipping options become available after adding items and delivery address, but does not describe side effects, idempotency, failure semantics, or permissions required. While it covers core functionality, more transparency would be beneficial for a complex tool with 11 parameters.
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 relatively concise, consisting of two sentences. The first sentence lists the capabilities, and the second provides a usage note. However, the first sentence is somewhat long and could be broken into bullet points for clarity, but overall it is 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?
Given the tool's complexity (11 parameters, nested objects, no output schema), the description covers the main functionality and a few constraints. However, it does not describe the return value or error handling, which would be useful for an agent. The description is adequate but not fully 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%, so baseline is 3. The description adds value beyond the schema by explaining the consolidation of multiple updates and the dependency between adding items/delivery address and shipping options. It also notes that only addItems is required for new carts, which is not explicit in 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 that the tool performs updates to a cart, including adding/removing/updating line items, buyer information, shipping details, discount codes, gift cards, and notes in one consolidated call. It uses a specific verb ('perform updates') and resource ('cart'), and distinguishes from sibling tools like get_cart (retrieval) and search_catalog (search).
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 usage context: it is for consolidated updates and notes that shipping options become available after adding items and delivery address. It also specifies that when creating a new cart, only addItems is required. However, it does not explicitly state when not to use the tool (e.g., for simple lookups), but the differentiation from sibling tools is implicit.
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!