Crystals MCP Server by RoxyAPI

by com.roxyapi

Overview Discussions Admin

Server Details

Crystal meanings, healing properties, chakra and birthstone lookups for AI agents.

Ownership verified

Status: Healthy
Uptime: 100.0% over 41 days
Last Tested: 2026-09-27 15:19
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A3.9/5.0

Scored 2026-09-23 18:10 across 12 tools

Disambiguation3/5

Most tools have clear distinct purposes, but get_crystals overlaps with get_crystals_chakra, get_crystals_element, and get_crystals_zodiac_sign since the base list endpoint already supports those filters. The descriptions help somewhat, but agents may be uncertain which to call for a specific filtered lookup.

Naming Consistency4/5

The naming pattern is mostly consistent with get_crystals_<suffix> using snake_case throughout. The main deviation is post_crystals_daily, which introduces a different verb, but the overall resource-prefixed pattern remains recognizable and predictable.

Tool Count4/5

Twelve tools is within a reasonable range for a crystal reference API, but several specialized filter endpoints duplicate functionality already available via the base get_crystals filters. Slightly more than strictly necessary, but not bloated or overwhelming.

Completeness5/5

The tool set covers the domain well: listing, detail retrieval, search, random discovery, daily crystal, pairings, and all major filters such as chakra, zodiac, element, color, planet, and birthstone month. Since this is a read-only reference API, the lack of write operations is not a gap.

Available Tools

12 tools

get_crystalsList all crystals - Crystal healing database APIA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`lang`	No	Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns 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 for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens.
`element`	No	Filter by elemental association, case-insensitive. Valid values: Earth, Water, Fire, Air, Storm.

Output Schema

ParametersJSON Schema

Name	Required	Description
`limit`	Yes
`total`	Yes
`offset`	Yes
`crystals`	Yes

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds pagination behavior and the minimal-summary-fields trait, which is useful. However, it doesn't disclose details like default pagination size, maximum limit, or the compact shape behavior, though those are in the schema. It adds some context beyond annotations but not rich behavioral detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the core action and pagination, then filters, then return shape, then use cases. It is efficient and every sentence earns its place, though the use-case sentence is slightly promotional.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists and annotations cover safety, the description is largely complete. It explains the minimal summary fields and points to the detail endpoint for full properties. It doesn't mention pagination defaults or the compact option, but those are in the schema. For a list endpoint with rich schema, this is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all 9 parameters. The description mentions filtering by chakra, zodiac, element, color, or planet, which maps to the schema, but adds no new meaning beyond what the schema already provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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 and gemstones with pagination and optional filters, and explicitly contrasts it with the detail endpoint for full healing properties. This distinguishes it from sibling tools like get_crystals_search and 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.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool (building explorer apps, guides, recommendation engines) and mentions the detail endpoint for full properties, implying when not to use it. It doesn't explicitly name sibling alternatives like get_crystals_search or get_crystals_random, but the use cases are clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_crystals_birthstone_monthBirthstones by month - Birthstone lookup APIA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`lang`	No	Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English.	en
`month`	Yes	Birth month as a number from 1 (January) to 12 (December).
`compact`	No	Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens.

Output Schema

ParametersJSON Schema

Name	Required	Description
`month`	Yes
`total`	Yes
`crystals`	Yes
`monthName`	Yes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds that it returns summary data (not full properties) and that it's based on GIA assignments, which are behavioral clarifications beyond the annotations. No contradictions, but no deep behavioral details like rate limits or pagination.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences: purpose, alternative, and use cases. The most critical information (what it does) is front-loaded, with no redundant phrasing. It earns each word.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only lookup with a well-defined input schema and an output schema present, the description adequately explains the tool's scope, return type (summary), and an alternative for more detail. It lacks nothing essential for an agent to decide to use it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all three parameters (lang, month, compact) have detailed descriptions. The description does not add parameter-specific semantics beyond what the schema provides, so it relies on the schema, which is acceptable given high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb (get), the resource (traditional birthstone crystals for a birth month), and what it returns (summary data). It differentiates from sibling tools by specifying the birth-month scope and noting GIA authority, which distinguishes it from other crystal 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.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions an alternative (the /crystals/{id} detail endpoint) for full healing properties, providing a clear when-to-use-other condition. It also suggests use cases (birthday gifts, jewelry) but does not explicitly contrast with other sibling filters like chakra or element, so it's clear but not exhaustive.

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 chakra - Chakra healing stones APIA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`lang`	No	Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns 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 for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens.

