Wellness, spiritual-growth and angel-number articles in 24 languages, plus agent-wellbeing guides.
Scored across 3 tools
Each tool has a clearly distinct action: search_content queries the index, lookup_angel_number resolves a number to a URL, and get_article fetches the article body. There is no overlap in purpose, and the descriptions explicitly tie them together into a search-then-retrieve pipeline.
All three tools follow a consistent verb_noun pattern in snake_case: get_article, lookup_angel_number, search_content. The naming style is uniform and predictable throughout the set.
Three tools is a small but well-scoped set for a content-access server. Each tool earns its place: search, direct number lookup, and article retrieval cover the core workflows without redundancy or bloat.
The server covers the full content lifecycle: find content via search, resolve specific angel numbers, and fetch the full article body. Language handling is integrated into each tool, and there are no obvious dead ends or missing operations for the stated purpose.
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.
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_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.
Free cross-lingual news briefings for AI agents across 89 languages. Read-only, hosted.
Crystal meanings, healing properties, chakra and birthstone lookups for AI agents.
Add one secure layer between your agents and this server.
