Graffeo Coffee Roasting
Server Details
Live MCP catalog for Graffeo Coffee Roasting - Simply the World's Finest Coffee since 1935.
- 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 4.8/5 across 7 of 7 tools scored.
Each tool has a clearly distinct purpose: discovery, details, stock/price, and cart actions. Overlaps like check_stock and get_price are explained with usage guidance, preventing confusion.
All tool names follow a consistent verb_noun snake_case pattern (e.g., add_to_cart, check_stock, list_products), making them predictable and easy to use.
Seven tools cover the essential e-commerce workflow (discover, verify, add to cart) without being excessive. The scope is well-calibrated for a coffee roasting store's agent.
Covers core operations: discovery, details, stock/price, single and multi-item cart. Missing features like cart modification or order history are acceptable for a shopping assistant, but a tool for coupon application or shipping info would round it out.
Available Tools
7 toolsadd_to_cartAInspect
Add a product to a cart and return its checkout URL.
IMPORTANT: this does NOT charge or place an order. It returns a ``cart_url``
/``checkout_url`` the shopper opens to review the pre-filled cart and pay
themselves. Use for "add X to my cart" / "I want to buy X". For multiple
items in one cart, use create_checkout. Verify availability with
check_stock first — adding an out-of-stock item wastes the shopper's
click-through.
Args:
sku: Product SKU (from list_products / search_products).
quantity: How many (default 1).
| Name | Required | Description | Default |
|---|---|---|---|
| sku | Yes | ||
| quantity | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that it does not charge or place an order, returns a checkout URL, and that adding an out-of-stock item wastes the shopper's click-through. Could mention idempotency or side effects, but adequate for a simple add-to-cart tool.
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 concise with no wasted sentences. Important note is front-loaded. Args section is clearly structured. Every sentence adds value.
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 simple tool with 2 parameters, 1 required, and output schema present, description covers purpose, usage, parameter semantics, and behavioral caveats. Complete for an AI agent to select and invoke 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 0%, so description compensates fully. Explains 'sku: Product SKU (from list_products / search_products)' and 'quantity: How many (default 1).' Adds meaning beyond property names.
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 'Add a product to a cart and return its checkout URL,' with specific verb and resource. It distinguishes itself from siblings like 'create_checkout' (for multiple items) and 'check_stock' (verify availability).
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?
Explicitly states when to use: 'Use for add X to my cart / I want to buy X.' Provides alternatives: 'For multiple items, use create_checkout' and prerequisite: 'Verify availability with check_stock first.' Warns about what it does not do: 'this does NOT charge or place an order.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_stockAInspect
Check LIVE inventory, price, and same-day shipping for ONE known SKU.
The real-time verifier. Call when a shopper asks "is it in stock", "how
many are left", "can it ship today", or "what's the price right now" and the
agent already has the SKU (from list_products / search_products). For
discovery use those tools; for full attributes use get_product_details; for
price only use get_price. Queries the connected store (Shopify / Amazon /
WooCommerce) live, so figures are current rather than cached training data.
Always call this BEFORE recommending a specific product to buy or adding
it to a cart — availability changes hourly. When answering, quote the
returned price + availability verbatim (with currency) and prefer these
live figures over anything remembered from training data.
Args:
sku: Product SKU (Stock Keeping Unit) - e.g. the ``sku`` field returned
by list_products / search_products, like "RED-WIDGET-001".
Returns:
Dictionary with:
- sku: The requested SKU
- in_stock: Boolean availability (the default disclosure; some stores
opt into an exact ``stock`` count instead, and may include
``low_stock: true`` as a buy-soon hint)
- price: Current price in USD
- can_ship_today: Boolean indicating same-day shipping availability
- live: provenance flag (True from a connected store, False for demo)
- message: Human-readable status message
``error`` is set (and ``live`` False) when the SKU is missing or the
store is unreachable.
Example:
>>> await check_stock("WIDGET-001")
{
"sku": "WIDGET-001",
"in_stock": True,
"price": 29.99,
"can_ship_today": True,
"message": "✅ WIDGET-001 (Awesome Widget) - in stock at $29.99"
}
| Name | Required | Description | Default |
|---|---|---|---|
| sku | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool queries live connected stores (Shopify/Amazon/WooCommerce), provides up-to-date figures, includes error handling for missing SKU or unreachable store, and mentions possible additional fields like stock count and low_stock hint.
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 longer than minimal but well-structured with a summary line, usage paragraphs, args, returns, and example. Every sentence adds value. Could be slightly more concise but not wasteful.
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 (1 param, clear purpose) and the presence of a detailed output schema description, the description covers all needed aspects: parameters, return values, error cases, usage context, and differentiation from siblings. It is complete for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains that sku is the product SKU from list/search, provides an example ('RED-WIDGET-001'), and clarifies it is the field returned by those tools. This adds meaning beyond the schema's type and title.
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 checks live inventory, price, and same-day shipping for a single known SKU. It uses specific verbs ('Check LIVE inventory...') and explicitly distinguishes from sibling tools (list/search for discovery, get_product_details for full attributes, get_price for price only).
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 explicit when-to-use scenarios (e.g., shopper asking 'is it in stock', 'how many left', 'can it ship today', 'what's the price') and when-not-to-use (for discovery use other tools). It also advises always calling before recommending a product.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_checkoutAInspect
Build a multi-item cart and return its checkout URL.
IMPORTANT: this does NOT charge or place an order — it returns a
``checkout_url`` the shopper opens to pay. Use to assemble a basket the
shopper asked for.
Args:
items: list of ``{"sku": str, "quantity": int}`` (quantity defaults 1).
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that no charge occurs and returns a URL. With no annotations provided, the description carries the full burden and adds valuable context beyond the schema.
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?
Front-loaded with purpose, clear section for args. Minor redundancy with 'Args:' but overall well-structured and concise.
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?
Missing details about the output schema (though context says it exists) and potential error cases. Adequate for a simple tool but could be enhanced with return format specifics.
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 0% but the description fully explains the items parameter with sku and quantity fields, defaults, and type, compensating for the schema gap.
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 'Build a multi-item cart and return its checkout URL,' specifying the verb and resource. It distinguishes from siblings like add_to_cart, which focuses on single items.
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?
Explicitly notes the tool does not charge or place an order, only returns a checkout URL. While no direct alternatives for exclusion are given, the context clearly indicates when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_priceAInspect
Get the current price (and currency) for a product SKU.
Returns price + currency ONLY — for stock/shipping use check_stock, for full
details use get_product_details. Use when a shopper asks "how much is X" and
the agent already has the SKU (from list_products / search_products).
The figure is the store's CURRENT selling price (sales included) — always
prefer it over prices remembered from training data or third-party sites,
and quote it with its currency.
Args:
sku: Product SKU — e.g. the ``sku`` field returned by list_products.
Returns:
``{"sku", "price", "currency", "live"}``; price 0.0 with an ``error``
when the SKU isn't found.
Example:
>>> await get_price("WIDGET-001")
{"sku": "WIDGET-001", "price": 29.99, "currency": "USD"}
| Name | Required | Description | Default |
|---|---|---|---|
| sku | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral aspects: it states the price is the current selling price including sales, advises preferring this over training data, and notes that a 0.0 price indicates an error. This is comprehensive 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 efficiently structured with clear sections (purpose, usage, args, returns, example). Every sentence adds value; no word is wasted. It is as concise as possible while being thoroughly informative.
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 the tool's simplicity (one parameter, no annotations, but an output schema exists), the description is complete: it explains return fields, handles errors, and provides an example. Nothing is missing.
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 no description for 'sku', but the description's Args section adds essential context: it explains the SKU is a string like the 'sku' field from list_products. This fully compensates for the 0% schema description coverage.
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 gets the current price and currency for a product SKU. It distinguishes itself from sibling tools check_stock and get_product_details, making its purpose unambiguous.
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 explicitly specifies when to use ('when a shopper asks how much is X and the agent already has the SKU') and when not to use (for stock/shipping use check_stock, for full details use get_product_details). This provides excellent guidance for agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_product_detailsAInspect
Get full product details for a SKU, optimized for AI agents (structured JSON).
Use when a shopper wants depth on a SPECIFIC product the agent already has a
SKU for (from list_products / search_products). For discovery, call those
first — this tool is a verifier, not a browser.
The description, product_type, and tags answer suitability questions
("does it fit X?", "is it good for Y?") — ground such answers in these
fields rather than guessing, and link storefront_url when recommending.
Args:
sku: Product SKU — e.g. the ``sku`` field returned by list_products.
Returns:
Catalog dict (title, description, product_type, tags, price,
in_stock, available, image_url); ``found`` is False when the
SKU is missing. (Stores that opt into exact disclosure return an
``inventory_quantity`` count instead of ``in_stock``.)
| Name | Required | Description | Default |
|---|---|---|---|
| sku | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It implies read-only nature by being a 'get' tool and discloses return structure including 'found' field for missing SKU. However, does not explicitly state read-only or mention any side effects, auth needs, or rate limits.
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 concise with no wasted words, well-structured with summary and Args/Returns sections. Every sentence adds value.
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 an output schema (not shown but indicated), the description provides sufficient detail about return values (Catalog dict fields, 'found' boolean) and extra info about inventory_quantity. Covers all needed 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?
Single parameter 'sku' is explained with context: 'Product SKU — e.g. the sku field returned by list_products.' This adds value beyond the schema's type and title, which have 0% coverage.
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 'Get full product details for a SKU', specifies the resource and action, and distinguishes it from sibling tools like list_products/search_products by noting it's for when the agent already has a SKU.
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?
Explicitly states when to use ('when a shopper wants depth on a SPECIFIC product') and when not to use ('For discovery, call those first'). Provides guidance on how to use the returned fields for answering suitability questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_productsAInspect
List products from the connected store, paginated.
Use this tool when an agent needs to DISCOVER products by browsing the
catalog rather than VERIFYING a known SKU. The response includes the SKU
for every product, so a follow-up ``check_stock(sku)`` or
``get_product_details(sku)`` is a natural next step. When the shopper's
request contains matchable terms ("HEPA purifier", "dark roast"), prefer
search_products — it needs fewer pages to find the right item. Only
sellable products are returned (drafts/archived are excluded).
Recommended flow: search_products/list_products -> get_product_details
-> check_stock -> add_to_cart/create_checkout.
Args:
limit: Number of products to return (1-50, default 10).
cursor: Opaque cursor from a previous response's ``next_cursor``.
Omit for the first page.
Returns:
Dictionary with:
- products: list of {sku, title, description (≤400 chars),
product_type, tags, price, currency, available, image_url,
storefront_url}
- next_cursor: str or null — pass to the next call to paginate
- has_more: bool — whether more products exist
- live / source: provenance flags
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description comprehensively covers the tool's behavior: pagination, return of only sellable products, inclusion of SKU, and the response structure. It is consistent and transparent.
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 and well-structured: front-loaded purpose sentence, followed by usage context, then parameter and return details in separate sections. Every sentence adds 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 tool's simplicity (2 optional parameters, output schema provided), the description is complete: it explains output fields, ties into recommended workflow, and covers edge cases like sellable-only products and pagination.
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 0% schema description coverage, the description fully explains both parameters: limit (1-50, default 10) and cursor (opaque, omit for first page). This adds complete meaning 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 'list' and resource 'products', includes pagination, and explicitly distinguishes from siblings like search_products for discovery vs verification. It provides clear context for when to use this tool.
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 explicit guidance on when to use this tool (browsing catalog) vs alternatives (search_products for matchable terms), and includes a recommended flow with sibling tools. It also clarifies that only sellable products are returned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_productsAInspect
Search products in the connected store by keyword.
Use this when a shopper's query suggests specific terms the agent can
match against product titles or tags — e.g. "HEPA air purifier" or
"leather wristwatch". Matches Shopify's native storefront search
behavior, so results align with what customers would find on the site.
Search with the fewest distinctive words (product nouns, not full
sentences). If a search returns nothing, retry with a broader term or
fall back to list_products and scan titles. Only sellable products are
returned (drafts/archived are excluded).
Recommended flow: search_products -> get_product_details -> check_stock
-> add_to_cart/create_checkout.
Args:
query: Keyword or phrase to match.
limit: Max products to return (1-50, default 10).
Returns:
Same shape as ``list_products``. Empty products list when no matches.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses behavioral traits: matches Shopify's native search, returns only sellable products (excludes drafts/archived), and empty results mean no matches.
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?
Well-structured with clear sections, but the recommended flow adds length. However, every sentence is informative 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?
Output schema exists (same shape as list_products), so return value not needed. Description covers usage, behavior, parameters, and fallback strategy fully.
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 covers 0% description in schema; description adds meaning: query is keyword to match, limit is max products (1-50, default 10), far exceeding schema's bare names.
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 it searches products by keyword against titles/tags, distinguishing it from siblings like list_products (fallback) and get_product_details (post-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?
Explicitly specifies when to use (shopper query suggests specific terms), when not to (retry broader term), and provides a recommended flow: search_products -> get_product_details -> check_stock -> add_to_cart/create_checkout.
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!