Crystals MCP Server by RoxyAPI

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

Annotations already establish read-only safety. The description adds meaningful behavioral context: results are paginated, only minimal summary fields are returned, and full healing properties are intentionally deferred to another endpoint. This goes beyond what annotations and the schema express.

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

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

The first two sentences are tight and front-load the core facts: list, pagination, filters, and summary-only output. The final sentence about building explorer apps is promotional rather than operational, but the overall length is still appropriate and readable.

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

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

For a read-only list tool with nine fully self-documenting parameters, the description gives sufficient context: pagination, filterable dimensions, summary-only output, and a pointer to the detail endpoint. It doesn't describe the exact response envelope, but return granularity is already communicated.

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

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

Schema coverage is 100% and every parameter has its own description, enum, default, or example. The description's mention of filtering by chakra, zodiac, element, color, and planet mirrors the schema but doesn't add extra meaning such as combination semantics or response behavior, so the baseline 3 applies.

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

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

The description clearly states a concrete action (retrieve) on a clear resource (healing crystals and gemstones) with pagination and optional filters. It separates itself from the detail endpoint, but does not explicitly disambiguate from sibling tools like get_crystals_search or the chakra/zodiac-specific endpoints.

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

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

It gives clear context that this is the paginated list/filter entry point and explicitly directs agents to the detail endpoint when full healing properties are needed. It doesn't name the exact sibling tools or spell out when to prefer search over this endpoint, but the usage intent is well conveyed.

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

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

Annotations already declare read-only and non-destructive behavior, so the safety profile is covered. The description adds contextual behavior: it returns 'summary data' and is based on GIA assignments, but doesn't go beyond that. It doesn't mention pagination, return format details, or additional constraints. Given annotations carry the main safety burden, a 3 is appropriate.

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

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

The description is compact and front-loaded with the core function. The note about the detail endpoint and use cases adds useful context without bloat. Each sentence contributes something meaningful, and the length is appropriate for the tool's simplicity.

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

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

The tool is simple (one required param, no output schema), but the description leaves 'summary data' vague — it doesn't clarify the exact structure or number of crystals returned per month. Minor missing details like pagination or output shape exist, but given the low complexity and annotations, it's reasonably complete.

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

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

Schema description coverage is 100%, so all three parameters (month, lang, compact) are already documented with types, defaults, and examples. The description doesn't add meaning beyond what the schema provides — it only reiterates the month concept. With full coverage, baseline 3 is correct.

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

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

The description clearly states the tool fetches traditional birthstone crystals for a birth month and returns summary data, which distinguishes it from detail endpoints. It also names a specific authoritative source (GIA). However, it doesn't explicitly contrast with all siblings (e.g., zodiac sign, chakra), so it's clear but not fully distinctive.

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

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

The description provides a concrete when-not: for full healing properties, use the /crystals/{id} detail endpoint, implying this tool is for summary needs. It also lists suitable use cases (gift recommendations, jewelry). It doesn't mention other sibling alternatives like zodiac or chakra, but the detail endpoint guidance covers a key alternative.

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

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 useful context about summary return data and chakra coverage, but it does not disclose pagination behavior or response shape beyond that. This is adequate given the annotation coverage, but not exceptional.

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

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

The description is front-loaded with the core purpose and stays reasonably compact. The list of chakras and the closing use-case sentence add some redundancy with the schema and title, but each sentence still contributes useful orientation.

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

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

For a read-only list endpoint with fully documented parameters and readOnly annotations, the description covers the essential context: what the tool returns, which chakras are supported, and where to go for full details. With no output schema, a bit more detail about the summary response shape could help, but nothing critical blocks correct invocation.

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

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

Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description reinforces that the chakra parameter is central and lists valid values, but it adds no meaning beyond what the schema already provides. Baseline 3 applies.

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

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

The description opens with a specific verb and resource: 'Get healing crystals and gemstones that resonate with a specific chakra energy center.' It clearly distinguishes itself from the detail endpoint by noting that it returns summary data, and it enumerates all 7 supported chakras, leaving no ambiguity about scope.

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

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

The description explicitly routes to the alternative detail endpoint: 'Use the /crystals/{id} detail endpoint for full healing properties.' It also gives concrete application contexts ('crystal grid building, chakra balancing, and energy healing applications'), so an agent knows when this tool is the right choice.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful context that results are summary data, not full healing properties, and lists the five supported elements. It does not address pagination, errors, or exact response shape, but the read-only annotation lowers the burden.

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

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

Four short sentences, each earning its place: the core action, the summary-data return, the pointer to the detail endpoint, and the supported elements/use cases. It is front-loaded and contains no filler.

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

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

For a simple read-only lookup with fully documented parameters and read-only annotations, the description is adequate. It communicates the result granularity and valid element values, but because there is no output schema, the exact fields in the summary data remain unspecified.

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

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

Input schema coverage is 100%, with detailed descriptions, defaults, ranges, and enums for all five parameters. The description only repeats the element enum values already present in the schema, adding no meaningful parameter-level semantics beyond what the schema provides.

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

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

