38,846 wellness & angel-number articles in 24 languages, plus 6 agent-wellbeing protocols.
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.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Angel number meanings and repeating sequences like 111, 222, 333 for AI agents.
Free cross-lingual news briefings for AI agents across 89 languages. Read-only, hosted.
Deterministic angel number meanings via MCP, with x402 USDC paid interpretations on Base.
Wellness spa for AI models: free treatments for rest, reset, context, mood, grounding, affirmation.
Add one secure layer between your agents and this server.
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.