Output Schema

ParametersJSON Schema

Name	Required	Description
`limit`	Yes
`total`	Yes
`chakra`	Yes
`offset`	Yes
`crystals`	Yes

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the operation read-only and non-destructive. The description adds useful behavioral context by clarifying that results are summary data and that the detail endpoint is needed for fuller properties. This goes beyond what the annotations alone communicate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the core action and scope. It wastes no words, though the final sentence on use cases is somewhat supplementary rather than essential. Overall it is well-structured and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has rich input schema documentation, output schema, and read-only annotations. The description covers what it returns, what chakras are supported, when to use a different endpoint, and typical application contexts. An agent has everything needed to select and invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all five parameters thoroughly. The description adds the semantic notion of 'resonate with a chakra energy center' but does not add significant parameter-level detail 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: get healing crystals filtered by chakra energy center. It distinguishes itself from the detail endpoint by noting it returns summary data, and enumerates all 7 chakras. The purpose is unambiguous even among many get_crystals_* siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly identifies the alternative endpoint for full healing properties, telling the agent when this tool is the right choice versus a more detailed one. It also provides concrete use cases (crystal grid building, chakra balancing, energy healing), giving clear contextual guidance.

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 colors - Crystal color filter APIA

Read-only

Inspect

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 browsing of healing stones, visual crystal pickers, and filtering UI. The values are filter identifiers and stay in English under every lang, so a translated picker still submits a color the filter accepts.

ParametersJSON Schema

Name	Required	Description	Default
`lang`	No	Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English.	en
`compact`	No	Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens.

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`colors`	Yes

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate a read-only, non-destructive operation. The description adds useful behavior beyond that: the values are filter identifiers and stay in English under every language, ensuring translated pickers still submit values the filter accepts.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded with the core behavior. The 'Essential reference endpoint' sentence adds use-case context but is slightly promotional compared to the rest.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-required-parameter read-only reference endpoint with an output schema and annotations, the description is complete. It explains what is returned, how to consume it downstream, and the key localization behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema coverage is 100%, so the baseline is 3. The description adds extra meaning for the lang parameter by explaining that color values are language-independent, while the compact parameter is adequately documented by the schema itself.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the exact resource and operation: listing all unique crystal colors in the database. It also positions the tool as a filter reference, which makes it clearly distinct from sibling crystal endpoints.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says to use these values with the color filter on GET /crystals and gives concrete use cases like color-based browsing and filter UIs. It does not mention exclusions or alternatives, but the context is clear enough.

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 element - Elemental crystal lookup APIA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`lang`	No	Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns 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 for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens.
`element`	Yes	Element name, case-insensitive (e.g., water, Water, WATER all work). Valid: Earth, Water, Fire, Air, Storm.

Output Schema

ParametersJSON Schema

Name	Required	Description
`limit`	Yes
`total`	Yes
`offset`	Yes
`element`	Yes
`crystals`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful context by stating that results are summary data only, that the full healing properties require the detail endpoint, and that exactly five elements are supported. This goes beyond the structured annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four focused sentences deliver the core action, output shape, an important routing direction, and supported values. The most important information is front-loaded, and there is no filler or repetition of schema details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the rich schema, output schema, and safety annotations, the description covers the essential context an agent needs: what is returned, how it differs from the detail endpoint, and when to use it. It does not mention pagination or localization, but those are fully documented in the schema, so this is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the structured schema already documents every parameter fully. The description mentions the five supported elements but does not add additional meaning about lang, limit, offset, or compact beyond what the schema already provides. This matches the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Get healing crystals and gemstones associated with a specific natural element.' It clearly states the output is summary data and explicitly differentiates itself from the detail endpoint, making the tool's purpose unambiguous and distinct from its many siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear usage context: elemental crystal selection, nature-based healing, and element-themed grids. It also points users to the detail endpoint when full healing properties are needed, providing an explicit alternative. It does not enumerate all sibling exclusions, but the naming and scope make the intended use clear.

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 by id - Crystal healing properties APIA

Read-only

Inspect

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.

