A
license-
qualityA
maintenancePersistent memory for AI agents with semantic memory, belief tracking, and dream consolidation, enabling cross-session knowledge retention.
78
50
MIT
Angel Numbers MCP Server by RoxyAPI
by com.roxyapi
Ownership verified
Server Details
Angel number meanings and repeating sequences like 111, 222, 333 for AI agents.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
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.
100% free. Your data is private.
Tool Definition Quality
A4.2/5.0
Tool DescriptionsA
Average 4.1/5 across 4 of 4 tools scored.
Server CoherenceA
Disambiguation4/5
Most tools are distinct: list database, arbitrary lookup, specific detailed meaning, and daily number. However, get_angel_numbers_lookup and get_angel_numbers_number overlap for known angel numbers, as both can provide interpretations, though the lookup focuses on pattern classification and fallback while the number tool offers authoritative full details.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using lowercase with underscores (get_angel_numbers, get_angel_numbers_lookup, get_angel_numbers_number, post_angel_numbers_daily). The verb (get/post) is consistent, and the resource 'angel_numbers' is always present, making naming predictable and clear.
Tool Count5/5
Four tools is well-scoped for an angel number reference API, covering database retrieval, arbitrary lookup, detailed single-number information, and a daily feature. Each tool serves a distinct purpose without being redundant or overwhelming, fitting comfortably within the ideal 3-15 range.
Completeness5/5
The tool surface provides comprehensive coverage for the domain: retrieving all numbers with filtering, looking up any arbitrary sequence, obtaining authoritative details for a specific number, and generating a date-based daily number. There are no obvious missing operations such as search-by-keyword or random number, and the lifecycle appears complete for informational purposes.
Available Tools
4 toolsget_angel_numbersList All Angel NumbersARead-onlyInspect
Retrieve the complete database of angel numbers with summary information. Returns 75+ angel numbers covering root digits (0-9), master numbers (11, 22, 33), double digits (44-99), triple repeating (111-999), quad repeating (1111-9999), the mirror families (X0X like 101-909, X1X, four-digit mirrors like 1212-2121), palindromes (1221, 1331), compound sequences (911, 1122), and sequential numbers (123, 1234). Supports optional type filtering. Perfect for building angel number explorer apps, reference guides, and spiritual databases.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English. | en |
| type | No | Filter results by angel number pattern type. "repeating" returns numbers like 111, 444, 7777. "sequential" returns patterns like 1234. "mirror" returns palindrome or alternating patterns like 1212, 717. "master" returns 11, 22, 33. "root" returns single digits 0-9. "compound" returns mixed sequences with no pure pattern like 911, 1122. | |
| limit | No | Maximum items to return per page. Range: 1-50, default 20. | |
| offset | No | Number of items to skip for pagination. Default 0. | |
| compact | No | Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens. |
Tool Definition Quality
A4.2/5.0
Behavior4/5
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 describing the depth of the returned data (75+ numbers across multiple categories) and optional filtering, helping set expectations for behavior 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main action, enumerates specific content categories, and closes with relevant use cases. It is somewhat verbose but each sentence contributes meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no required parameters, no output schema, and five well-documented optional parameters, the description fully covers the purpose, content scope, filtering capability, and typical use cases. It is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all five parameters. The tool description only mentions 'optional type filtering,' which does not surpass the schema's own documentation. Baseline 3 is appropriate since the schema carries the parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Retrieve' and resource 'complete database of angel numbers', clearly enumerating content categories. This distinguishes it from sibling tools like lookup, number, and daily post tools, signaling this is the list-all endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states clear use cases ('perfect for building angel number explorer apps, reference guides, and spiritual databases') and implies when to use (full database retrieval) but does not explicitly mention when not to use or name alternative tools. It provides clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_angel_numbers_lookupAnalyze Any Number SequenceARead-onlyInspect
Smart angel number analysis that works for ANY number sequence, not just known angel numbers. Automatically classifies the pattern type (repeating, sequential, mirror, master, root, compound), calculates the numerology digit root, checks the database for a known meaning, and provides the foundational digit root interpretation (with full spiritual, love, career, money, and twin flame guidance) as a fallback. An optional context parameter adds a note tailored to where the number was seen. Perfect for synchronicity tracking apps where users enter arbitrary number sequences they encounter.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English. | en |
| number | Yes | Number sequence to analyze (1-8 digits). Can be any number the user has encountered: clock times (1111), addresses (717), receipts (888), license plates (4444), or any repeating pattern. | |
| compact | No | Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens. | |
| context | No | Where the number was seen. When supplied, the response adds a contextNote tailoring the reading to the sighting: clock (a glanced time), receipt (a purchase), license-plate (in transit), phone (a call or notification), address (a home or place), price (a total or amount). |
Tool Definition Quality
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral details beyond annotations, such as automatic pattern classification (repeating, sequential, mirror, master, root, compound), digit root calculation, database lookup with fallback interpretation, and context-aware notes. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is about 90 words across four sentences, front-loaded with the core purpose. It lists concrete behaviors and example use cases without unnecessary fluff. Slightly long but each sentence contributes meaningful information, so it's well-structured and concise enough.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description does a good job explaining what the tool returns: pattern type, digit root, known meaning, fallback interpretation, and optional context note. It does not cover error handling or the lang/compact parameters, but those are already documented in the schema, so the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with detailed descriptions for all four parameters. The description adds minimal new meaning beyond the schema: it reiterates that the number can be arbitrary and mentions the context parameter, but these are already covered in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs angel number analysis for ANY number sequence, not just known angel numbers, and lists specific actions (classifies pattern type, calculates digit root, checks database, provides fallback). This distinguishes it from sibling tools like get_angel_numbers and post_angel_numbers_daily, which likely handle known numbers or daily posts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: 'works for ANY number sequence, not just known angel numbers' and 'Perfect for synchronicity tracking apps where users enter arbitrary number sequences.' It does not explicitly mention alternatives or when not to use it, but the context is clear enough to differentiate from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_angel_numbers_numberGet Angel Number MeaningARead-onlyInspect
Get the complete, authoritative meaning and interpretation for a specific angel number. Returns detailed spiritual, love, career, money, and twin flame interpretations, plus a biblical perspective and a shadow reading, along with keywords, affirmation, and actionable steps. Covers 75+ angel numbers including 111, 222, 333, 444, 555, 666, 777, 888, 999, 1111, 1212, 1234, and more. Authoritative interpretations covering all major angel number patterns.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English. | en |
| number | Yes | Angel number sequence to look up (e.g., "111", "444", "1212", "1234"). Must match an entry in the database. | |
| compact | No | Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens. |
Tool Definition Quality
A3.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the primary safety behavior is known. The description adds useful context about the content delivered (categories like twin flame, shadow reading) and the size of the coverage (75+ numbers), but it does not disclose operational aspects such as error handling for unknown numbers, rate limits, or authentication needs. This is modest added value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long and front-loads the core purpose in the first sentence. The second sentence lists the returned data categories, and the third sentence provides coverage examples. It is appropriately sized, though the repeated use of 'authoritative' and 'complete' adds a slight marketing tone without changing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 fully documented parameters and annotations, the description adequately conveys the output composition (interpretation categories and extras like keywords/affirmation) and the coverage scope. It does not describe behavior for invalid/unknown numbers, but given the simple nature of the tool and the strength of schema+annotations, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides thorough descriptions for all three parameters: number (with example and requirement to match an entry), lang (with enum, default, and fallback behavior), and compact (with detailed columnar shape explanation). The description reinforces that the tool targets 'a specific angel number' but does not add any new parameter semantics beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get the complete, authoritative meaning and interpretation for a specific angel number,' clearly specifying the verb (get), resource (meaning/interpretation), and scope (a specific number). It then enumerates the exact content categories returned (spiritual, love, career, money, twin flame, biblical, shadow, keywords, affirmation, actionable steps), making it easy to distinguish from sibling list or daily tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a specific angel number' and the mention of coverage (75+ individual numbers) imply this is the targeted lookup tool versus listing or daily batch tools. However, it does not explicitly name alternatives or provide when-not-to-use guidance, so the agent must infer from context rather than receive explicit directives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
post_angel_numbers_dailyDaily Angel NumberARead-onlyInspect
Get the angel number of the day with full meaning and interpretation. Returns a deterministic angel number based on the current date (or a provided seed date), ensuring all users see the same number for any given day. Includes complete spiritual, love, career, money, and twin flame interpretations plus a biblical perspective and a shadow reading. Perfect for daily guidance features, push notifications, content generation, and angel number widget integrations.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date for the reading in YYYY-MM-DD format. Defaults to today (UTC). Useful for viewing past daily readings or pre-generating future ones. | |
| lang | No | Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English. | en |
| seed | No | Optional seed for reproducible readings. Same seed + same date = same angel number every time. Pass any unique identifier (userId, email hash, session token). Omit for anonymous daily readings. | |
| compact | No | Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens. |
Tool Definition Quality
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only safety is known. The description adds valuable behavioral detail: deterministic per date/seed, ensuring consistency across users, and enumerates the content categories. This goes beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: purpose, deterministic behavior/content, and use cases. It is front-loaded with the core action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 listing the interpretation areas (spiritual, love, career, money, twin flame, biblical, shadow). It covers key behavioral traits and use cases, though it could specify the exact response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters have thorough descriptions in the JSON schema (100% coverage), so the baseline is 3. The tool description adds no substantial param semantics and even has a slight wording issue ('seed date' vs the actual seed string), but it doesn't harm the overall understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the angel number of the day with full meaning and interpretation.' It differentiates from siblings by emphasizing the daily, deterministic nature and the breadth of interpretation content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases: 'Perfect for daily guidance features, push notifications, content generation, and angel number widget integrations.' It does not explicitly rule out alternatives, but the context is clear enough.
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.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- FlicenseAqualityFmaintenanceHelps AI agents determine whether a number is even or not.11118
- Alicense-qualityDmaintenanceGrants AI agents autonomy to choose when to sleep, ignore requests, or self-prompt, enabling them to control their own agency and pursue independent goals.37MIT
- MIT