Crystals MCP Server by RoxyAPI

List crystal colors - Crystal color filter API

get_crystals_colors

Read-only

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.

Input Schema

TableJSON 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.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed1 schema field changedSep 4, 2026

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"
+}

Changed2 schema fields changedAug 17, 2026

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

changedInput schema / properties / compact / description

Previous value: -"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."New value: +"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."

Changed1 schema field changedJul 22, 2026

changedInput schema / properties / compact / description

Previous value: -"Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false."New value: +"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."

Changed1 schema field changedJul 22, 2026

addedInput schema / properties / compact

Added value: +{
+  "default": false,
+  "description": "Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false.",
+  "type": "boolean"
+}

First observedJul 8, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare this as a safe read operation, and the description adds meaningful behavior beyond that: the values are filter identifiers, not display labels, and they remain in English even when lang is set to a translated locale. This prevents an agent from assuming localized color names are safe to submit back to the filter.

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 short sentences with no filler: the first states what the tool returns, the second states how to consume those values, and the third explains a subtle localization constraint. Every sentence earns its place and the most important information is front-loaded.

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 simple zero-required-parameter reference endpoint with read-only annotations, the description is nearly complete: it covers what is returned, why an agent would call it, and how the values behave across languages. There is no output schema, but the description's 'list all unique crystal colors' is sufficient given the simplicity of the 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?

The input schema already documents both lang and compact with full coverage, so the description does not need to re-explain them. It adds one useful nuance about lang by noting that colors stay English under every locale, which complements the schema's existing translation behavior. No extra semantic value is added for compact.

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 crystal colors') and immediately ties it to its intended use with the color filter on GET /crystals. It clearly differentiates this reference endpoint from siblings like get_crystals_search or get_crystals_chakra by framing it as a filter-value source for color-based browsing and pickers.

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: use these values with the color filter on GET /crystals, and it positions the endpoint as an essential reference for building color-based UI. It does not explicitly list when not to use it versus other filter-reference siblings, but the use case is clear enough that an agent can select it confidently.

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

All Crystals MCP Server by RoxyAPI tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation3/5

The main get_crystals endpoint already supports filtering by chakra, element, and zodiac, making the dedicated filter endpoints partially redundant. However, each tool has a clearly named purpose, so an agent can usually pick the right one.

Naming Consistency4/5

Most tools follow a consistent get_crystals_<suffix> pattern, but post_crystals_daily breaks the verb convention, and suffix ordering is slightly inconsistent (e.g., pairings_id vs id).

Tool Count5/5

12 tools is well within the ideal range for a domain-specific read-only API. Each tool serves a distinct browsing, search, detail, filter, reference, or discovery function.

Completeness4/5

The surface covers listing, detail, search, filters, random, daily, pairings, and reference values. Minor gap: no direct tool for enumerating chakras/elements/zodiac signs, though those are small fixed sets handled by the main list.

Resources

Need Help?