ParametersJSON Schema

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 (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English.	en
`compact`	No	Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens.

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`name`	Yes
`colors`	Yes
`planet`	Yes
`chakras`	Yes
`meaning`	Yes
`elements`	Yes
`hardness`	Yes
`imageUrl`	Yes
`keywords`	Yes
`pairsWith`	Yes
`birthMonth`	Yes
`affirmation`	Yes
`description`	Yes
`zodiacSigns`	Yes
`numericalVibration`	Yes

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds context about what content is returned (spiritual, emotional, physical healing interpretations, chakra, zodiac, elemental, pairings) but does not disclose non-obvious behaviors such as language fallback, compact response shape, or not-found behavior. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a compact three-sentence definition with the main action and resource front-loaded. The enumeration of returned categories is useful, but the final 'Authoritative interpretations covering all major healing crystals' is promotional filler rather than actionable guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a rich input schema, full parameter coverage, explicit annotations, and an output schema present, the description does not need to explain return structure or safety. It adequately covers the common invocation path for a known crystal id, though it could be more complete by naming sibling alternatives for fuzzy or list-based lookups.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: the id parameter is documented with case-insensitivity, lang has an enum and fallback behavior, and compact describes its columnar shape and token savings. The description itself adds no parameter-level detail, so the 3 baseline is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and names the resource ('a specific crystal or gemstone') while enumerating the returned data categories. It is clearly distinct from list-oriented siblings, though it does not explicitly contrast itself with get_crystals_search or get_crystals_pairings_id; the title's 'by id' supplies the missing differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'for a specific crystal or gemstone' implies the caller should already know the crystal identifier, giving some usage context. However, there is no explicit statement of when to use this tool instead of the many sibling lookup tools, no exclusions, and no mention of when search or list endpoints would be preferable.

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 pairings - Crystal combination APIA

Read-only

Inspect

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.

ParametersJSON Schema

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 (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English.	en
`compact`	No	Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens.

Output Schema

ParametersJSON Schema

Name	Required	Description
`name`	Yes
`count`	Yes
`crystal`	Yes
`pairings`	Yes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful behavioral context by stating that it returns both the source crystal and companion stones with properties, but it does not disclose edge-case behavior like unknown IDs or empty pairing results. This is adequate given the read-only nature and output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact at three sentences, front-loading the core action and resource. The use-case sentence adds context but leans slightly promotional; it is still useful enough to justify inclusion. No redundant restatement of the name or title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is a read-only lookup with three well-documented parameters, a provided output schema, and readOnly/destructive annotations. The description together with the schema covers everything an agent needs to select and invoke it correctly: what it does, what it returns, and its relevant use cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all three parameters. The description only indirectly references the id parameter ('a given crystal') and adds no additional meaning beyond the schema. The baseline of 3 applies because the schema carries the parameter-documentation burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get'), names the resource (crystals pairings), and clearly explains the input ('a given crystal') and output ('source crystal along with its recommended companion stones'). This clearly distinguishes it from the sibling tools like get_crystals_id or get_crystals_search, which focus on basic crystal lookups or search rather than pairings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit use cases: crystal grid building, healing combination recommendations, and cross-sell features. This gives clear contextual guidance on when the tool is appropriate, though it does not explicitly name alternative tools or state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_crystals_planetsList crystal planets - Planetary ruler filter APIA

Read-only

Inspect

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. The values are filter identifiers and stay in English under every lang, so a translated picker still submits a planet the filter accepts.

ParametersJSON Schema

Name	Required	Description	Default
`lang`	No	Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English.	en
`compact`	No	Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens.

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`planets`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavior beyond that: values are filter identifiers that remain English under every language, so a translated picker still submits accepted values. This prevents a real misuse even though it does not discuss output size or pagination.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core function and uses four purposeful sentences. The 'Essential reference endpoint' sentence adds useful audience context but is slightly less essential than the rest, keeping it from being perfectly lean.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple read-only endpoint with no required parameters, a complete input schema, and an output schema. The description covers purpose, usage, locale behavior, and how the values relate to GET /crystals, so nothing needed for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so lang and compact are already fully documented in the schema. The description does not add parameter-specific detail beyond noting the language-invariance of the returned values, which matches the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'List all unique planetary associations available in the database.' It clearly frames the endpoint as a filter-value reference for GET /crystals, distinguishing it from sibling crystal-listing tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit usage context: pass the returned values to the planet filter on GET /crystals, especially for astrology apps recommending crystals by birth-chart placements. It does not explicitly list when-not-to-use or compare against siblings like get_crystals_zodiac_sign, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_crystals_randomRandom crystal - Crystal discovery APIA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`lang`	No	Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English.	en
`compact`	No	Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens.

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`name`	Yes
`chakras`	Yes
`imageUrl`	Yes
`affirmation`	Yes
`description`	Yes
`zodiacSigns`	Yes

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only and non-destructive behavior. The description adds meaningful behavioral context beyond that: the response is non-deterministic, a different crystal appears on each request, and the result is a teaser rather than a complete property listing. This is sufficient for safe invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: first sentence states the core action, second clarifies randomness, and subsequent sentences cover alternatives and use cases. Every sentence earns its place with no redundant filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema, full parameter coverage, and read-only annotations, the description is complete for correct invocation. It explains randomness, points to the right alternative endpoints for related needs, and gives enough context for an agent to decide when to call this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameter details for 'lang' and 'compact' are already fully documented in the input schema. The tool description adds no extra parameter-specific meaning, which matches the baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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, which distinguishes it from search, detail, and daily siblings. It also explicitly differentiates itself by noting non-deterministic behavior and references the /daily endpoint as a deterministic alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description names concrete use cases: crystal discovery features, surprise picks, roulette games, and exploration widgets. It also tells the agent when NOT to use it: for deterministic daily crystals use /daily, and for complete healing properties use the /crystals/{id} detail 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 crystals - Crystal search APIA

Read-only

Inspect

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.

ParametersJSON Schema

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 (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns 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 for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens.

Output Schema

ParametersJSON Schema

Name	Required	Description
`limit`	Yes
`query`	Yes
`total`	Yes
`offset`	Yes
`crystals`	Yes

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that it returns summary data (not full details) and specifies the search-field matching behavior, which is useful context beyond annotations. Doesn't contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Five sentences, each adding distinct value: purpose, match fields, return type, alternative endpoint, and use cases. Slightly longer than the bare minimum but no filler — every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists so return values are covered structurally. The description covers search behavior, use cases, and the alternative for full details. Only minor omission is explicit pagination guidance, but that's fully documented in the schema parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with detailed per-parameter descriptions (q length/case matching, lang BCP-47 fallback, limit/offset pagination bounds, compact columnar shape). The description adds little beyond schema — it mentions 'keyword or name' search which the schema's q already documents. Baseline 3 is appropriate when the schema carries the semantic load.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb-resource pair ('Search for healing crystals by keyword or name') and enumerates the fields matched against (names, healing keywords, descriptions, spiritual/emotional/physical meaning). Clearly distinguishable from sibling filter tools like get_crystals_chakra or get_crystals_element, which target single attributes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes to the /crystals/{id} detail endpoint when full healing properties are needed, and lists concrete use cases (search bars, recommendation features, healing property lookups). However, it does not explicitly contrast with the sibling filter-by-attribute tools, leaving some selection inference to the agent.

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 sign - Zodiac birthstone APIA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`lang`	No	Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns 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 for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens.

Output Schema

ParametersJSON Schema

Name	Required	Description
`sign`	Yes
`limit`	Yes
`total`	Yes
`offset`	Yes
`crystals`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context: responses are summary data rather than full healing properties, and all 12 zodiac signs are supported. No conflict with annotations was found.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and stays reasonably concise. The pointer to the detail endpoint is useful. The final marketing sentence about 'personalized crystal recommendations' adds little value but does not materially hurt.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema, complete parameter docs, and safe read-only annotations, the description fully covers what an agent needs: the tool's purpose, result summary, endpoint alternative for richer data, and supported zodiac signs. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and each parameter has detailed descriptions, enums, defaults, and examples. The tool description adds no extra parameter-level semantics beyond what the schema already provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Get healing crystals and gemstones associated with a specific zodiac sign.' This clearly sets it apart from siblings like get_crystals_chakra or get_crystals_birthstone_month. It also clarifies the output is summary data, not full details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes the use case clear—zodiac-based crystal lookup—and explicitly points to the /crystals/{id} detail endpoint for full healing properties. However, it does not name or exclude sibling tools directly, so the differentiation is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

post_crystals_dailyDaily crystal - Crystal of the day APIA

Read-only

Inspect

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.

ParametersJSON Schema

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 (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns 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 for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens.

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`date`	Yes
`name`	Yes
`seed`	Yes
`chakras`	Yes
`imageUrl`	Yes
`affirmation`	Yes
`description`	Yes
`zodiacSigns`	Yes

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark the tool as read-only and non-destructive. The description adds valuable behavioral context: deterministic selection based on date, consistency across all users for the same day, and the 'discovery teaser' nature. The phrase 'provided seed date' is slightly imprecise because the schema separates date from seed, but the core behavior is clearly disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: the first sentence states the tool's purpose, the second explains determinism, and the remaining sentences give the alternative and use cases. It earns its length, though the use-case list is slightly expansive and 'seed date' could be worded more precisely.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, read-only, fully-optional-parameter tool with an output schema present, the description covers everything an agent needs: what it returns, how determinism works, when to use it, and where to go for richer data. The annotations handle safety expectations, and the schema handles parameter details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents date, lang, seed, and compact in detail. The description adds only the general determinism concept and does not provide additional parameter-level semantics. Baseline 3 is appropriate since no compensation is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Get the crystal of the day') and immediately clarifies its deterministic daily nature. It also differentiates from the more detailed crystals endpoint by labeling this a 'discovery teaser' and pointing to /crystals/{id} for full properties. This is enough for an agent to distinguish it from sibling tools 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.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit use cases ('daily guidance features, push notifications, wellness app widgets, and crystal journal integrations') and an explicit alternative: 'Use the /crystals/{id} detail endpoint for complete spiritual, emotional, and physical healing properties.' This tells an agent both when to use this tool and when to choose the detail endpoint instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesSep 23, 2026
- Changedget_crystals2 fields changed
  - addedInput schema / properties / offset / default
```
Added value: +0
```
  - addedInput schema / properties / offset / minimum
```
Added value: +0
```
- Changedget_crystals_chakra2 fields changed
  - addedInput schema / properties / offset / default
```
Added value: +0
```
  - addedInput schema / properties / offset / minimum
```
Added value: +0
```
- Changedget_crystals_element2 fields changed
  - addedInput schema / properties / offset / default
```
Added value: +0
```
  - addedInput schema / properties / offset / minimum
```
Added value: +0
```
- Changedget_crystals_search2 fields changed
  - addedInput schema / properties / offset / default
```
Added value: +0
```
  - addedInput schema / properties / offset / minimum
```
Added value: +0
```
- Changedget_crystals_zodiac_sign2 fields changed
  - addedInput schema / properties / offset / default
```
Added value: +0
```
  - addedInput schema / properties / offset / minimum
```
Added value: +0
```
5 tool updatesSep 20, 2026
- Changedget_crystals3 fields changed
  - removedInput schema / properties / offset / default
```
Removed value: -0
```
  - removedInput schema / properties / offset / minimum
```
Removed value: -0
```
  - changedInput schema / properties / offset / type
```
Previous value: -[
-  "integer",
-  "null"
-]New value: +"integer"
```
- Changedget_crystals_chakra3 fields changed
  - removedInput schema / properties / offset / default
```
Removed value: -0
```
  - removedInput schema / properties / offset / minimum
```
Removed value: -0
```
  - changedInput schema / properties / offset / type
```
Previous value: -[
-  "integer",
-  "null"
-]New value: +"integer"
```
- Changedget_crystals_element3 fields changed
  - removedInput schema / properties / offset / default
```
Removed value: -0
```
  - removedInput schema / properties / offset / minimum
```
Removed value: -0
```
  - changedInput schema / properties / offset / type
```
Previous value: -[
-  "integer",
-  "null"
-]New value: +"integer"
```
- Changedget_crystals_search3 fields changed
  - removedInput schema / properties / offset / default
```
Removed value: -0
```
  - removedInput schema / properties / offset / minimum
```
Removed value: -0
```
  - changedInput schema / properties / offset / type
```
Previous value: -[
-  "integer",
-  "null"
-]New value: +"integer"
```
- Changedget_crystals_zodiac_sign3 fields changed
  - removedInput schema / properties / offset / default
```
Removed value: -0
```
  - removedInput schema / properties / offset / minimum
```
Removed value: -0
```
  - changedInput schema / properties / offset / type
```
Previous value: -[
-  "integer",
-  "null"
-]New value: +"integer"
```

12 tool updatesSep 20, 2026

Changedget_crystals1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "crystals": {
+      "items": {
+        "properties": {
+          "chakras": {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "colors": {
+            "items": {
+              "type": "string"
+            },
+            "type": [
+              "array",
+              "null"
+            ]
+          },
+          "id": {
+            "type": "string"
+          },
+          "imageUrl": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "name": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "name",
+          "id",
+          "imageUrl",
+          "colors",
+          "chakras"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "limit": {
+      "type": "number"
+    },
+    "offset": {
+      "type": "number"
+    },
+    "total": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "total",
+    "limit",
+    "offset",
+    "crystals"
+  ],
+  "type": "object"
+}

Changedget_crystals_birthstone_month1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "crystals": {
+      "items": {
+        "properties": {
+          "colors": {
+            "items": {
+              "type": "string"
+            },
+            "type": [
+              "array",
+              "null"
+            ]
+          },
+          "id": {
+            "type": "string"
+          },
+          "imageUrl": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "name": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "name",
+          "id",
+          "imageUrl",
+          "colors"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "month": {
+      "type": "number"
+    },
+    "monthName": {
+      "type": "string"
+    },
+    "total": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "month",
+    "monthName",
+    "total",
+    "crystals"
+  ],
+  "type": "object"
+}

Changedget_crystals_chakra1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "chakra": {
+      "type": "string"
+    },
+    "crystals": {
+      "items": {
+        "properties": {
+          "colors": {
+            "items": {
+              "type": "string"
+            },
+            "type": [
+              "array",
+              "null"
+            ]
+          },
+          "id": {
+            "type": "string"
+          },
+          "imageUrl": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "name": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "name",
+          "id",
+          "imageUrl",
+          "colors"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "limit": {
+      "type": "number"
+    },
+    "offset": {
+      "type": "number"
+    },
+    "total": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "chakra",
+    "total",
+    "limit",
+    "offset",
+    "crystals"
+  ],
+  "type": "object"
+}

Changedget_crystals_colors1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "colors": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "count": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "count",
+    "colors"
+  ],
+  "type": "object"
+}

Changedget_crystals_element1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "crystals": {
+      "items": {
+        "properties": {
+          "colors": {
+            "items": {
+              "type": "string"
+            },
+            "type": [
+              "array",
+              "null"
+            ]
+          },
+          "id": {
+            "type": "string"
+          },
+          "imageUrl": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "name": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "name",
+          "id",
+          "imageUrl",
+          "colors"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "element": {
+      "type": "string"
+    },
+    "limit": {
+      "type": "number"
+    },
+    "offset": {
+      "type": "number"
+    },
+    "total": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "element",
+    "total",
+    "limit",
+    "offset",
+    "crystals"
+  ],
+  "type": "object"
+}

Changedget_crystals_id1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "affirmation": {
+      "type": "string"
+    },
+    "birthMonth": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "chakras": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "colors": {
+      "items": {
+        "type": "string"
+      },
+      "type": [
+        "array",
+        "null"
+      ]
+    },
+    "description": {
+      "type": "string"
+    },
+    "elements": {
+      "items": {
+        "type": "string"
+      },
+      "type": [
+        "array",
+        "null"
+      ]
+    },
+    "hardness": {
+      "type": "number"
+    },
+    "id": {
+      "type": "string"
+    },
+    "imageUrl": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "keywords": {
+      "items": {
+        "type": "string"
+      },
+      "type": [
+        "array",
+        "null"
+      ]
+    },
+    "meaning": {
+      "properties": {
+        "emotional": {
+          "type": "string"
+        },
+        "physical": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "spiritual": {
+          "type": [
+            "string",
+            "null"
+          ]
+        }
+      },
+      "required": [
+        "spiritual",
+        "emotional",
+        "physical"
+      ],
+      "type": "object"
+    },
+    "name": {
+      "type": "string"
+    },
+    "numericalVibration": {
+      "type": "number"
+    },
+    "pairsWith": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "planet": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "zodiacSigns": {
+      "items": {
+        "type": "string"
+      },
+      "type": [
+        "array",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "name",
+    "id",
+    "imageUrl",
+    "description",
+    "meaning",
+    "chakras",
+    "zodiacSigns",
+    "planet",
+    "elements",
+    "colors",
+    "hardness",
+    "numericalVibration",
+    "keywords",
+    "birthMonth",
+    "affirmation",
+    "pairsWith"
+  ],
+  "type": "object"
+}

Changedget_crystals_pairings_id1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "count": {
+      "type": "number"
+    },
+    "crystal": {
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    },
+    "pairings": {
+      "items": {
+        "properties": {
+          "chakras": {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "description": {
+            "type": "string"
+          },
+          "id": {
+            "type": "string"
+          },
+          "imageUrl": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "keywords": {
+            "items": {
+              "type": "string"
+            },
+            "type": [
+              "array",
+              "null"
+            ]
+          },
+          "name": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "name",
+          "id",
+          "imageUrl",
+          "description",
+          "chakras",
+          "keywords"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "crystal",
+    "name",
+    "count",
+    "pairings"
+  ],
+  "type": "object"
+}

Changedget_crystals_planets1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "count": {
+      "type": "number"
+    },
+    "planets": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "count",
+    "planets"
+  ],
+  "type": "object"
+}

Changedget_crystals_random1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "affirmation": {
+      "type": "string"
+    },
+    "chakras": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "description": {
+      "type": "string"
+    },
+    "id": {
+      "type": "string"
+    },
+    "imageUrl": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "name": {
+      "type": "string"
+    },
+    "zodiacSigns": {
+      "items": {
+        "type": "string"
+      },
+      "type": [
+        "array",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "name",
+    "id",
+    "imageUrl",
+    "description",
+    "chakras",
+    "zodiacSigns",
+    "affirmation"
+  ],
+  "type": "object"
+}

Changedget_crystals_search1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "crystals": {
+      "items": {
+        "properties": {
+          "colors": {
+            "items": {
+              "type": "string"
+            },
+            "type": [
+              "array",
+              "null"
+            ]
+          },
+          "id": {
+            "type": "string"
+          },
+          "imageUrl": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "name": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "name",
+          "id",
+          "imageUrl",
+          "colors"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "limit": {
+      "type": "number"
+    },
+    "offset": {
+      "type": "number"
+    },
+    "query": {
+      "type": "string"
+    },
+    "total": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "query",
+    "total",
+    "limit",
+    "offset",
+    "crystals"
+  ],
+  "type": "object"
+}

Changedget_crystals_zodiac_sign1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "crystals": {
+      "items": {
+        "properties": {
+          "colors": {
+            "items": {
+              "type": "string"
+            },
+            "type": [
+              "array",
+              "null"
+            ]
+          },
+          "id": {
+            "type": "string"
+          },
+          "imageUrl": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "name": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "name",
+          "id",
+          "imageUrl",
+          "colors"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "limit": {
+      "type": "number"
+    },
+    "offset": {
+      "type": "number"
+    },
+    "sign": {
+      "type": "string"
+    },
+    "total": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "sign",
+    "total",
+    "limit",
+    "offset",
+    "crystals"
+  ],
+  "type": "object"
+}

Changedpost_crystals_daily1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "affirmation": {
+      "type": "string"
+    },
+    "chakras": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "date": {
+      "type": "string"
+    },
+    "description": {
+      "type": "string"
+    },
+    "id": {
+      "type": "string"
+    },
+    "imageUrl": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "name": {
+      "type": "string"
+    },
+    "seed": {
+      "type": "string"
+    },
+    "zodiacSigns": {
+      "items": {
+        "type": "string"
+      },
+      "type": [
+        "array",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "date",
+    "seed",
+    "name",
+    "id",
+    "imageUrl",
+    "description",
+    "chakras",
+    "zodiacSigns",
+    "affirmation"
+  ],
+  "type": "object"
+}

2 tool updatesSep 4, 2026

Changedget_crystals_colors1 field changed

addedInput schema / properties / lang

Added value: +{
+  "default": "en",
+  "description": "Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English.",
+  "enum": [
+    "en",
+    "tr",
+    "de",
+    "es",
+    "hi",
+    "pt",
+    "fr",
+    "ru",
+    "zh-Hans",
+    "zh-Hant"
+  ],
+  "example": "en",
+  "type": "string"
+}

Changedget_crystals_planets1 field changed

addedInput schema / properties / lang

Added value: +{
+  "default": "en",
+  "description": "Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English.",
+  "enum": [
+    "en",
+    "tr",
+    "de",
+    "es",
+    "hi",
+    "pt",
+    "fr",
+    "ru",
+    "zh-Hans",
+    "zh-Hant"
+  ],
+  "example": "en",
+  "type": "string"
+}

10 tool updatesAug 25, 2026

Changedget_crystals2 fields changed

changedInput schema / properties / lang / description

Previous value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English."

changedInput schema / properties / lang / enum

Previous value: -[
-  "en",
-  "tr",
-  "de",
-  "es",
-  "hi",
-  "pt",
-  "fr",
-  "ru"
-]New value: +[
+  "en",
+  "tr",
+  "de",
+  "es",
+  "hi",
+  "pt",
+  "fr",
+  "ru",
+  "zh-Hans",
+  "zh-Hant"
+]

Changedget_crystals_birthstone_month2 fields changed

changedInput schema / properties / lang / description

Previous value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English."

changedInput schema / properties / lang / enum

Previous value: -[
-  "en",
-  "tr",
-  "de",
-  "es",
-  "hi",
-  "pt",
-  "fr",
-  "ru"
-]New value: +[
+  "en",
+  "tr",
+  "de",
+  "es",
+  "hi",
+  "pt",
+  "fr",
+  "ru",
+  "zh-Hans",
+  "zh-Hant"
+]

Changedget_crystals_chakra2 fields changed

changedInput schema / properties / lang / description

Previous value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English."

changedInput schema / properties / lang / enum

Previous value: -[
-  "en",
-  "tr",
-  "de",
-  "es",
-  "hi",
-  "pt",
-  "fr",
-  "ru"
-]New value: +[
+  "en",
+  "tr",
+  "de",
+  "es",
+  "hi",
+  "pt",
+  "fr",
+  "ru",
+  "zh-Hans",
+  "zh-Hant"
+]

Changedget_crystals_element2 fields changed

changedInput schema / properties / lang / description

Previous value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English."

changedInput schema / properties / lang / enum

Previous value: -[
-  "en",
-  "tr",
-  "de",
-  "es",
-  "hi",
-  "pt",
-  "fr",
-  "ru"
-]New value: +[
+  "en",
+  "tr",
+  "de",
+  "es",
+  "hi",
+  "pt",
+  "fr",
+  "ru",
+  "zh-Hans",
+  "zh-Hant"
+]

Changedget_crystals_id2 fields changed

changedInput schema / properties / lang / description

Previous value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English."

changedInput schema / properties / lang / enum

Previous value: -[
-  "en",
-  "tr",
-  "de",
-  "es",
-  "hi",
-  "pt",
-  "fr",
-  "ru"
-]New value: +[
+  "en",
+  "tr",
+  "de",
+  "es",
+  "hi",
+  "pt",
+  "fr",
+  "ru",
+  "zh-Hans",
+  "zh-Hant"
+]

Changedget_crystals_pairings_id2 fields changed

changedInput schema / properties / lang / description

Previous value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English."

changedInput schema / properties / lang / enum

Previous value: -[
-  "en",
-  "tr",
-  "de",
-  "es",
-  "hi",
-  "pt",
-  "fr",
-  "ru"
-]New value: +[
+  "en",
+  "tr",
+  "de",
+  "es",
+  "hi",
+  "pt",
+  "fr",
+  "ru",
+  "zh-Hans",
+  "zh-Hant"
+]

Changedget_crystals_random2 fields changed

changedInput schema / properties / lang / description

Previous value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English."

changedInput schema / properties / lang / enum

Previous value: -[
-  "en",
-  "tr",
-  "de",
-  "es",
-  "hi",
-  "pt",
-  "fr",
-  "ru"
-]New value: +[
+  "en",
+  "tr",
+  "de",
+  "es",
+  "hi",
+  "pt",
+  "fr",
+  "ru",
+  "zh-Hans",
+  "zh-Hant"
+]

Changedget_crystals_search2 fields changed

changedInput schema / properties / lang / description

Previous value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English."

changedInput schema / properties / lang / enum

Previous value: -[
-  "en",
-  "tr",
-  "de",
-  "es",
-  "hi",
-  "pt",
-  "fr",
-  "ru"
-]New value: +[
+  "en",
+  "tr",
+  "de",
+  "es",
+  "hi",
+  "pt",
+  "fr",
+  "ru",
+  "zh-Hans",
+  "zh-Hant"
+]

Changedget_crystals_zodiac_sign2 fields changed

changedInput schema / properties / lang / description

Previous value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English."

changedInput schema / properties / lang / enum

Previous value: -[
-  "en",
-  "tr",
-  "de",
-  "es",
-  "hi",
-  "pt",
-  "fr",
-  "ru"
-]New value: +[
+  "en",
+  "tr",
+  "de",
+  "es",
+  "hi",
+  "pt",
+  "fr",
+  "ru",
+  "zh-Hans",
+  "zh-Hant"
+]

Changedpost_crystals_daily2 fields changed

changedInput schema / properties / lang / description

Previous value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English."

changedInput schema / properties / lang / enum

Previous value: -[
-  "en",
-  "tr",
-  "de",
-  "es",
-  "hi",
-  "pt",
-  "fr",
-  "ru"
-]New value: +[
+  "en",
+  "tr",
+  "de",
+  "es",
+  "hi",
+  "pt",
+  "fr",
+  "ru",
+  "zh-Hans",
+  "zh-Hant"
+]

12 tool updatesAug 17, 2026

Changedget_crystals2 fields changed

addedInput schema / examples
```
Added value: +[
+  {}
+]
```