Skip to main content
Glama

Crystals MCP Server by RoxyAPI

by com.roxyapi

Search Crystals

get_crystals_search
Read-only

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qYesSearch query (2-50 characters). Matches against crystal names, keywords, descriptions, and meaning fields. Case-insensitive partial matching.
langNoResponse 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
limitNoMaximum items to return per page. Range: 1-50, default 20.
offsetNoNumber of items to skip for pagination. Default 0.
compactNoSet 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.

TDQS

A4.2/5.0
Behavior4/5

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

The annotations already state readOnlyHint=true and destructiveHint=false, and the description is consistent with them. It adds useful behavioral context by noting that only summary data is returned and that full healing properties require a separate detail endpoint. No contradiction is present.

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: it opens with the primary action and required input, clarifies matching scope, states the return nature, and gives practical context. Every sentence contributes useful information without redundancy or filler.

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 search tool with a fully described input schema, the description covers the main selection and invocation needs. It explains summary-level output and points to the detail endpoint, though it does not describe the exact response structure since no output schema is present.

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% and every parameter, including q, lang, limit, offset, and compact, has rich descriptions in the schema. The tool description does not need to explain parameters further, though it adds some matching-field context already present in the q parameter description.

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 clear verb and resource: 'Search for healing crystals by keyword or name.' It specifies the matched fields and distinguishes itself from sibling list/filter tools by emphasizing text-based search. This is sufficient for an agent to understand exactly what the tool does.

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 concrete use cases (search bars, keyword recommendations, healing property lookups) and tells the agent to use the /crystals/{id} detail endpoint when full healing properties are needed. It does not explicitly list which sibling tools to use instead for facet-based browsing, 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.

All Crystals MCP Server by RoxyAPI toolsInspect
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

A4.2/5.0
Disambiguation4/5

Most tools have clearly distinct purposes, but there is overlap between get_crystals with filters and the dedicated endpoints for chakra, element, zodiac, and birthstone. The descriptive names and detailed explanations help agents choose correctly, though mis-selection is possible.

Naming Consistency4/5

All tools follow the get_crystals_<suffix> pattern except post_crystals_daily, which uses a post verb for a read operation. This minor deviation, along with the slightly awkward get_crystals_id and get_crystals_pairings_id, keeps the naming consistent overall.

Tool Count5/5

With 12 tools, the server is well-scoped for a crystal reference API. It covers listing, detail, search, random, daily, pairings, and filter-specific endpoints, each earning its place without feeling redundant or excessive.

Completeness4/5

The API provides comprehensive lookup coverage for crystals, including list, detail, search, random, daily, pairings, and filter/reference endpoints. The lack of dedicated endpoints for color and planet filters (only reference lists) is a minor gap, but the generic filter covers these use cases.

Resources