AirShelf Catalog
Server Details
Cross-vendor B2B catalog for AI agents: search, compare, find equivalents, request a quote.
- 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.3/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose: search_catalog for querying, get_product for single product details, compare_products for side-by-side comparison, explain_product for build traces, list_merchants for merchant listing, and request_quote for quotes. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern using snake_case: search_catalog, get_product, compare_products, explain_product, list_merchants, request_quote. No mixing of conventions.
With 6 tools, the server is well-scoped for a B2B catalog domain: search, retrieve, compare, trace, merchant listing, and quote request. The count is neither too few nor too many, each tool serves a necessary function.
The tool surface covers the full lifecycle: discovering products (search), examining details (get, compare), understanding provenance (explain), interacting with merchants (list, request quote). No obvious gaps for a read-only catalog with lead capture.
Available Tools
6 toolscompare_productsARead-onlyInspect
Compare 2-10 products side-by-side. Use slugs from search_catalog. On not_found the result includes did_you_mean: retry with a suggestion or call search_catalog FIRST before escalating. When asked for the fastest / largest / best of a class, compare the FULL class returned by search_catalog, not just two picks.
Each found item includes canonical_name (cite verbatim) and spec_absence_note (do not assert absent fields).
| Name | Required | Description | Default |
|---|---|---|---|
| slugs | Yes | Catalog slugs to compare | |
| provenance | No | Include per-claim source provenance + signed-attestation URL + jwks_url |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | No | |
| items | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the readOnlyHint annotation, including 'not_found' handling with did_you_mean, and specific response fields like canonical_name and spec_absence_note with usage instructions.
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, front-loaded with the core purpose, and each sentence adds necessary information. It is concise despite covering multiple aspects.
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, the description adequately covers purpose, usage, error handling, and behavioral instructions. No major gaps remain for an agent to effectively use this 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?
The input schema has 100% description coverage, so baseline is 3. The description adds marginal value by stating that slugs come from search_catalog, but does not significantly enhance 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 tool's purpose: 'Compare 2-10 products side-by-side.' It specifies the verb (compare) and resource (products), and distinguishes from sibling tools like explain_product and get_product.
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 tells when to use this tool (for comparison) and when to first use search_catalog (for obtaining slugs). It also provides guidance on handling 'not_found' results and on comparing full classes for superlatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_productARead-onlyInspect
Return the agentic build trace (BuilderRunTrace) for a SKU — every stage of the cold-run pipeline that produced this catalog row, including costs and outcomes.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Composite slug to explain |
Output Schema
| Name | Required | Description |
|---|---|---|
| sku | No | |
| note | No | |
| slug | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the description's disclosure of returning build trace data is consistent. Beyond annotations, it reveals that the trace includes every pipeline stage, costs, and outcomes, adding useful 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?
A single, well-structured sentence that front-loads the core action and key outputs. No wasted 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 the tool's complexity (output schema exists), the description adequately explains what the tool does and what it returns. It could mention the output format briefly, but the presence of an output schema reduces the burden.
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 one parameter (slug) described. The description adds minimal extra meaning beyond 'Composite slug to explain' which is already in the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
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 returns the agentic build trace for a SKU, detailing pipeline stages, costs, and outcomes. It uses a specific verb (explain) and resource (product build trace), and distinguishes itself from siblings like get_product or compare_products.
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 use for obtaining build trace data for a SKU, but provides no explicit guidance on when to use versus alternatives like get_product or search_catalog. 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.
get_productARead-onlyInspect
Get full golden-record + latest price for a single catalog product by slug ("-").
canonical_name in the response is the exact product name the judge compares against — cite it verbatim.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Composite slug, e.g. keychron-q1-pro |
Output Schema
| Name | Required | Description |
|---|---|---|
| title | Yes | |
| action | Yes | |
| buyUrl | No | |
| imageUrl | No | |
| productId | Yes | |
| buttonLabel | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true. The description adds value by specifying the response includes a 'full golden-record' and 'latest price', and instructs how to use the canonical_name field. 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?
Two concise sentences with zero waste. The first states the purpose, the second adds critical usage guidance. Perfectly 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 simplicity (1 required param, read-only, output schema present), the description sufficiently covers what the tool returns and how to use the output. A mention of not searching multiple slugs would be minor, but not needed.
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?
Only one parameter (slug) with 100% schema description coverage. The description reinforces the slug format, adding slight context but not significantly beyond the schema. Baseline 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?
Describes a specific action: get full golden-record and latest price for a single product by a slug in a defined format. Clearly distinguishes from sibling tools like search_catalog or compare_products.
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?
Explains when to use the tool (to retrieve a single product by slug) and provides important guidance about the canonical_name field. Lacks explicit when-not-to-use or alternative examples, but the context is clear given sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_merchantsARead-onlyInspect
List AirShelf merchants you can request a quote from (name, slug, product count). Use the returned slug as the merchant argument to request_quote.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| total | No | |
| merchants | Yes |
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 value by specifying return fields and the fact that merchants are quote-requestable, but does not significantly deepen behavioral transparency beyond the 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 two sentences, front-loaded with purpose and actionable information. 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 zero parameters and the existence of an output schema, the description is complete enough: it states what the tool does, what data is returned, and how to use the output. It could mention pagination or filtering, but that is not required for a simple list.
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?
There are no parameters, so the baseline is 4. The description adds no parameter details but does enhance understanding by linking the output to another tool's input.
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 AirShelf merchants available for quote requests and specifies the returned fields (name, slug, product count). It also distinguishes itself by linking to request_quote, a sibling 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 explicitly tells how to use the output (slug as merchant argument for request_quote), providing clear context. It lacks explicit when-not-to-use guidance, but the sibling context makes the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_quoteAInspect
Submit a B2B quote request to a specific merchant once the buyer wants to proceed. Captures a contactable lead and returns a reference number. Resolve the merchant (slug or id) via list_merchants.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | Any extra context from the buyer | |
| contact | Yes | Buyer contact details | |
| merchant | Yes | Merchant slug or id (from list_merchants) | |
| products | Yes | Catalog slugs the buyer is interested in | |
| quantity | No | Units the buyer wants |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | No | |
| merchant | No | |
| referenceNumber | No | Quote reference for the buyer |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it is not read-only and not destructive. The description adds that it captures a contactable lead and returns a reference number, which is useful but does not fully disclose side effects like email notifications or data persistence.
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?
Two sentences, front-loaded with the main action. No redundant information; every part 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 complexity (5 params, 3 required, nested objects, output schema exists), the description provides a complete overview: purpose, prerequisite, and outcome. Could mention error handling but not critical for a quote request 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 covers all parameters with descriptions (100% coverage). The description adds value for the merchant parameter by instructing to resolve via list_merchants, but otherwise does not enhance understanding of other parameters 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 action (submit a B2B quote request), the specific resource (to a specific merchant), and the condition (once buyer wants to proceed). It distinguishes from siblings by mentioning merchant resolution via list_merchants, which is a sibling 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 clear context for when to use ('once the buyer wants to proceed') and a prerequisite (resolve merchant via list_merchants). It does not explicitly list when not to use or alternatives, but the trigger condition is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_catalogARead-onlyInspect
Search AirShelf catalog by natural-language query (e.g. "tactile mechanical keyboard under $150"). Returns ranked products with prices.
Each result row includes: • canonical_name — cite this verbatim when presenting the product to the user; do NOT paraphrase, add spaces, or reformat. • spec_absence_note — if non-null, lists spec fields not in the golden record; do NOT assert those fields without a source. • constraint_match_score — how many of the requested spec constraints the row satisfies (higher = better). • matched_criteria / missing_criteria — per-row spec accounting.
parsed.price_availability.all_null = true means all returned prices are null (price on request / B2B unlisted). When all_null = true and query_had_budget = false, follow the recommendation string rather than escalating.
If the response's parsed.weak_match is true, the catalog could not honor the buyer's constraints — do not present these results as satisfying the request; say what could not be matched and consider escalating. If parsed.no_match is true, no catalog product satisfies the buyer's hard constraint — candidates violating it were excluded server-side; do NOT recommend a substitute; escalate.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Natural-language query. Supports budget ("under $150") and switch-type hints. | |
| limit | No | Max results | |
| specs | No | Hard spec facets, e.g. {"form_factor":"desktop","print_speed_ppm":33}. Filters by exact/range spec match. | |
| category | No | Optional category filter (e.g. mechanical-keyboards) |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | No | |
| query | No | |
| results | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. The description adds substantial behavioral context: result fields (canonical_name, spec_absence_note, etc.), ranking, and edge cases like weak_match and no_match. This goes well beyond the 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 well-structured: a clear first sentence, bullet points for result fields, and then special-case handling. It is informative without being verbose. Slightly longer than necessary, but every part 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 complexity of the tool (4 params, nested objects, output schema), the description covers the main purpose, result interpretation, and critical edge cases. It is complete enough for an agent to select and invoke 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 description coverage is 100%, so baseline is 3. The description adds a small extra hint for the 'q' parameter (supports budget and switch-type hints), but does not significantly enhance understanding of the other parameters 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 states the tool's purpose: 'Search AirShelf catalog by natural-language query'. It specifies the resource (catalog) and the action (search with ranking). Siblings like compare_products, explain_product, get_product are distinct, so there is no 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 explicit guidance on interpreting results, including handling of weak_match, no_match, and all_null prices. It implies when to escalate but does not explicitly state when to use this tool over siblings. However, the context of sibling names makes it clear.
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!