Wellness and angel-number articles in 24 languages, plus Nema products with prices and page links.
Scored across 5 tools
Each tool targets a distinct resource and action: fetch article, fetch product, list products, resolve angel number, search content. No overlapping purposes; lookup_angel_number and search_content have clearly different scopes (precise resolver vs keyword search).
All tools follow a consistent snake_case verb_noun pattern: get_article, get_product, list_products, lookup_angel_number, search_content. The convention is predictable and readable throughout.
Five tools is well-scoped for a read-only content and product access server. Each tool covers a clear, non-redundant function without overloading the surface.
Core read-only workflows are covered: fetching articles, searching content, resolving angel numbers, and browsing products. A minor gap is the absence of a direct list/browse articles by section or full article index, though search_content offers a workaround.
Fetch a specific Anahana article as markdown, given its full URL, site-relative path (e.g. "/en/angel-numbers/111-angel-number/"), or a bare slug from search_content results (e.g. "111-angel-number"). Tries two fetch modes against the live site in order: (1) content negotiation — GET the article URL with Accept: text/markdown; (2) the path-based markdown mirror at <article-url>index.md. Both are live. Page chrome (skip link, table of contents with dead anchors, back-to-top anchor, analytics pixel) is stripped, so what you get back is the article body. If both modes fail, returns a clear error naming the canonical HTML URL instead of silently failing. Works in all 24 languages: a full URL or a site-relative path already names its language, and a bare slug is resolved in the language given by language (English by default). Article slugs are identical across languages — only the title and body are translated — so the same slug plus a different language gives you the same article in that language.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language for a BARE SLUG, e.g. "ja". Ignored when url_or_slug is a full URL or a site-relative path, since those already carry their language prefix. Defaults to "en". | |
| url_or_slug | Yes | Full URL, site-relative path, or bare slug, e.g. "111-angel-number". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses more than the readOnlyHint/openWorldHint annotations: it explains the two fetch modes tried in order, that page chrome is stripped, that failure returns a clear error naming the canonical HTML URL, and that slugs are language-agnostic. This gives the agent a solid model of the tool's actual runtime behavior.
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 long but every sentence earns its place. It is logically ordered: accepted inputs, fetch strategy, output cleaning, error behavior, then language handling. There is no filler, and the most important usage constraint (input forms) comes first.
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?
With no output schema, the description still explains what the caller receives ('the article body') and what is removed. It also covers failure behavior, language behavior, and the multi-language edge case. The tool is complex, but the description leaves no major operational gap for an agent to call it 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% for both parameters, but the description adds meaning beyond the schema: it defines acceptable input forms, clarifies when 'language' is ignored, confirms the default, and gives concrete examples. This is valuable supplementary guidance rather than mere schema repetition.
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 specific verb ('Fetch'), a specific resource ('a specific Anahana article'), and the output format ('as markdown'). It also distinguishes itself from siblings by focusing on article retrieval versus search_content or lookup_angel_number, and by accepting full URLs, paths, or slugs from search results.
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, actionable conditions for when to call this tool: when you have a full URL, site-relative path, or bare slug from search_content. It explains how language resolution works and mentions fallback behavior, but it does not explicitly state when to prefer lookup_angel_number or search_content over this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one Nema by Anahana product by its sku from list_products (e.g. "complete-guide-en"): name, type, language, list price, currency, and url — the product's page on anahana.com, the only place to buy it. Paid products carry checkout_note: "buyers outside the US see a converted price with a 4% conversion fee at checkout". A sku that is in the catalog but not on sale returns available: false, a definitive answer; do not retry it. Read-only: no checkout, no payment link.
| Name | Required | Description | Default |
|---|---|---|---|
| sku | Yes | The product sku from list_products, e.g. "complete-guide-en". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, but the description adds substantial context beyond them: the available:false semantics for off-sale skus, the no-retry rule, the meaning of checkout_note with the 4% conversion fee, and the fact that url is the only purchase location. That is meaningfully more than the annotations convey.
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?
Front-loaded with the verb, resource, and return fields, then constraints. The checkout_note sentence is somewhat dense and quotes a long string, but each clause carries operational information rather than 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?
With no output schema, the description carries the burden of describing returns and does so (name, type, language, list price, currency, url, available, checkout_note). Combined with the read-only guarantee, an agent has everything needed to call and interpret 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 coverage is 100% and the schema already describes the single sku parameter with an example. The description only reinforces that the sku comes from list_products, adding little beyond the structured field, 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?
States a specific verb and resource ('Get one Nema by Anahana product by its sku'), names the source of the identifier (list_products), and enumerates the returned fields, so it is clearly distinguishable from list_products and the other content siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent where the sku comes from (list_products) and gives a when-not rule ('a sku that is in the catalog but not on sale returns available: false ... do not retry it'). It does not name alternative siblings for non-product lookups, so it falls short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the Nema by Anahana digital products on sale right now (for example angel-number guides and a personalized natal chart report). Each product has its sku, name, type (free_lead_magnet, one_time or bundle), language, list price and currency (e.g. "11.11" and "USD"), and url: the product's page on anahana.com, the only place to buy it. Paid products also carry checkout_note. Read-only: this server has no checkout or payment tool and never returns a payment link. The list is the site's own catalog, regenerated on every site deploy. Use get_product for one product.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Only products in this language, e.g. "en". One code, a comma-separated list, or "all". Omit to list every product on sale, in every language. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing that the server has no checkout or payment tool, never returns a payment link, that anahana.com is the only place to buy, and that the catalog is regenerated on every site deploy. These are real behavioral and freshness facts the agent cannot infer from readOnlyHint/openWorldHint.
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?
Front-loaded with purpose, then the return fields, then the read-only/behavioral notes, then the sibling routing. The field enumeration is slightly dense but earns its place because there is no output schema. No filler sentences.
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?
With no output schema, the description compensates by naming every returned field (sku, name, type, language, list price, currency, url, checkout_note) plus the type enum values. Combined with the payment/checkout caveat and sibling pointer, an agent has everything needed to call and interpret it.
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 single 'language' parameter is fully documented in the schema (including the 'all' and comma-list forms), so the description correctly does not duplicate it. Baseline 3 applies since the schema carries the parameter burden.
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?
States a specific verb ('List') and resource ('the Nema by Anahana digital products on sale right now') and enumerates what each item contains. It clearly distinguishes itself from the sibling get_product, which retrieves a single product.
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 closing sentence 'Use get_product for one product' gives an explicit alternative and the condition that selects it, so bulk-listing vs single-fetch is unambiguous. It stops short of stating exclusions against the other siblings (get_article, search_content), so it is 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.
Resolve a specific angel number (e.g. "111", "1234", "22") to its Anahana article URL, in any of 24 languages. Slugs are English-stable across every language — most numbers are "-angel-number"; the single digits 1-9, the master numbers 11/22/.../99, and the outlier 828 use "angel-number-" — so only the title and body differ between languages. COVERAGE, however, is not uniform: en/de/es/ru publish 568 distinct numbers, the other 20 languages publish 519, so a number can exist in English and genuinely not exist in Japanese. Existence is therefore always answered against the language you asked for, from an index the site regenerates on every deploy. A well-formed number with no article in that language is a successful result with exists: false, a definitive message, also_published_in naming the languages that DO have it, and the nearest numbers published in your language — not an error. Do not retry it.
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | The angel number as digits, e.g. "111" or "828". | |
| language | No | Language to resolve in, e.g. "ja". Defaults to "en", which is the pre-1.2.0 behavior. Supported codes are listed in _meta.languages_supported. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral detail beyond the readOnlyHint annotation: coverage differs by language, existence is judged per requested language, 'exists: false' is a successful outcome with additional fields, and the site's index is regenerated on every deploy. It also warns against retrying, which is genuine behavioral guidance an agent could not infer from the schema or 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 dense but structured: action first, then slug rules, coverage, existence semantics, and a retry warning. Every sentence contributes meaningful information, though the length is substantial. It is front-loaded with the core purpose and avoids fluff, but is not as compact as it could be.
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 lookup tool with no output schema, the description covers edge cases well: language-specific existence, non-uniform coverage, the exists:false result shape, also_published_in, nearest numbers, and the no-retry rule. The only gap is that it never explicitly describes the success response when exists:true beyond the title's promise of an article URL, but overall this is a complete and actionable definition.
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?
Although schema description coverage is 100%, the description enriches both parameters. For 'number' it supplies slug patterns and an outlier ('828'); for 'language' it explains defaults, supported languages, and coverage variance. This goes beyond the schema's basic pattern and example descriptions.
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 precise verb and resource: 'Resolve a specific angel number... to its Anahana article URL, in any of 24 languages.' It names specific examples ('111', '1234', '22') and states the slug conventions, making the tool's purpose unmistakable and clearly distinct from the sibling tools get_article and search_content.
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 clearly establishes the tool's use case: resolving an angel number to an article URL, with language and coverage semantics explained. It also gives an important operational instruction ('Do not retry it'). However, it does not explicitly contrast this tool with the sibling tools or state when not to use it, so it stops short of a full when/when-not explanation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Anahana's wellness content — angel numbers, astrology, zodiac, tarot, crystals, yoga, meditation, breathing exercises, mental and physical health, and more — in any of 24 languages. Returns matching articles with title, url, section, language, and a short summary. Matching is KEYWORD/SUBSTRING over title, description, section and slug; it is NOT semantic search, in any language. For zh, ja and th the query is not word-segmented, so it is matched as one substring. The index is regenerated on every site deploy; exact live per-language document counts are in each response's _meta and at https://www.anahana.com/content-index/manifest.json.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search keywords, e.g. '111 angel number' or 'box breathing'. | |
| language | No | Language to search. Omit for English (the default and the pre-1.2.0 behavior). One code ("de"), a comma-separated list ("de,fr,ja"), or "all" to search every indexed language. Supported codes are listed in _meta.languages_supported: en, de, it, es, nl, fr, sv, pl, cs, fi, hu, ro, ru, da, no, pt, tr, el, id, uk, ja, ko, zh, th. Unrecognized codes are skipped with a note rather than failing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint=true and openWorldHint=false, so safety is covered. The description goes well beyond annotations by disclosing the matching algorithm (over title, description, section, slug), the lack of word-segmentation for zh/ja/th, index regeneration on deploy, and the presence of per-language counts in _meta. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense but purposeful sentences: scope, return fields, matching behavior, and index freshness. Every sentence earns its place, and the most decision-relevant caveat (not semantic search) appears early. No redundancy with schema or annotations.
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 search tool with no output schema, the description specifies the exact return fields (title, url, section, language, summary), covers the main matching caveats, and tells the agent where to find live document counts. Given the tool's complexity (24 languages, substring matching, edge cases), nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful behavior beyond the schema: it explains that query is matched as a substring/keyword, that zh/ja/th are treated as a single unsegmented substring, and that unrecognized language codes are skipped rather than failing. These nuances help an agent use the parameters correctly.
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?
States a specific verb ('Search') and resource ('Anahana's wellness content'), enumerates content categories and language coverage. The scope is clear and distinct from siblings: it searches across content broadly rather than retrieving a single article (get_article) or performing a specialized angel-number lookup (lookup_angel_number).
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 the tool: keyword/substring search over wellness content in 24 languages. It explicitly warns that matching is NOT semantic search, which prevents a common misuse. However, it does not name sibling tools or state 'use get_article when you already have an article ID,' leaving some exclusion logic implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_productlist_productsget_article1 field changedInput schema / properties / languageAdded value: +{
+ "description": "Language for a BARE SLUG, e.g. \"ja\". Ignored when url_or_slug is a full URL or a site-relative path, since those already carry their language prefix. Defaults to \"en\".",
+ "type": "string"
+}lookup_angel_number1 field changedInput schema / properties / languageAdded value: +{
+ "description": "Language to resolve in, e.g. \"ja\". Defaults to \"en\", which is the pre-1.2.0 behavior. Supported codes are listed in _meta.languages_supported.",
+ "type": "string"
+}search_content1 field changedInput schema / properties / language / descriptionPrevious value: -"Language code. Only \"en\" is indexed in v1; other values return zero results with a note."New value: +"Language to search. Omit for English (the default and the pre-1.2.0 behavior). One code (\"de\"), a comma-separated list (\"de,fr,ja\"), or \"all\" to search every indexed language. Supported codes are listed in _meta.languages_supported: en, de, it, es, nl, fr, sv, pl, cs, fi, hu, ro, ru, da, no, pt, tr, el, id, uk, ja, ko, zh, th. Unrecognized codes are skipped with a note rather than failing."get_articlelookup_angel_numbersearch_contentAngel number meanings and repeating sequences like 111, 222, 333 for AI agents.
Vedic and Western astrology for AI agents: charts, dasha, matchmaking, panchanga, numerology, tarot.
Multilingual travel guides, gear picks and booking links for AI travel agents.
Gematria with typed transliteration, the 72 names, Tree of Life and Hebrew birthday for AI agents.
Add one secure layer between your agents and this server.