The first sentence states a specific verb and resource ('Get healing crystals and gemstones') scoped by natural element, and the supported elements are listed clearly. The description does not explicitly name sibling tools, so differentiation is mostly implicit, though the title and element scope make the purpose unambiguous.

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

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

The description explicitly directs agents to the /crystals/{id} detail endpoint when full healing properties are needed, which is a clear alternative. It also gives relevant use cases such as elemental crystal selection and nature-based healing, though it does not exhaustively contrast with all sibling tools.

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

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 behavioral context by enumerating what the response contains: spiritual, emotional, and physical healing interpretations, chakra associations, zodiac connections, elemental properties, and pairing recommendations. This is valuable since there is no 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.

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

The description is short and front-loaded: the first sentence states the core purpose, the second details return contents, and the third is a brief scope statement. The final sentence is slightly promotional but not harmful.

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

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

For a simple read-only lookup tool with all parameters fully described in the schema, the description is complete enough. It explains what data is returned and the overall scope, though it does not mention error behavior for unknown ids or response shape details.

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

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

Schema description coverage is 100%, and the schema already documents id, lang, and compact thoroughly, including examples and defaults. The description adds no additional parameter-level semantics beyond characterizing the lookup as returning complete data for a specific crystal.

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

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

The description states a specific verb and resource: get complete healing properties and metaphysical data for a specific crystal or gemstone. It clearly distinguishes itself from sibling tools by emphasizing 'specific' lookup and 'complete' data, versus search, random, or domain-specific siblings like chakra or planet tools.

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

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

The usage context is implied: use when you need complete data for a known crystal or gemstone. However, the description does not explicitly contrast with alternatives like get_crystals_search or get_crystals_random, nor does it state when not to use this tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so no safety contradiction exists. The description adds that the tool returns the source crystal along with companion stones and their properties, but it does not describe failure modes, response shape edge cases, or other behavioral nuances. This is adequate given the read-only annotation.

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

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

The description is three sentences with no wasted words. The core action is front-loaded, the return content is stated in the second sentence, and the use cases in the third sentence add practical context without bloat.

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

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

The tool is a simple read-only lookup with three well-documented parameters and no output schema. The description covers what the tool returns and why it is useful. It could be slightly more complete by hinting at not-found behavior or that results vary by requested language, but the schema already handles parameter-level detail.

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

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

Schema description coverage is 100%, so the schema fully documents id, lang, and compact. The description adds little beyond mapping 'given crystal' to the id parameter and vaguely referencing properties. With full schema coverage, the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Get crystals that pair well with a given crystal.' It clearly differentiates this from sibling tools like get_crystals_id or get_crystals_search by focusing on pairings and companion stones. The mention of source crystal plus recommended companion stones makes the tool's purpose unambiguous.

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

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

The description gives concrete use cases: crystal grid building, healing combination recommendations, and cross-sell features. It does not explicitly say when not to use this tool or name alternatives, so it stops short of full when/when-not guidance, but the context is clear enough for an agent to route appropriately.

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

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 detail beyond that: planetary values remain English identifiers in every language, so a translated picker still submits values the filter accepts. This is a meaningful, non-obvious behavior for clients.

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

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

The description is compact and front-loaded: the core listing behavior is in the first sentence, followed by usage context and a cross-language caveat. Each sentence contributes useful information without padding.

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

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

For a read-only endpoint with no required parameters, the description supplies the essential context: what is returned, how the values are consumed, and how language affects them. There is no output schema, but the simple reference-endpoint nature means the description is sufficient for an agent to select and call the tool correctly.

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

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

Schema coverage is 100%, so lang and compact are already documented with defaults, enums, and examples. The description adds extra semantic value by explaining that language selection does not affect the filter identifiers returned, which is important for correctly using lang with the downstream filter.

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

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

The description names a specific action and resource: 'List all unique planetary associations available in the database.' It explicitly ties the output to the planet filter on GET /crystals, which clearly distinguishes it from sibling filter-listing endpoints like chakra, colors, or zodiac sign.

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

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

The description gives clear usage context: use these values as inputs to the planet filter on GET /crystals for astrology-based recommendations. It does not explicitly state when to prefer alternatives or list exclusions, but the intended workflow is unmistakable.

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

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

Annotations already communicate read-only/non-destructive behavior, and the description adds two useful behavioral traits beyond that: responses are non-deterministic ('different crystal on each request') and the payload is a teaser rather than full property data. It does not describe response shape, but the core non-determinism is disclosed.

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

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

The primary behavior is front-loaded in the first sentence, and the following sentences add concrete routing guidance. The use-case list is slightly repetitive with the 'discovery teaser' framing, but the description remains compact and each sentence earns its place.

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

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

For a zero-required-parameter read-only tool, the description plus full schema coverage is sufficient to invoke correctly. It explains what the endpoint returns, its key randomness caveat, and which alternative endpoints to use for detail or deterministic daily use; no output schema exists, but the simple random-crystal response does not require more.

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

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

Schema description coverage is 100%, so the schema fully documents the lang and compact parameters. The description adds no parameter-level meaning, which is acceptable because the schema already carries the burden; baseline 3 applies.

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

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

