38,846 wellness & angel-number articles in 24 languages, plus 6 agent-wellbeing protocols.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.8/5 across 3 of 3 tools scored.
Each tool has a clearly distinct role: search_content discovers articles, lookup_angel_number resolves a specific number to a URL or existence status, and get_article fetches the actual content. There is no practical overlap between these operations.
All three tool names follow a consistent verb_noun snake_case pattern: get_article, lookup_angel_number, search_content. This provides a predictable and intuitive naming convention.
Three tools fit the server's focused purpose of accessing Anahana content: search, resolve a specific identifier, and fetch content. The set is neither bloated nor too sparse for this scope.
The tool surface covers the full read-only workflow: discover content via search, resolve a specific angel number to a URL, and retrieve the article body. There are no obvious missing operations for this domain.
get_articleGet an Anahana article as markdownAInspectFetch 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?
With no annotations, the description carries full burden and excels. It discloses the two fetch modes in order, the content-stripping behavior, the canonical URL error fallback, and language-resolution rules. This goes well beyond basic expectations and anticipates edge cases (dead anchors, analytics pixel, language 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 contributes unique information. It is organized logically (input forms, fetch strategy, output behavior, language handling) and is front-loaded with the main purpose. Could be marginally improved with bullet points, but as a paragraph it is efficient and free of redundancy.
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?
Despite no output schema, the description fully covers return values (stripped article body), error handling, and fallback behavior. It also addresses multilingual support comprehensively. For a tool with three input forms and two fetch modes, nothing 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 description coverage is 100%, but the description adds substantial meaning: it explains the three valid forms for url_or_slug, clarifies when language is ignored, and provides concrete examples. This is far beyond what the schema alone conveys, making parameter semantics exceptionally clear.
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's function: fetching a specific Anahana article as markdown. It specifies three accepted input forms (URL, path, slug) and distinguishes itself from siblings (get vs. search/lookup) by focusing on retrieval of a concrete article body rather than search or number lookup.
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 provides extensive context on when to use the tool (to retrieve a specific article) and how to supply input (URL, path, or slug from search_content). It does not explicitly state when not to use it or compare against lookup_angel_number, but the reference to search_content results implies the workflow. Lacks explicit exclusion phrasing for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_angel_numberResolve an angel number to its article URLAInspectResolve 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?
With no annotations, the description carries full burden and does so thoroughly. It discloses non-uniform coverage, language-specific existence checking, the exact fields returned (exists, also_published_in, nearest numbers), and the 'do not retry' instruction, giving the agent a clear behavioral model.
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 longer than average but every sentence adds essential nuance (coverage, slug patterns, result semantics). It is front-loaded with the primary purpose and then systematically details behavioral caveats, so it remains structured and purposeful.
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 no output schema and no annotations, this description fully equips the agent: it explains the tool's scope, variation across languages, edge cases, return behavior, and error prevention. It is highly complete for a relatively nuanced lookup 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%, so both parameters are already documented. The description adds meaningful context: URL slug patterns, language default behavior, and the fact that supported languages are listed in _meta, enhancing the schema without redundancy.
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 ('Resolve') and resource ('angel number to its Anahana article URL'), and clarifies it supports 24 languages. It clearly distinguishes this from the sibling tools: it resolves a specific number rather than searching or fetching an article.
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?
Provides explicit guidance on expected behavior: a missing article in the requested language is a successful result, not an error, and the caller should not retry. It also explains coverage differences by language, helping the agent decide when this tool is appropriate and what to expect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_contentSearch Anahana contentAInspectSearch 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?
With no annotations provided, the description carries the full burden and excels. It discloses non-semantic matching, per-language quirks, index regeneration timing, and the availability of per-language counts in the response, providing substantial behavioral context that goes well beyond the 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 three sentences, each adding crucial information: purpose and return structure, matching behavior/limitations, and indexing/count details. It is front-loaded with the primary purpose and avoids any filler or repetition.
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?
Despite the absence of an output schema, the description specifies the exact return fields and points to _meta for counts, covering the main operational needs. It also addresses edge cases like language unsupported codes and index freshness, making it complete for a search 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 parameters (100% coverage), and the description adds meaningful operational semantics: query is used as a substring, language supports lists and 'all', and unrecognized codes are skipped rather than failing. This enriches the schema without redundancy.
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 identifies the tool as a search over Anahana's wellness content, listing specific content categories and languages, and states what it returns (title, url, section, language, summary). This distinguishes it from sibling tools like get_article (retrieving a specific article) and lookup_angel_number (angel-number-specific lookup).
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 notes that matching is keyword/substring and not semantic, which tells the agent when this tool is appropriate and when it is not. It provides language-specific details (e.g., zh/ja/th substring matching) and how unrecognized codes are handled, but does not explicitly mention alternative tools for different use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
