store
Server Details
Custom metal-print storefront: catalog search, product details, shipping, reviews. Read-only.
- 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/5 across 11 of 11 tools scored. Lowest: 3.3/5.
Most tools target distinct concerns (compatibility, comparison, recommendations, reviews, shipping, info, search, configuration), but the task variants (check_photo_compatibility_task, search_products_task) are nearly identical to their sync counterparts, which may cause confusion for an agent deciding which to use.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., check_photo_compatibility, get_product_recommendations). The _task suffix for async variants is uniform.
With 11 tools, the server is well-scoped for a store assistant covering product discovery, compatibility, shipping, and configuration initiation. The count feels appropriate without being overwhelming or thin.
The tool surface covers the primary customer journey (search, compare, check compatibility, get shipping, reviews, configure). Missing are order placement or cart management, but these may be out of scope for the server's intended role. A slight gap exists between configuration and purchase.
Available Tools
11 toolscheck_photo_compatibilityCheck Photo CompatibilityARead-onlyIdempotentInspect
Check if a customer's photo dimensions meet the minimum resolution requirements for each metal print size. Returns compatible sizes and a recommendation. Use this when a customer asks whether their photo is high enough quality for a specific size.
| Name | Required | Description | Default |
|---|---|---|---|
| width | Yes | Photo width in pixels | |
| format | No | Image format (e.g. 'jpeg', 'png', 'heic', 'webp') | |
| height | Yes | Photo height in pixels |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| photo | No | |
| sizes | No | |
| message | No | |
| format_note | No | |
| recommendation | No | |
| compatible_count | No | |
| recommended_size | No | |
| configurator_note | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint, covering safety. The description adds that it returns compatible sizes and a recommendation, but does not go beyond annotations. No contradiction.
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 core purpose. Every sentence adds value with 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 output schema exists, the description adequately summarizes returns. For a tool with 3 parameters and full schema coverage, the description is complete enough, though it could hint at the recommendation logic.
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 does not add extra meaning beyond the schema; it only mentions 'photo dimensions' without elaborating on individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: checking photo dimensions against metal print size requirements, returning compatible sizes and a recommendation. It uses specific verbs and resources, distinguishing it from the sibling 'check_photo_compatibility_task'.
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 states when to use the tool: 'when a customer asks whether their photo is high enough quality for a specific size.' It does not mention when not to use or alternatives, but the context is sufficient for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_photo_compatibility_taskCheck Photo Compatibility TaskAInspect
Task-based photo resolution compatibility analysis for long-running MCP clients. Use task polling to retrieve the result.
| Name | Required | Description | Default |
|---|---|---|---|
| width | Yes | Photo width in pixels | |
| format | No | Image format (e.g. 'jpeg', 'png', 'heic', 'webp') | |
| height | Yes | Photo height in pixels |
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 only mentions it's task-based and for long-running clients, but doesn't disclose behavioral traits such as what happens during analysis, any destructive actions, or polling specifics.
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, front-loaded with purpose, 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?
Adequately states it's task-based and needs polling, but lacks details on polling mechanism, expected output, and differences from the synchronous sibling tool, given 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%, so baseline is 3. The description adds no extra meaning beyond the schema; it merely restates the general purpose without detailing parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb ('analysis'), resource ('photo resolution compatibility'), and distinguishes from sibling 'check_photo_compatibility' by specifying it's task-based and for long-running clients.
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 instructs to use task polling to retrieve the result, implying it's for asynchronous operations. However, no explicit when-not-to-use or comparison with the synchronous sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_productsCompare ProductsARead-onlyIdempotentInspect
Compare Bolot Studio products — Legacy Print vs Cinematic Print, or Bolot vs competitors (Displate, Canvas, Framed prints).
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Locale code for localized URLs (e.g. 'en', 'pl', 'de') | |
| country | No | ISO 3166-1 alpha-2 or alpha-3 country code for localized URLs (e.g. 'PL', 'DE', 'GB', 'DEU', 'GBR') | |
| product_handle | No | Product handle for competitor comparison (defaults to 'the-legacy-print') | |
| comparison_type | Yes | Type of comparison |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| market | No | |
| message | No | |
| product | No | |
| category | No | |
| comparison | No | |
| legacy_print | No | |
| sustainability | No | |
| vs_competitors | No | |
| cinematic_print | No | |
| differentiators | No | |
| shared_features | No | |
| quality_assurance | No | |
| wall_art_launch_gate | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description's 'compare' aligns with safe, idempotent behavior. It adds contextual detail about comparison scope but does not contradict annotations and adds limited new behavioral info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, directly states purpose and key details. No wasted words, well 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?
With an output schema present, description needn't detail returns. It sufficiently covers the two comparison scenarios and gives competitor examples. Could be slightly more explicit about which products are eligible, but overall adequate.
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%, but the description adds value by explaining what each comparison_type enum means (Legacy vs Cinematic, vs competitors with examples). This contextualizes parameters beyond their schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool compares Bolot Studio products, with specific comparison types (Legacy Print vs Cinematic Print, or vs competitors like Displate). It clearly defines the action and resources.
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 by listing comparison types and examples, but does not provide explicit guidance on when to use this tool versus siblings like get_product_recommendations or search_products, nor any when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_product_recommendationsGet Product RecommendationsARead-onlyIdempotentInspect
Get personalized product and variant recommendations based on customer intent, budget, recipient profile, room type, and lighting conditions.
| Name | Required | Description | Default |
|---|---|---|---|
| budget | No | Maximum budget in EUR | |
| intent | Yes | Customer intent: gift, home_decor, valentines, birthday_50, memorial, desk_display, home_cinema, etc. | |
| locale | No | Locale code for localized URLs (e.g. 'en', 'pl', 'de') | |
| country | No | ISO 3166-1 alpha-2 or alpha-3 country code for geo-pricing (e.g. 'PL', 'DE', 'GB', 'DEU', 'GBR') | |
| lighting | No | Room lighting: bright, dim, mixed | |
| room_type | No | Room type: living_room, bedroom, office, bathroom, kitchen, entertainment_room | |
| recipient_profile | No | Who is this for: partner, mother, father, man_who_has_everything, woman, couple, pet_lover, photographer, movie_fan |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | No | |
| error | No | |
| message | No | |
| room_advice | No | |
| finish_advice | No | |
| total_matches | No | |
| recommendations | No | |
| active_promotions | No | |
| wall_art_launch_gate | No | |
| address_sign_launch_gate | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with annotations (readOnlyHint=true, idempotentHint=true) but adds little beyond stating the action. It does not describe additional behavioral traits like pagination, result limits, or error handling, but the annotations already cover safety aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence of about 20 words, front-loading the main action and then listing inputs. No redundant or 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?
With 7 parameters and an output schema present, the description covers the core functionality but could be slightly more helpful by noting that recommendations include variants or that results are scored. Still, it is adequate given the output schema fills in return details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description merely lists the parameter names without adding new semantic information beyond what is in the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'personalized product and variant recommendations', and lists the specific inputs (intent, budget, recipient profile, room type, lighting) that distinguish it from sibling tools like search_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 usage for personalized recommendations based on rich context, but does not explicitly state when to use this tool versus alternatives like search_products or compare_products. No when-not-to-use or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_reviews_summaryGet Reviews SummaryARead-onlyIdempotentInspect
Get aggregated customer review statistics and featured review excerpts. Use this when a customer asks about product quality, other customers' experiences, or social proof. Returns ratings, distribution, and highlighted reviews.
| Name | Required | Description | Default |
|---|---|---|---|
| product_handle | No | Product handle: 'the-legacy-print', 'the-cinematic-print', or 'the-address-sign'. Omit for store-wide stats. |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | No | |
| error | No | |
| scope | No | |
| source | No | |
| message | No | |
| available | No | |
| total_reviews | No | |
| average_rating | No | |
| review_platform | No | |
| featured_reviews | No | |
| verified_purchase_count | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint as true, so the description carries minimal burden. It adds that the tool returns 'ratings, distribution, and highlighted reviews,' which is useful but does not disclose additional behaviors like rate limits or authentication needs. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and usage, no unnecessary words. 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 low complexity (one optional parameter, output schema exists), the description sufficiently covers what the tool does and its return types. No additional information is 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?
Schema description coverage is 100%, and the description does not add new meaning beyond the schema's own description of the optional 'product_handle' parameter. The statement about omitting for store-wide stats echoes 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?
Description uses a specific verb ('Get') and resource ('aggregated customer review statistics and featured review excerpts'), and explicitly states when to use it (customer asks about product quality, experiences, social proof). This clearly distinguishes it from sibling tools like 'compare_products' or 'get_product_recommendations'.
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?
Description provides explicit usage context: 'when a customer asks about product quality, other customers' experiences, or social proof.' It does not state when not to use or mention alternatives, but the context is clear enough for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_shipping_estimateGet Shipping EstimateARead-onlyIdempotentInspect
Get estimated delivery time, free shipping threshold, and carrier information for a specific country. Use this when a customer asks about shipping costs or delivery times to their location.
| Name | Required | Description | Default |
|---|---|---|---|
| country_code | Yes | ISO 3166-1 alpha-2 or alpha-3 country code (e.g. 'PL', 'DE', 'GB', 'FR', 'DEU', 'GBR') |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| carrier | No | |
| message | No | |
| returns | No | |
| tracking | No | |
| supported | No | |
| country_code | No | |
| free_shipping | No | |
| shipping_cost | No | |
| delivery_estimate | No | |
| manufacturing_note | No | |
| supported_countries | No | |
| total_estimated_time | No | |
| wall_art_launch_gate | No | |
| tax_duty_handling_note | No | |
| address_sign_launch_gate | No | |
| tax_duty_handling_setup_dependent | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark as readOnly and idempotent. Description adds specifics about what is estimated (delivery time, threshold, carrier). 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 sentences, front-loaded with purpose, then usage. 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?
Single parameter well-described, annotations present, output schema exists. Description covers purpose and usage adequately for a simple lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of country_code. Description does not add extra meaning beyond the schema, which is acceptable.
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?
Clear and specific: 'Get estimated delivery time, free shipping threshold, and carrier information for a specific country.' Distinct from sibling tools, none of which address shipping.
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 this when a customer asks about shipping costs or delivery times to their location.' No explicit when-not-to-use, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_store_infoGet Store InfoARead-onlyIdempotentInspect
Get Bolot Studio brand information, shipping zones, payment methods, and configurator URLs. Essential context for helping customers.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Locale code used when country is not supplied | |
| country | No | ISO 3166-1 alpha-2 or alpha-3 country code for market-visible catalog sizes/prices (e.g. 'DE', 'DEU') |
Output Schema
| Name | Required | Description |
|---|---|---|
| b2b | No | |
| brand | No | |
| error | No | |
| market | No | |
| message | No | |
| products | No | |
| policy_urls | No | |
| finish_guide | No | |
| free_shipping | No | |
| sustainability | No | |
| payment_methods | No | |
| active_promotions | No | |
| configurator_urls | No | |
| quality_assurance | No | |
| agent_instructions | No | |
| shipping_by_country | No | |
| wall_art_launch_gate | No | |
| address_sign_launch_gate | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds specifics about what data is returned (brand, shipping, payment, configurator URLs), providing valuable behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no unnecessary words. Front-loaded with the main purpose.
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, the presence of an output schema, and thorough annotations, the description is complete and sufficient for an AI agent to understand the tool's role.
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 does not add new meaning to parameters beyond the schema descriptions, which are already informative.
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 the tool retrieves store info including brand, shipping, payment, and configurator URLs. It is distinct from sibling tools which focus on products, reviews, etc.
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 phrase 'Essential context for helping customers' implies usage when store-level information is needed. No explicit alternatives or when-not-to-use, but the uniqueness of the tool makes usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_policies_and_faqsSearch Policies and FAQsARead-onlyIdempotentInspect
Search Bolot Studio FAQs and store policies. Covers product questions, sizing, finishes, shipping, returns, and ordering.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (e.g. 'returns', 'shipping to Germany', 'matte vs glossy', 'desk stand') | |
| locale | No | Locale code for localized policy URLs (e.g. 'en', 'pl', 'de') | |
| country | No | ISO 3166-1 alpha-2 or alpha-3 country code for locale-aware policy URLs (e.g. 'PL', 'DE', 'GB', 'DEU', 'GBR') |
Output Schema
| Name | Required | Description |
|---|---|---|
| faqs | No | |
| error | No | |
| message | No | |
| policy_links | No | |
| total_matches | No | |
| shipping_by_country | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-open world behavior. The description adds context on what the search covers but does not disclose additional behavioral traits (e.g., speed, rate limits) 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?
Single sentence that efficiently communicates purpose and scope. No filler 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?
The description adequately covers what the tool does and its scope. With an output schema present, explicit return format is less critical. However, it could briefly mention that results are policy/FAQ texts or links.
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 3 parameters with descriptions. The description adds value by providing example queries ('returns', 'shipping to Germany') and clarifying parameter usage (locale, country). Slightly improved understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches 'Bolot Studio FAQs and store policies' and lists specific covered topics (product questions, sizing, etc.). This distinguishes it from sibling tools like 'search_products' and 'check_photo_compatibility'.
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 for policy and FAQ lookups but does not explicitly state when to use it over alternatives or provide exclusion criteria. No guidance on not using it for product search or other topics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_productsSearch ProductsARead-onlyIdempotentInspect
Search and browse Bolot Studio custom metal photo prints. Returns enriched product data including AI summaries, use-case recommendations, FAQs, competitive positioning, and variant details with dimensions and weight.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search term (e.g. 'metal print', 'gift', 'cinematic') | |
| handle | No | Product handle: 'the-legacy-print', 'the-cinematic-print', or 'the-address-sign' | |
| locale | No | Locale code for localized URLs (e.g. 'en', 'pl', 'de') | |
| country | No | ISO 3166-1 alpha-2 or alpha-3 country code for geo-pricing (e.g. 'PL', 'DE', 'GB', 'DEU', 'GBR') |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| query | No | |
| total | No | |
| handle | No | |
| market | No | |
| message | No | |
| products | No | |
| launch_gate | No | |
| available_handles | No | |
| wall_art_launch_gate | No | |
| address_sign_launch_gate | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, which the description does not contradict. The description adds that the tool returns enriched product data, but does not disclose additional behavioral traits such as rate limits or authentication needs. With annotations covering the safety profile, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose and then lists return data. It is efficient with no wasted words, though it could be slightly more concise by omitting the bullet list of return fields.
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 and comprehensive annotations, the description covers the key aspects: search functionality, resource type, and return value highlights. It provides sufficient context for an agent to understand what the tool does without needing additional detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters thoroughly. The tool description does not add additional meaning beyond what the schema provides. Per the guidelines, baseline is 3 when coverage exceeds 80%.
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 and browse Bolot Studio custom metal photo prints.' It specifies the resource (products) and the action (search/browse), and distinguishes from sibling tools like 'search_products_task' by detailing the enriched data returned, such as AI summaries and recommendations.
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 for searching and browsing products but does not explicitly state when to use this tool over alternatives like 'compare_products' or 'get_product_recommendations'. No guidance on when not to use is provided, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_products_taskSearch Products TaskBInspect
Task-based product search for long-running MCP clients. Use task polling to retrieve the result.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search term (e.g. 'metal print', 'gift', 'cinematic') | |
| handle | No | Product handle: 'the-legacy-print', 'the-cinematic-print', or 'the-address-sign' | |
| locale | No | Locale code for localized URLs (e.g. 'en', 'pl', 'de') | |
| country | No | ISO 3166-1 alpha-2 or alpha-3 country code for geo-pricing (e.g. 'PL', 'DE', 'GB', 'DEU', 'GBR') |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description gives minimal behavioral info (task-based, polling) but omits details like task lifecycle, ID retrieval, or 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?
Two sentences, front-loaded, efficient. Could be slightly more informative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and minimal behavioral description; lacks explanation of task mechanics, response format, or polling procedure.
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; description adds no extra meaning, so baseline score 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?
Clearly states it is a task-based product search for long-running clients, distinguishing it from likely synchronous siblings like search_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?
Implies use for async scenarios with polling, but lacks explicit when-to-use or comparison with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
start_configurationStart ConfigurationARead-onlyIdempotentInspect
Generate a direct URL to the Bolot Studio product configurator with pre-selected options. Optionally pre-select size and/or finish ('matte' or 'glossy'). Valid sizes are product-specific: 'the-legacy-print' accepts 'classic' (30×20) or 'statement' (42×30); 'the-cinematic-print' accepts 'intimate' (21×14), 'classic' (30×20), or 'statement' (42×30); 'the-address-sign' uses templates and ignores size/finish. Use this when the customer is ready to upload their photo and customize their metal print.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Pre-select size. Valid set depends on the product: 'the-legacy-print' → 'classic' or 'statement'; 'the-cinematic-print' → 'intimate', 'classic', or 'statement'. An unsupported size for the chosen product returns an invalid_size_for_product error. Not applicable to the address sign. | |
| finish | No | Pre-select finish. Not applicable to address sign. | |
| locale | No | Locale code (en, de, pl, etc.) | |
| country | No | ISO 3166-1 alpha-2 or alpha-3 country code for market-visible product availability (e.g. 'DE', 'DEU') | |
| product_handle | Yes | Product to configure |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | No | |
| error | No | |
| locale | No | |
| market | No | |
| message | No | |
| product | No | |
| launch_gate | No | |
| valid_sizes | No | |
| instructions | No | |
| pre_selected | No | |
| requested_size | No | |
| configurator_url | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so description adds value by detailing that sizes are product-specific, that address sign ignores size/finish, and that unsupported size returns an error. 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 sentences, no fluff. First sentence states purpose, second gives usage context and key constraints. 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?
Description covers when to use, what it does, and key parameter constraints. Output schema exists to explain return values, so description is complete for agent decision-making.
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%, but the description adds significant meaning: it lists valid size enumerations per product, mentions error cases, and clarifies when finish is not applicable. Examples for locale and country are also helpful.
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 generates a direct URL to the configurator with pre-selected options. It specifies the verb 'generate' and resource 'URL', and distinguishes from sibling tools like check_photo_compatibility 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?
Explicitly says 'Use this when the customer is ready to upload their photo and customize their metal print.' It does not explicitly state when not to use, but the context is clear and no alternative is needed given sibling tools are very different.
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!