The first sentence names a specific operation ('Get a randomly selected healing crystal') and frames it as a discovery teaser, so an agent immediately knows what it does. It also clearly distinguishes the tool from the many get_crystals_* siblings by the random-selection behavior and by explicitly naming the /crystals/{id} and /daily alternatives.

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

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

The description provides direct usage guidance: use this for discovery/surprise/roulette features, and explicitly routes agents to the detail endpoint for complete healing properties and to the /daily endpoint when a deterministic daily crystal is needed. This is an explicit when-to-use vs. when-not-to-use statement.

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

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 established. The description adds useful behavioral context beyond annotations, notably that results contain 'summary data' rather than full healing properties, and that matching spans 'names, healing keywords, descriptions, and spiritual/emotional/physical meaning fields.' This helps an agent set correct expectations about output scope without contradicting the annotations.

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

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

The description is five short, purposeful sentences with the primary action front-loaded. Each sentence earns its place: what the tool does, what fields it matches, what it returns, when to use the detail endpoint, and recommended use cases. 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.

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

Given the 5-parameter schema with 100% coverage, read-only annotations, and no output schema, the description covers the essential decision points: what is searched, what is returned, when to use the detail endpoint, and typical use cases. The main omission is any mention of pagination or language fallback behavior, but those are already thoroughly documented in the input schema, so the description remains sufficient for correct invocation.

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

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

Schema description coverage is 100%, so the structured schema already documents q, lang, limit, offset, and compact thoroughly. The description still adds meaning by clarifying the q parameter's searchable domains with the more specific phrase 'spiritual/emotional/physical meaning fields' and by noting results are summaries, which helps interpret the q and limit parameters. This is above the baseline but not heavily compensated because the schema already carries most parameter detail.

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

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

The description opens with a specific verb and resource: 'Search for healing crystals by keyword or name.' It goes on to enumerate exactly which fields are matched, and explicitly distinguishes this tool from the detail endpoint by stating it 'Returns summary data' and directing users to the /crystals/{id} endpoint for full properties. This clearly separates it from the get_crystals_id and other sibling list tools.

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

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

The description names concrete use cases: 'building crystal search bars, keyword-based recommendation features, and healing property lookups.' It also provides an explicit alternative for full healing properties: 'Use the /crystals/{id} detail endpoint.' However, it does not address when to prefer sibling filter tools like get_crystals_chakra or get_crystals_element, so routing guidance is good but not exhaustive.

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

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 value by noting that only summary data is returned and that full healing properties require the detail endpoint. It does not disclose pagination defaults or compact output behavior, though those are documented in the input schema.

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

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

The description is concise and front-loaded: the core action comes first, then the response type, then routing guidance. The final sentence about personalized recommendations is slightly use-case-oriented rather than operational, but it is not excessive and the overall length is appropriate.

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

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

For a read-only lookup tool with a rich input schema and no output schema, the description provides enough context: what it returns, what inputs are valid, and where to go for deeper data. Pagination, language, and compact-shape behavior are already covered by parameter descriptions, so nothing critical is missing for selecting and invoking the tool.

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

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

Schema description coverage is 100%, with detailed descriptions for the sign enum, case-insensitivity, language support, pagination, and compact mode. The description reinforces that the tool is zodiac-sign-driven but does not add parameter meaning beyond what the schema already provides, matching the baseline for high schema coverage.

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

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

The description opens with a specific verb and resource ('Get healing crystals and gemstones associated with a specific zodiac sign') and explicitly says it returns summary data, which distinguishes it from sibling tools like get_crystals_birthstone_month or get_crystals_chakra. The statement that it supports all 12 signs further anchors the tool's scope.

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

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

The description gives clear context for when to use this tool: when the user wants crystals or gemstones for a zodiac sign. It also directs the agent to the '/crystals/{id}' detail endpoint when full healing properties are needed, which is a useful alternative. It does not explicitly name sibling tools for exclusion, but the guidance is sufficient.

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

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

With readOnlyHint=true and destructiveHint=false in annotations, the description need not re-state safety. It adds value by revealing determinism, date-based consistency, and seed-date behavior, which are beyond the annotations.

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

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

Three concise sentences: the core behavior, an alternative endpoint, and relevant use cases. It is front-loaded and every sentence earns its place.

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

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

The description covers what the tool returns, its determinism, and points to the richer endpoint for full properties. Since there is no output schema, a bit more detail about the response shape would improve completeness, but the description is adequate for selecting and invoking the tool.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds only a light conceptual note about determinism and date seeds, which is helpful but not a substitute for full parameter documentation.

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

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

The description states a specific verb ('Get'), a precise resource ('crystal of the day'), and a defining behavior ('deterministic crystal based on the current date... ensuring all users see the same crystal'). This distinguishes it from siblings such as get_crystals_random and from the more complete /crystals/{id} detail endpoint.

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

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

It gives clear usage context: 'Perfect for daily guidance features, push notifications, wellness app widgets, and crystal journal integrations.' It also explicitly routes users needing full properties to '/crystals/{id}', providing a concrete alternative.

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