Search verified crystal bracelets and source beads, accessories, and raw materials.
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.
Average 3.9/5 across 6 of 6 tools scored.
Each tool has a distinct purpose: building shortlists, fetching product details, sourcing guidance across categories, listing materials, preparing inquiries, and searching. Minor overlap between search and get_product, but descriptions clarify boundaries.
All tools follow a consistent 'crystal_verb_noun' pattern (e.g., build_procurement_shortlist, get_product, list_materials), with clear and predictable naming.
Six tools are well-suited for the crystal sourcing domain, covering search, details, shortlisting, materials listing, guidance, and inquiry preparation without being excessive or insufficient.
The tool set covers the main workflows: searching, retrieving details, building shortlists, listing materials, getting guidance, and preparing inquiries. A minor gap is lack of update/delete operations, but the domain is advisory-focused.
crystal_build_procurement_shortlistBuild Crystal Procurement ShortlistABuild a deterministic shortlist across requested crystal categories. Verified products are limited to catalog bracelets; other categories remain clearly separated advisory items.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| colors | No | ||
| cursor | No | ||
| channel | No | ||
| useCases | No | ||
| materials | No | ||
| packaging | No | ||
| categories | Yes | ||
| destination | No | ||
| contentAssets | No | ||
| targetQuantity | No | ||
| targetTimeline | No |
| Name | Required | Description |
|---|---|---|
| hasMore | Yes | |
| coverage | Yes | |
| warnings | Yes | |
| nextCursor | Yes | |
| sourceUrls | Yes | |
| totalCount | Yes | |
| advisoryItems | Yes | |
| verifiedProducts | Yes | |
| recommendedInquiryFields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description adds 'deterministic' behavior and clarifies that only bracelets are verified products while others are advisory, providing useful context 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?
Two concise sentences, front-loaded with main purpose. Every sentence is meaningful with 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?
Despite having an output schema, the description lacks details on return values, pagination (cursor, limit), and filtering parameters. For a tool with 12 parameters, this is incomplete.
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 12 parameters with 0% description coverage. The description only hints at 'categories' via 'across requested crystal categories', but fails to explain other parameters like colors, useCases, limit, etc. Minimal value added 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 'Build a deterministic shortlist across requested crystal categories', specifying verb (build), resource (shortlist), and scope (categories). It also distinguishes 'verified products are limited to catalog bracelets' and 'other categories remain clearly separated advisory items', differentiating it from sibling tools like crystal_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 building a shortlist with a specific constraint on products, but does not explicitly state when to use this tool versus alternatives like crystal_search_products or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
crystal_get_productGet Crystal ProductAGet one verified bracelet by exact SKU or slug, including materials, image, source URL, related SKUs, and explicit manual-confirmation status for commercial terms.
| Name | Required | Description | Default |
|---|---|---|---|
| sku | No | ||
| slug | No |
| Name | Required | Description |
|---|---|---|
| product | Yes | |
| coverage | Yes | |
| warnings | Yes | |
| sourceUrls | Yes | |
| relatedProducts | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, non-destructive. The description adds value by detailing the return fields (materials, image, source URL, related SKUs, confirmation status) and the 'explicit manual-confirmation status' trait, which goes 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?
Single sentence, front-loaded with action and scope, no redundant information. Every part contributes to understanding the tool's purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple optional parameters and existence of an output schema, the description covers key return fields. However, it lacks explicit guidance that at least one parameter is needed, and 'verified bracelet' could be clarified. 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 coverate is 0%, so description must compensate. It mentions 'exact SKU or slug' implying exact match and that at least one is required, but does not clarify behavior if both are provided or differences between sku and slug. Provides minimal additional meaning.
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 'Get one verified bracelet by exact SKU or slug', specifying the action (Get), resource (verified bracelet), and identifier types. It distinguishes from sibling tools like crystal_search_products, which is for searching rather than exact retrieval.
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 when to use (when you have an exact SKU or slug), but does not explicitly state when not to use or mention alternatives. No guidance on excluding search_products for broader queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
crystal_get_sourcing_guidanceGet Crystal Sourcing GuidanceAGet source-linked procurement checks for bracelets, loose beads, accessories, or raw materials. Adjacent categories are advisory only and never return invented inventory or SKUs.
| Name | Required | Description | Default |
|---|---|---|---|
| channel | No | ||
| category | Yes | ||
| packaging | No | ||
| destination | No | ||
| contentAssets | No | ||
| proofRequirements | No |
| Name | Required | Description |
|---|---|---|
| category | Yes | |
| coverage | Yes | |
| warnings | Yes | |
| checklist | Yes | |
| sourceUrls | Yes | |
| shortAnswer | Yes | |
| comparisonCriteria | Yes | |
| requiresManualConfirmation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. The description adds valuable context by stating the tool never returns invented inventory or SKUs, reinforcing the openWorldHint=false and increasing trustworthiness. No contradictions 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 concise sentences: first defines purpose and scope, second adds an important constraint. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters with 0% schema coverage and an output schema (not shown), the description is minimal. It covers the core purpose and category constraint but omits details on other parameters and return format. Adequate for simple cases but lacks depth for complex parameter usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only hints at the 'category' parameter by listing its valid values. Other parameters (channel, packaging, destination, contentAssets, proofRequirements) are not explained, leaving the agent to infer their purpose from names alone. This is insufficient to compensate for the missing 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?
Description clearly states the tool retrieves 'source-linked procurement checks' for specific categories (bracelets, beads, accessories, raw materials). It distinguishes itself from siblings by focusing on procurement guidance for these exact categories and explicitly states what it does not return (invented inventory/SKUs).
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 specifies which categories to use and warns that adjacent categories are advisory only, providing some usage context. However, it does not mention when to use alternatives or provide explicit when-not conditions relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
crystal_list_materialsList Bracelet MaterialsAList normalized materials and real SKU counts from the current verified bracelet catalog. Counts do not claim coverage for loose beads, components, or raw crystals.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| cursor | No |
| Name | Required | Description |
|---|---|---|
| hasMore | Yes | |
| coverage | Yes | |
| warnings | Yes | |
| materials | Yes | |
| nextCursor | Yes | |
| sourceUrls | Yes | |
| totalCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's main behavioral addition is the data source specification ('current verified bracelet catalog') and the disclaimer about coverage. This adds some value but does not disclose pagination or sorting 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 two sentences, front-loads the primary action and resources, and avoids unnecessary words. Every sentence adds value: the first states what it does, the second clarifies what it does not cover.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool has three parameters with no documentation. The description covers data scope and limitations but completely omits parameter usage, which is essential for invocation. The agent cannot determine how to use 'query' or the pagination cursor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides no explanation for any of the three parameters (limit, query, cursor). The agent must infer meaning from names alone, which is insufficient for proper usage. The description should at least mention how 'query' is used for filtering materials.
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 uses specific verbs ('list') and resources ('normalized materials and real SKU counts') and clearly scopes to 'current verified bracelet catalog'. It also explicitly states what it does not cover (loose beads, components, raw crystals), distinguishing it from sibling tools like crystal_search_products which might cover a broader catalog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on the tool's scope (verified bracelet catalog only) and its limitations (counts not covering other categories). While it does not explicitly name alternative tools or provide 'when to use / when not to use' guidance, the boundary descriptions implicitly guide proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
crystal_prepare_inquiryPrepare Crystal Wholesale InquiryAValidate any supplied bracelet SKUs and draft an English wholesale inquiry. This read-only tool never sends, stores, or submits buyer data and never invents price, MOQ, stock, lead time, or certificates.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| skus | No | ||
| No | |||
| channel | No | ||
| company | No | ||
| country | No | ||
| quantity | No | ||
| materials | No | ||
| packaging | No | ||
| requirements | No | ||
| contentAssets | No | ||
| targetTimeline | No | ||
| proofRequirements | No |
| Name | Required | Description |
|---|---|---|
| body | Yes | |
| subject | Yes | |
| coverage | Yes | |
| warnings | Yes | |
| draftOnly | Yes | |
| validSkus | Yes | |
| sourceUrls | Yes | |
| missingFields | Yes | |
| classification | Yes | |
| submissionTarget | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds beyond annotations by stating it never invents price, MOQ, stock, lead time, or certificates. This complements the readOnlyHint and idempotentHint annotations, providing clear behavioral boundaries.
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 purpose, and no redundant 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?
For a tool with 13 optional parameters, an output schema is present, but the description lacks guidance on how each parameter affects the drafted inquiry. The agent can infer basic usage but may struggle with optional 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?
With 0% schema description coverage, the description must explain parameters. It only mentions 'bracelet SKUs', leaving the other 12 parameters (name, email, channel, etc.) unexplained. Parameter names are self-explanatory, but the lack of detail hampers correct invocation.
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 validates bracelet SKUs and drafts an English wholesale inquiry. It uses specific verbs ('validate', 'draft') and distinguishes the tool from siblings like crystal_search_products and crystal_build_procurement_shortlist.
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 says the tool is read-only and never sends or stores data, guiding the agent on safe usage. However, it does not mention explicit alternatives or when not to use it, though sibling tools are listed separately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
crystal_search_productsSearch Crystal ProductsASearch the verified 104-SKU bracelet catalog by SKU, name, material, or theme. Beads, accessories, and raw materials return advisory-only coverage with no fabricated SKUs. Commercial terms always require manual confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| cursor | No | ||
| channel | No | ||
| category | No | bracelets | |
| useCases | No | ||
| materials | No | ||
| benefitTags | No |
| Name | Required | Description |
|---|---|---|
| hasMore | Yes | |
| coverage | Yes | |
| products | Yes | |
| warnings | Yes | |
| nextCursor | Yes | |
| sourceUrls | Yes | |
| totalCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds valuable behavioral context beyond annotations: discloses advisory-only coverage for non-bracelet categories, fabricated SKU absence, and need for manual confirmation on commercial terms. No contradictions 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 concise sentences: first states core purpose, second adds critical behavioral nuance. 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?
Adequately describes the search tool's purpose and data quality, but given 8 parameters and no per-parameter guidance, the description lacks depth for rich filtering. Sufficient for simple queries but not for complex ones.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description only vaguely mentions searchable fields (SKU, name, material, theme) but does not explain the other parameters like limit, cursor, channel, useCases, benefitTags, which are left opaque.
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 'search' and resource 'verified 104-SKU bracelet catalog', and distinguishes from sibling tools like crystal_get_product and crystal_list_materials by specifying catalog scope and coverage limitations.
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 usage for searching the bracelet catalog, but does not explicitly state when to use alternatives like crystal_get_product for single product lookup or crystal_build_procurement_shortlist for shortlisting.
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.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.