PuroAir
Server Details
Breathe with Confidence. Live MCP catalog for PuroAir HEPA air purifiers - stock, pricing, details.
- 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 distinct purpose: discovery (list_products, search_products), detail retrieval (get_product_details), price/stock checking (get_price, check_stock), and cart operations (add_to_cart for single items, create_checkout for multiple). No overlap in functionality.
All tools follow a consistent verb_noun pattern in snake_case: add_to_cart, check_stock, create_checkout, get_price, get_product_details, list_products, search_products. No deviations.
Seven tools cover the essential e-commerce workflow (browse, search, details, stock, price, cart, checkout) without being excessive or insufficient. The scope is well-matched to the server's purpose.
The set covers product discovery, details, inventory, pricing, and cart creation. Minor gaps exist: no tool for modifying a cart (e.g., remove item) or viewing order history, but these are typically handled on the storefront side. Overall, the main shopping flow is well-supported.
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?
No annotations provided, so full burden on description. It discloses that the tool does not charge or place an order, returns a URL for the shopper to pay themselves, and warns that adding out-of-stock wastes click-through. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact yet complete: a one-line summary, a critical note in all caps, clear parameter descriptions. Every sentence is valuable, no 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 moderate complexity (2 parameters, output schema present), the description covers purpose, restrictions, prerequisites (check_stock), alternatives (create_checkout), and output (checkout URL). It fully equips the 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 0%, so description must compensate. The Args section explains that sku comes from list_products/search_products and quantity defaults to 1, providing essential context beyond the schema's bare types and 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 it adds a product to a cart and returns a checkout URL. It distinguishes from sibling create_checkout by noting that create_checkout is for multiple items. The purpose is specific and 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?
Provides explicit when-to-use ("add X to my cart") and when-not-to-use (for multiple items, use create_checkout). Also advises to verify stock with check_stock first, which guides the agent in proper tool selection and sequence.
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 + stock 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
- stock: Current inventory count
- 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",
"stock": 42,
"price": 29.99,
"can_ship_today": True,
"message": "✅ WIDGET-001 (Awesome Widget) - 42 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 are provided, so the description carries full burden. It discloses live querying of connected store, return structure, and error conditions. It lacks mention of rate limits or permissions, but the tool is read-only and safe.
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 well-structured with clear sections and front-loaded with the key purpose. It is slightly verbose but every sentence adds value, earning a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description includes a returns section with field names, types, and an example, covering all needed return details. It also describes error states. For a single-parameter tool, the description is 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 description coverage is 0%, but the description fully compensates by explaining the 'sku' parameter in detail, including its source from other tools and an example value. This adds significant 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 explicitly states 'Check LIVE inventory, price, and same-day shipping for ONE known SKU' with a specific verb and resource. It distinguishes from siblings by mentioning when to use other tools like list_products, get_product_details, or get_price.
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 ('when a shopper asks...') and when-not-to-use (for discovery, full attributes, price only). It also gives a critical directive: 'Always call this BEFORE recommending a specific product to buy or adding it to a cart.'
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?
With no annotations, the description carries full burden. It discloses that the tool does not charge or place an order, only returns a checkout URL, providing essential 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 with a clear first line, an important note, and structured parameter documentation. No unnecessary words.
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 one parameter, no annotations, and an output schema, the description covers purpose, behavior, and parameter format adequately. It might lack error handling details, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides minimal info for the 'items' parameter. The description compensates completely by specifying expected structure: list of objects with 'sku' (string) and 'quantity' (int, default 1).
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 states 'Build a multi-item cart and return its checkout URL,' clearly indicating the action and result. It also distinguishes from siblings like add_to_cart by mentioning returning a URL for payment.
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 explicitly notes that the tool does NOT charge or place an order, advising when to use it for assembling a basket. However, it lacks explicit mention of when not to use or alternatives.
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?
No annotations present, but description fully discloses return behavior: returns only price+currency, mentions sales inclusion, advises against using old data, and covers error case.
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 front-loaded purpose, structured into Args/Returns/Example sections, every sentence provides 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?
For a single-parameter tool with output schema present, the description fully covers what the tool does, its inputs, outputs, and edge cases, making it 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 has 0% coverage, but description adds meaningful context for the sku parameter: explains it's the field from list_products and provides an example value, fulfilling the semantic need.
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 gets the current price for a product SKU and explicitly distinguishes from sibling tools like check_stock and get_product_details.
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 shopper asks price and agent has SKU) and when not to use (for stock/shipping/details), with alternative tool names 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
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,
inventory_quantity, available, image_url); ``found`` is False when the
SKU is missing.
| 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?
Details the return fields and notes that 'found' is false when SKU is missing. Lacks explicit mention of read-only nature or error handling, but is sufficiently transparent for a lookup 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?
Well-structured with sections for args, returns, and usage. Front-loaded with purpose. 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 simple input (one param) and output schema, the description covers all necessary aspects: input source, output fields, and usage context. Integrates with sibling tools effectively.
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 description adds context to the single 'sku' parameter, explaining it should come from the 'sku' field of list_products, which is not present in the schema (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?
The description clearly states the tool retrieves full product details for a specific SKU. It distinguishes itself from sibling tools like list_products and search_products, establishing it as a verifier rather than a browser.
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 agent has a SKU from list_products/search_products) and when not to use (for discovery). Provides guidance on grounding answers in returned fields and linking storefront_url.
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?
No annotations provided, so description carries full burden. It discloses that only sellable products are returned (no drafts/archived), and details the return format including pagination tokens. Does not mention auth or rate limits, but for a read-only listing tool, the information is sufficient.
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 and concise. Core action in first sentence, followed by usage guidelines, parameter documentation, and return structure. No 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?
Complete coverage: input parameters, output structure, behavioral traits (sellable only), pagination, and integration with sibling tools. Sufficient for an agent to use 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%, but the description explicitly documents both parameters: limit (1-50, default 10) and cursor (opaque, from previous next_cursor, omit for first page). Adds full semantics.
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 lists products from the connected store with pagination. It distinguishes itself from search_products by noting that it is for browsing/discovery rather than verifying a known 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?
Explicit guidance on when to use this tool vs search_products (prefer search_products when matchable terms exist). Provides a recommended flow: search_products/list_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.
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, the description carries full burden. It discloses search behavior matches Shopify native storefront, only sellable products returned, and recommended flow. It lacks explicit mention of auth needs or rate limits, but overall is transparent about core 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 well-structured: starts with core purpose, then usage guidance, search tips, and return info. Every sentence adds value, and it remains concise without 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 low complexity (2 params, no nested objects, output schema referenced), the description covers all necessary aspects: when to use, how to search, fallback behavior, and recommended flow. It is complete for an agent to use effectively.
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?
Despite 0% schema description coverage, the description adds meaningful semantics: query is a keyword/phrase to match, limit has a range of 1-50 and default of 10, which goes beyond the schema's type and default.
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 products by keyword in the connected store, specifies it matches against titles and tags, and distinguishes it from sibling tools like list_products and the rest of the recommended flow.
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 advises using this when a shopper's query has specific terms, suggests searching with fewest distinctive words, and instructs to retry broader or fall back to list_products if no results, providing clear context for when to use and when not.
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!