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. | |
| compact | No | Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {"__cols":[field names],"__rows":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON. | |
| 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?
No annotations provided, but description discloses pagination, filtering, compact parameter, and that it returns minimal summary fields. Lacks explicit read-only or safety statements, but overall 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?
Three concise sentences front-loading main action and filters, no 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 no output schema and many filters, description adequately explains what is returned and directs to detail endpoint; pagination and compact flag are covered.
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 params, description adds context about return shape (minimal summary, pagination) and purpose of compact parameter, adding value 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?
Description states 'Retrieve healing crystals and gemstones with pagination' with specific filters (chakra, zodiac, element, color, planet) and distinguishes from sibling tools (e.g., detail endpoint, get_crystals_chakra).
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 the detail endpoint for full healing properties' and targets use cases like 'crystal explorer apps, healing stone guides, and personalized crystal recommendation engines.'
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). | |
| compact | No | Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {"__cols":[field names],"__rows":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description indicates it returns summary data (implied read-only) but does not explicitly state behavioral traits like rate limits or side effects. Adequate for a straightforward data retrieval 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?
Three sentences, no redundant information. First sentence states purpose, second provides alternative, third adds authority and use cases. Slightly more verbose than necessary but still concise.
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 clarifies it returns summary data per crystal and references GIA authority. For a simple lookup tool with many siblings, it provides enough context to understand what the tool returns and its 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%, so baseline is 3. Description does not add significant meaning beyond what the schema already provides for parameters like month, lang, and compact. No extra value added.
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 the action 'Get the traditional birthstone crystals for a given birth month' and distinguishes from sibling tools like get_crystals_zodiac_sign and get_crystals_chakra by focusing on birth month. Includes specific use cases.
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 when to use an alternative endpoint ('Use the /crystals/:id detail endpoint for full healing properties') and mentions suitable contexts like birthday gift recommendations. Lacks explicit when-not-to-use but provides clear guidance.
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. | |
| compact | No | Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {"__cols":[field names],"__rows":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers that it returns summary data and supports all 7 chakras. However, it does not disclose pagination behavior, error handling, or idempotency, leaving some behavioral aspects implicit.
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, front-loaded with purpose, clear guidance, and context. 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?
Given 5 parameters with full schema descriptions and no output schema, the description explains the tool's purpose, data type (summary), and usage context well. It could be slightly more explicit about the paginated list structure, but it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description adds minimal extra value beyond listing chakras and mentioning summary data, so 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 gets healing crystals for a specific chakra and returns summary data. It distinguishes from the detail endpoint and from sibling filter tools by specifying the chakra focus.
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 directs users to the /crystals/:id detail endpoint for full properties, and mentions applicability to crystal grid building and chakra balancing. Lacks explicit guidance on when not to use it, but context is clear.
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 |
|---|---|---|---|
| compact | No | Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {"__cols":[field names],"__rows":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. However, it only states the purpose and does not disclose any behavioral traits (e.g., read-only, safe, 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: first states the function, second explains usage. No redundant information.
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 simple list tool with one well-documented parameter, the description is nearly complete. It lacks an explicit mention of the return format (e.g., array of strings), but that is implied.
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%, and the schema already describes the compact parameter in detail. The description adds no additional meaning beyond the schema, so baseline score of 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 the tool lists unique crystal colors and distinguishes it from sibling tools by positioning it as an essential reference endpoint for color-based browsing and filtering.
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?
Usage is explicitly linked to the color filter on GET /crystals, providing clear context. No exclusions or alternatives are mentioned, but the use case is well-defined.
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. | |
| compact | No | Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {"__cols":[field names],"__rows":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON. | |
| 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?
No annotations are provided, so the description must carry the full burden. It explains that the element is case-insensitive, describes pagination parameters (offset, limit), and details the compact mode's behavior and token savings. It does not cover ordering, error handling, or rate limits, but given the schema's completeness and the provided details, a 4 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 compact paragraph of four sentences with no fluff. It starts with the core action, adds output description, provides usage guidance, and lists use cases—all essential information. Every sentence contributes meaningfully, earning a 5.
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 tool has 5 parameters (100% schema coverage) and no output schema. The description explains the 'summary data' nature and pagination, but it does not describe the return fields, order, or error conditions, leaving the agent somewhat in the dark about the response format. For a tool with moderate complexity, a 3 is fair.
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 baseline is 3. The description adds value by mentioning the five elements and directing to the detail endpoint, but it does not significantly enhance understanding beyond the schema's own parameter descriptions (e.g., compact explanation is already in schema). Hence, a 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 uses a specific verb ('Get') and clearly identifies the resource ('healing crystals and gemstones associated with a specific natural element'). It explains the output ('summary data') and distinguishes itself by specifying the element filter, which differentiates it from sibling tools that filter by chakra, birthstone, 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 description explicitly states when to use this tool ('essential for elemental crystal selection, nature-based healing, and element-themed crystal grid applications') and tells the agent to use the detail endpoint for full properties. However, it does not provide explicit exclusionary guidance (e.g., when NOT to use this tool compared to siblings), so it earns 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_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 |
| compact | No | Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {"__cols":[field names],"__rows":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It describes what data is returned but does not mention read-only nature, error handling, or rate limits. It is adequate but lacks depth.
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-loading the main purpose. It is concise and efficient, though could be slightly more structured.
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 fully explains what is returned: spiritual, emotional, physical healing interpretations, chakra, zodiac, element, and pairings. It is complete for a comprehensive crystal 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 description coverage is 100%, and the tool's description does not add new meaning beyond the schema. The schema already explains parameters well, so baseline 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 it gets 'complete healing properties and metaphysical data for a specific crystal or gemstone,' specifying the verb and resource. It distinguishes itself from sibling tools (e.g., get_crystals_chakra) by emphasizing comprehensiveness.
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 this tool (when you need complete data for one crystal), but it does not explicitly state when not to use it or mention alternatives. Given sibling tools, the context is clear but not explicit.
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 |
| compact | No | Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {"__cols":[field names],"__rows":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility for behavioral disclosure. It states what is returned (source crystal and companion stones) but does not mention read-only nature, authentication, rate limits, or error handling (e.g., missing ID). The description adds basic behavioral context but leaves gaps.
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, front-loaded with the primary action, then details on return, then use cases. Every sentence contributes meaning with no redundancy or filler.
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 no annotations, the description adequately explains the tool's input (a crystal identifier) and output (source + companion stones). However, it omits details like pagination, error responses, or what happens if the input crystal has no pairings. For a simple lookup tool, this is sufficient but not exhaustive.
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 all three parameters, so the schema already documents each parameter's description, default, and enum. The tool description adds no further parameter-specific information, only an overall goal. Thus, per guidelines, 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 uses a specific verb 'Get' and resource 'crystals that pair well with a given crystal', clearly distinguishing it from sibling tools like 'get_crystals' (list all) or 'get_crystals_id' (single crystal). It also lists use cases (crystal grid building, healing recommendations, cross-sell), reinforcing its 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 implies when to use (when needing pairings for a given crystal) and mentions use cases, but does not explicitly state when not to use or name alternatives among sibling tools. It provides clear context, but no exclusions or comparisons.
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 |
|---|---|---|---|
| compact | No | Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {"__cols":[field names],"__rows":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON. |
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 states the tool lists unique values but does not disclose ordering, pagination, or other behavioral traits like whether it's safe or idempotent. The information is adequate but minimal.
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 the core action, second adds usage context and audience. 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?
For a simple list endpoint with one optional parameter and no output schema, the description covers purpose, usage, and audience. It could mention output format or sort order for completeness, but it's not severely lacking.
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 compact parameter, with a detailed schema description. The tool description adds no additional meaning about the parameter beyond the schema, so 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 explicitly states the tool lists all unique planetary associations and specifies its use as a reference for the planet filter on GET /crystals. It clearly distinguishes itself from sibling tools like get_crystals_chakra or get_crystals_zodiac.
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 users to use the output as filter values for another endpoint, and it identifies the target audience (astrology app builders). However, it does not explicitly exclude alternative tools or mention when not to use it, though the sibling tools are distinct enough.
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 |
| compact | No | Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {"__cols":[field names],"__rows":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It mentions non-deterministic returns and hints at crystal data, but lacks specifics on failure modes or rate limits. Still transparent overall.
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?
Brief yet comprehensive: three sentences cover purpose, usage, and differentiation. 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?
No output schema, but description explains what is returned (random crystal) and provides alternative for deterministic crystal. Could mention data shape briefly, but sufficient for a random 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%, baseline 3. Description adds value by detailing the lang parameter's fallback behavior and explains the compact parameter's token optimization in depth.
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 that the tool returns a randomly selected healing crystal as a discovery teaser, and emphasizes non-deterministic behavior. Differentiates from the /daily endpoint explicitly.
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 lists use cases (discovery, surprise picks, roulette games) and tells when to use an alternative (daily crystal, use /daily 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. | |
| compact | No | Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {"__cols":[field names],"__rows":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions matching fields and returns summary data, but does not specify pagination, rate limits, or auth. Compact parameter token savings is a good extra. Adequate but not comprehensive.
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, front-loaded with key action. No fluff; each sentence adds distinct value: action, matching scope, return/usage guidance.
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?
Describes search behavior and mentions detail endpoint, but does not explain pagination or return format. With 5 params and many sibling tools, could be more complete, but schema covers parameter 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 has 100% description coverage, so baseline 3. Description adds context for 'q' (matching fields) and mentions summary data, but other params are not elaborated 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?
Clearly states the action (search), resource (crystals), and scope (by keyword/name across multiple fields). Differentiates from the detail endpoint and sibling tools like get_crystals_chakra 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?
Provides explicit guidance: use the /crystals/:id endpoint for full details. Also mentions use cases (search bars, recommendations). Does not explicitly contrast with all sibling tools but sufficient.
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. | |
| compact | No | Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {"__cols":[field names],"__rows":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: returns summary data, supports all 12 signs, language support, and pagination via limit/offset. The compact parameter is explained thoroughly. No annotations provided, so burden is on description; it covers read-only nature and response shape without 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?
Concise three-sentence structure: first sentence states purpose, second gives usage guidance, third contextualizes. No redundant information; 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?
Given 5 parameters and no output schema, the description is quite complete: explains purpose, return type (summary), pagination hints, language support, and compact format. Could be more explicit about pagination behavior (e.g., page size), 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% with detailed descriptions for each parameter. The description adds value beyond schema by explaining the overall return type and directing to the detail endpoint for full properties. This contextualizes the parameters effectively.
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 verb ('Get') and resource ('healing crystals and gemstones associated with a specific zodiac sign'). It specifies returns summary data and distinguishes from the /crystals/:id detail endpoint, directly differentiating from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use the detail endpoint for full healing properties, providing clear when-to-use guidance. Also mentions use case (personalized crystal recommendations based on astrological birth chart data). Slightly less explicit about when not to use but differentiation via sibling context is clear.
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. | |
| compact | No | Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {"__cols":[field names],"__rows":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses deterministic behavior based on date and optional seed, and explains the compact parameter's effect on output format. No annotations exist, so the description adequately covers behaviors.
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 clear, front-loaded sentences. Every sentence serves a purpose—explaining what it does, deterministic nature, comparison to detail endpoint, and example use cases.
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?
While the description covers purpose and usage, it lacks details about the return shape (e.g., fields like name, properties). Given no output schema, more specifics on output structure would improve completeness.
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?
All parameters have descriptions in the schema (100% coverage). The description adds context, such as the date parameter being useful for past/future readings and the seed for reproducible results, adding value 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 returns the crystal of the day as a discovery teaser, with deterministic behavior based on date. It lists specific use cases like daily guidance features and widgets, distinguishing it from siblings like get_crystals_random or get_crystals_id.
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 advises using the /crystals/:id endpoint for complete healing properties, indicating when not to use this tool. It implies usage for daily features but could be more explicit about alternatives among siblings.
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!