Crystals MCP Server by RoxyAPI
Server Details
Crystal meanings, healing properties, chakra and birthstone lookups for AI agents.
- 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.1/5 across 12 of 12 tools scored.
Each tool has a unique, clearly defined purpose: general listing, filtering by specific attributes (chakra, zodiac, element, etc.), detail retrieval, search, random, daily pick, and pairings. There is no overlap or ambiguity among the 12 tools.
All tool names follow a consistent verb_noun snake_case pattern with 'get_crystals_' prefix (except 'post_crystals_daily', which still maintains the prefix). The naming is uniform and predictable, aiding agent selection.
With 12 tools, the server is well-scoped for a crystal database API. Each tool serves a distinct query or filter, providing coverage without unnecessary bloat.
The tool set covers all major use cases: listing with filters (chakra, zodiac, element, color, planet), detail retrieval, search, random, daily pick, and pairings. No obvious gaps for a read-only API; it's comprehensive for building crystal-related applications.
Available Tools
12 toolsget_crystalsList All CrystalsAInspect
Retrieve healing crystals and gemstones with pagination. Supports optional filtering by chakra, zodiac sign, element, color, or planet. Returns minimal summary fields per crystal. Use the detail endpoint for full healing properties. Perfect for building crystal explorer apps, healing stone guides, and personalized crystal recommendation engines.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English. | en |
| color | No | Filter by crystal color (partial match, case-insensitive). E.g., "pink", "green", "blue", "purple". Use GET /colors for valid values. | |
| limit | No | Maximum items to return per page. Range: 1-100, default 20. | |
| chakra | No | Filter by chakra association, case-insensitive. Valid values: Root, Sacral, Solar Plexus, Heart, Throat, Third Eye, Crown. | |
| offset | No | Number of items to skip for pagination. Default 0. | |
| planet | No | Filter by planetary association (partial match, case-insensitive). E.g., "Venus", "Moon", "Jupiter". Use GET /planets for valid values. | |
| zodiac | No | Filter by zodiac sign, case-insensitive. Valid values: aries, taurus, gemini, cancer, leo, virgo, libra, scorpio, sagittarius, capricorn, aquarius, pisces. | |
| element | No | Filter by elemental association, case-insensitive. Valid values: Earth, Water, Fire, Air, Storm. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It covers pagination and filtering behavior but omits details on error handling, rate limits, or what happens with no results.
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 four sentences with no extraneous information. The main action is front-loaded in the first sentence.
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 (8 optional params, no output schema), the description covers pagination, filtering, and points to a detail endpoint. It lacks explicit mention of response field structure, but is adequate for a list 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 description coverage is 100%, so the baseline is 3. The description adds marginal value by grouping filter options, but does not provide significantly new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves healing crystals with pagination and filtering, and mentions returning minimal summary fields. It distinguishes from a detail endpoint but does not explicitly differentiate from sibling filter-only endpoints like get_crystals_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using the detail endpoint for full properties, providing an alternative. However, it does not specify when to use specialized sibling endpoints (e.g., get_crystals_chakra) instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_crystals_birthstone_monthBirthstone Crystals by MonthAInspect
Get the traditional birthstone crystals for a given birth month. Returns summary data for each crystal. Use the /crystals/:id detail endpoint for full healing properties. Based on GIA-authoritative birthstone assignments. Perfect for birthday gift recommendations, personalized crystal suggestions, and birthstone jewelry applications.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English. | en |
| month | Yes | Birth month as a number from 1 (January) to 12 (December). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool is read-only (returns summary data) and based on GIA assignments. However, it does not mention error handling, rate limits, or authentication needs, which would be helpful for a complete behavioral profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences. First sentence states the primary action, second sentence clarifies output and alternative, third sentence adds context and use cases. It is front-loaded with the key information and has no unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 well-described parameters, no output schema), the description covers purpose, return type, alternative endpoint, and use cases. It mentions GIA authority. However, it could be more explicit about the output structure, but overall it is 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?
The input schema already describes both parameters with 100% coverage. The description adds no new semantic value for parameters beyond restating 'birth month'. The mention of 'traditional' adds context but is not parameter-specific, so the description does not improve upon 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 'Get the traditional birthstone crystals for a given birth month' with a specific verb and resource. It distinguishes from sibling tools like get_crystals (general list) and get_crystals_zodiac_sign (by zodiac) by focusing on birth month and mentioning an alternative endpoint for full details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using '/crystals/:id' for full healing properties, guiding when to choose an alternative. It also provides use cases (birthday gifts, personalized suggestions). However, it does not explicitly list exclusions or conditions for not using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_crystals_chakraCrystals by ChakraAInspect
Get healing crystals and gemstones that resonate with a specific chakra energy center. Returns summary data for each crystal. Use the /crystals/:id detail endpoint for full healing properties. Supports all 7 primary chakras: Root, Sacral, Solar Plexus, Heart, Throat, Third Eye, and Crown. Essential for crystal grid building, chakra balancing, and energy healing applications.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English. | en |
| limit | No | Maximum items to return per page. Range: 1-30, default 20. | |
| chakra | Yes | Chakra name, case-insensitive (e.g., heart, Heart, HEART all work). Valid: Root, Sacral, Solar Plexus, Heart, Throat, Third Eye, Crown. | |
| offset | No | Number of items to skip for pagination. Default 0. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must compensate. It states the tool returns 'summary data for each crystal' and supports all 7 primary chakras. However, it does not disclose pagination behavior (though schema indicates limit/offset) or mention rate limits, authentication, or output format details. This is minimally adequate for a simple filtered list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, each serving a distinct purpose: purpose, return type with link to detail endpoint, and usage context. It is front-loaded with the key action, and there is no redundant or filler language.
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 no output schema, the description hints at the return format ('summary data') but does not specify fields or ordering. It covers the tool's place among siblings and its typical use cases. For a simple 4-parameter tool, this is fairly complete, though a note on default sort order would improve it.
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, with each parameter including clear descriptions and examples. The tool description adds some value: it notes the chakra parameter is case-insensitive and lists all 7 options, and it mentions language fallback for unsupported translations. However, for limit and offset, the description adds no new meaning 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?
The description clearly states the tool retrieves healing crystals for a specific chakra, using specific verbs ('Get healing crystals and gemstones that resonate with a specific chakra energy center'). It differentiates from siblings like get_crystals (all crystals) and get_crystals_colors (by color), and mentions the detail endpoint for full properties. The title and description consistently convey the tool's purpose.
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 use cases ('Essential for crystal grid building, chakra balancing, and energy healing applications') and directs users to the /crystals/:id endpoint for detailed healing properties, which serves as an alternative for more information. However, it does not explicitly state when not to use this tool or compare it to other filtering tools like get_crystals_element or get_crystals_zodiac_sign.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_crystals_colorsList Crystal ColorsAInspect
List all unique crystal colors available in the database. Use these values with the color filter on GET /crystals to find crystals by color. Essential reference endpoint for building color-based crystal browsing, visual crystal pickers, and filtering UI.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description fully discloses behavior: it lists unique colors, a simple read operation with no side effects.
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 superfluous 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 no output schema and zero parameters, the description fully covers what the tool does and how to use it, supported by sibling differentiation.
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?
No parameters; description adds no parameter info because none needed. Baseline 4 for zero-parameter tools.
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 lists unique crystal colors and explicitly differentiates from siblings by explaining how the output is used with GET /crystals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Use these values with the color filter on GET /crystals' and mentions reference for browsing UI, making usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_crystals_elementCrystals by ElementAInspect
Get healing crystals and gemstones associated with a specific natural element. Returns summary data for each crystal. Use the /crystals/:id detail endpoint for full healing properties. Supports five elements: Earth, Water, Fire, Air, and Storm. Essential for elemental crystal selection, nature-based healing, and element-themed crystal grid applications.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English. | en |
| limit | No | Maximum items to return per page. Range: 1-30, default 20. | |
| offset | No | Number of items to skip for pagination. Default 0. | |
| element | Yes | Element name, case-insensitive (e.g., water, Water, WATER all work). Valid: Earth, Water, Fire, Air, Storm. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It states it returns 'summary data' implying non-destructive read. However, it lacks details on pagination behavior, rate limits, or that results are limited to the specified element. The case-insensitivity is only in schema, not description.
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?
Three sentences with clear flow: purpose, clarification of summary vs detail, and use cases. No extraneous information. Properly 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 4 parameters, full schema coverage, and no output schema, the description is adequately complete. It identifies the filter, return type, and use cases. Could mention pagination or sorting, but schema covers pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds value by mentioning 'summary data' but doesn't elaborate on parameters beyond what the schema already provides. The schema descriptions are thorough, so the description adds minimal extra 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 it gets healing crystals associated with a natural element, using specific verb 'Get'. It distinguishes from siblings by the filter criterion and mentions it returns summary data, not full properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly advises using the /crystals/:id endpoint for full healing properties, implying when not to use this tool. It also lists applications like elemental crystal selection and element-themed grids. However, it doesn't directly compare to sibling tools like get_crystals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_crystals_idGet Crystal Healing PropertiesAInspect
Get complete healing properties and metaphysical data for a specific crystal or gemstone. Returns spiritual, emotional, and physical healing interpretations along with chakra associations, zodiac connections, elemental properties, and crystal pairing recommendations. Authoritative interpretations covering all major healing crystals.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | URL-safe crystal identifier, case-insensitive (e.g., "amethyst", "Amethyst", "rose-quartz" all resolve). Must match an entry in the database. | |
| lang | No | Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English. | en |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the return type (healing properties, chakra, zodiac, etc.) and notes the authoritative coverage. It does not mention side effects or limitations, but for a read-only lookup, this is fairly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first defines the action and resource, second enumerates the returned categories. No redundant wording, front-loaded with 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 no output schema, the description adequately outlines the return data (spiritual, emotional, physical interpretations, etc.). It covers the key aspects for a single-crystal lookup, though some might want more detail on data format.
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% (both parameters have descriptions). The description reiterates the crystal identifier nature but adds no new meaning 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?
The description clearly states the tool retrieves complete healing properties for a specific crystal, using the verb 'Get' and specifying the resource. It distinguishes from siblings by focusing on a single crystal ID, as opposed to search or random tools.
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 a specific crystal by ID but does not explicitly state when to use this versus alternatives like get_crystals_search or get_crystals_random. No exclusions or when-not-to-use 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_crystals_pairings_idCrystal PairingsAInspect
Get crystals that pair well with a given crystal for enhanced healing combinations. Returns the source crystal along with its recommended companion stones and their properties. Essential for crystal grid building, healing combination recommendations, and crystal shop cross-sell features.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | URL-safe crystal identifier to find pairings for, case-insensitive (e.g., "amethyst", "Amethyst", "rose-quartz" all resolve). | |
| lang | No | Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English. | en |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. States return includes source crystal and companion stones with properties, but lacks details on edge cases (e.g., no pairings found, response structure 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 efficient sentences: first defines core purpose, second adds context and use cases. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description outlines return content. Adequate for a list-retrieval tool with simple parameters. Could mention response format or pagination if applicable, but fine for this scope.
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% for both parameters (id, lang). Description does not add meaningful info beyond the schema descriptions, so baseline 3 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?
Description clearly states 'Get crystals that pair well with a given crystal' with specific verb and resource. Distinguished from siblings by focusing on pairings, not other crystal properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases (crystal grid building, healing combinations, cross-sell features). Does not explicitly state when not to use or name alternatives, but context from sibling tools makes this clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_crystals_planetsList Crystal PlanetsAInspect
List all unique planetary associations available in the database. Use these values with the planet filter on GET /crystals to find crystals by ruling planet. Essential reference endpoint for astrology app builders who want to recommend crystals based on planetary placements in a birth chart.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It clearly describes the read-only operation of listing unique planetary associations. Could mention if authentication or rate limits apply, but not strictly needed for a simple list endpoint.
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?
Three concise sentences with no fluff. Front-loads purpose, then usage, then audience. Every sentence 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?
Sufficient for a simple list tool. Explains output usage and audience. Could specify output format (e.g., array of strings), but not critical for selection.
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?
No parameters, schema coverage 100%. Description adds value by explaining how to use the output (with filter), justifying baseline 4.
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 lists all unique planetary associations, distinguishing it from sibling tools like 'get_crystals' which filter crystals. Specifies it is a reference endpoint for astrology app builders.
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 tells agents to use the output values with the planet filter on GET /crystals, providing clear context for when and how to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_crystals_randomRandom CrystalAInspect
Get a randomly selected healing crystal as a discovery teaser. Returns a different crystal on each request (non-deterministic). Use the /crystals/:id detail endpoint for complete spiritual, emotional, and physical healing properties. Perfect for crystal discovery features, surprise crystal picks, crystal roulette games, and exploration widgets. For a deterministic daily crystal that is the same for all users on a given date, use the /daily endpoint instead.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English. | en |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states non-deterministic behavior but does not describe the output structure or potential edge cases like empty results. The lang parameter behavior is covered in schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with five sentences, front-loading the main action. The 'Perfect for' sentence adds useful context without excessive fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and no output schema, the description covers non-deterministic behavior, language support, and alternatives. It is adequate for the intended use cases.
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% for the single 'lang' parameter, so the baseline is 3. The description adds no extra parameter information 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 returns a randomly selected healing crystal as a discovery teaser. It distinguishes from siblings by mentioning the /daily endpoint for deterministic daily crystals and the /crystals/:id endpoint for full details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends use cases like crystal discovery features and surprise picks. It also specifies when not to use (for deterministic daily crystal) and suggests an alternative endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_crystals_searchSearch CrystalsAInspect
Search for healing crystals by keyword or name. Matches against crystal names, healing keywords, descriptions, and spiritual/emotional/physical meaning fields. Returns summary data for each crystal. Use the /crystals/:id detail endpoint for full healing properties. Useful for building crystal search bars, keyword-based recommendation features, and healing property lookups.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query (2-50 characters). Matches against crystal names, keywords, descriptions, and meaning fields. Case-insensitive partial matching. | |
| lang | No | Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English. | en |
| limit | No | Maximum items to return per page. Range: 1-50, default 20. | |
| offset | No | Number of items to skip for pagination. Default 0. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: returns summary data, matches across multiple fields, supports language fallback for non-English queries. It accurately portrays a read-only search operation.
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 compact at 3 sentences plus one line of guidance and one line of use cases. It front-loads the core action. Slightly repetitive in places, but clear.
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 no output schema and 4 parameters, the description covers return type, searchable fields, and alternative endpoint. Pagination behavior is implied by schema but not explicitly described, which is a minor gap.
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 significant meaning beyond the schema's own parameter descriptions, as both explain matching behavior and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for healing crystals by keyword or name, and specifies it matches against multiple fields. This differentiates it from sibling tools that filter by specific attributes like chakra or color.
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 explains when to use this tool (general search) and provides a clear alternative: use the /crystals/:id endpoint for full details. It also lists use cases like building search bars, but doesn't explicitly exclude cases, which is why it's a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_crystals_zodiac_signCrystals by Zodiac SignAInspect
Get healing crystals and gemstones associated with a specific zodiac sign. Returns summary data for each crystal. Use the /crystals/:id detail endpoint for full healing properties. Supports all 12 zodiac signs from Aries through Pisces. Perfect for personalized crystal recommendations based on astrological birth chart data.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English. | en |
| sign | Yes | Zodiac sign name, case-insensitive (e.g., pisces, Pisces, PISCES all work). Valid: aries, taurus, gemini, cancer, leo, virgo, libra, scorpio, sagittarius, capricorn, aquarius, pisces. | |
| limit | No | Maximum items to return per page. Range: 1-30, default 20. | |
| offset | No | Number of items to skip for pagination. Default 0. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It states the tool returns summary data and directs users to the detail endpoint for full properties. This provides some behavioral context but lacks specifics on what the summary data includes (e.g., names, properties) and does not mention authentication, rate limits, or pagination beyond schema hints. 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 four sentences, each adding value: purpose, output type, alternative endpoint, and use case. It is front-loaded and concise with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains that the tool returns summary data. The parameters are fully described in the schema. The description provides enough context for an agent to decide to use this tool for zodiac-based recommendations, though it could mention that results are paginated (implicit via limit/offset) or the default ordering.
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 well-documented parameters and examples. The description does not add significant meaning beyond the schema; it only reiterates that all 12 signs are supported. Baseline of 3 is correct.
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 gets healing crystals for a specific zodiac sign, with a specific verb and resource. It distinguishes from siblings by focusing on zodiac sign and mentions the endpoint for full details. It is unambiguous and comprehensive.
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 tells when to use this tool (for personalized recommendations based on zodiac) and explicitly points to the /crystals/:id endpoint for full healing properties. This provides good guidance, though it could be more explicit about when not to use it compared to other sibling tools like birthstone or chakra.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
post_crystals_dailyDaily CrystalAInspect
Get the crystal of the day as a discovery teaser. Returns a deterministic crystal based on the current date (or a provided seed date), ensuring all users see the same crystal for any given day. Use the /crystals/:id detail endpoint for complete spiritual, emotional, and physical healing properties. Perfect for daily guidance features, push notifications, wellness app widgets, and crystal journal integrations.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date for the reading in YYYY-MM-DD format. Defaults to today (UTC). Useful for viewing past daily readings or pre-generating future ones. | |
| lang | No | Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English. | en |
| seed | No | Optional seed for reproducible readings. Same seed + same date = same crystal every time. Pass any unique identifier (userId, email hash, session token). Omit for anonymous daily readings. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description responsibly discloses determinism based on date/seed and that it returns a teaser (not full properties). It does not mention rate limits, authentication, or caching, but covers key behavioral aspects for a simple read operation.
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 extremely concise with two sentences plus a use-case list. It is front-loaded with the main action and purpose, and 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 no output schema, the description adequately explains the return value as a teaser crystal and points to the detail endpoint for full properties. It covers determinism and use cases, making it sufficiently complete for a simple 3-parameter 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%, so the schema already documents all parameters. The description reinforces determinism and date/seed dependency but adds no new meaning beyond what the schema provides, justifying the baseline score of 3.
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 returns a deterministic crystal of the day as a discovery teaser, distinguishing it from the detail endpoint and sibling tools like get_crystals_random.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It lists ideal use cases (daily guidance, push notifications, widgets, journals) and implies that for full properties the detail endpoint should be used. However, it doesn't explicitly contrast with sibling tools like get_crystals_random or provide when-not-to-use scenarios.
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!