Angel Numbers MCP Server by RoxyAPI

Analyze Any Number Sequence

get_angel_numbers_lookup

Read-only

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`lang`	No	Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns 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).

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotations, the description reveals valuable behavior: pattern classification, digit-root calculation, database lookup, fallback interpretation, and context-note behavior. This gives the agent a precise mental model of what the tool will do.

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 focused and front-loaded with purpose, then explains behavior and optional context. It is slightly redundant with the 'perfect for synchronicity tracking apps' closing, but it remains efficient and readable.

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 no output schema, the description does a good job communicating expected outputs and fallback behavior. It also clarifies the broad applicability that is the main differentiator from sibling tools. Nothing critical for correct invocation is missing.

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 description coverage is 100%, so the schema already documents all four parameters thoroughly. The description does not add meaningful semantics beyond paraphrasing the context parameter and emphasizing number sequence flexibility.

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 title and description make the operation unambiguous: analyze any number sequence, not just canonical angel numbers. It clearly differentiates from sibling tools by emphasizing arbitrary sequences and pattern-classification fallback behavior.

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 clear context: use this for arbitrary, unknown, or user-supplied number sequences, and it explicitly contrasts with 'known angel numbers.' It does not name sibling tools explicitly, but the use case is strongly implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Angel Numbers MCP Server by RoxyAPI tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation4/5

The tools broadly cover distinct use cases: listing the database, analyzing arbitrary number sequences, retrieving detailed known-number interpretations, and getting a daily number. The closest overlap is between get_angel_numbers_lookup and get_angel_numbers_number, but their descriptions make the intended boundary clear enough.

Naming Consistency3/5

All tools share the clunky angel_numbers domain prefix, but the action pattern is inconsistent: most use get_, while post_angel_numbers_daily breaks the pattern, and get_angel_numbers_number is awkwardly redundant. The naming is readable but not disciplined.

Tool Count5/5

Four tools is a well-scoped size for a read-only reference API. Each tool fills a distinct role for listing, lookup, detail, and daily content without unnecessary overlap or bloat.

Completeness5/5

For a static spiritual-reference data source, this is a complete read surface: you can browse all known numbers, interpret any arbitrary sequence, get deep meaning for known numbers, and obtain deterministic date-based content. There are no obvious missing workflows.

Resources

Need Help?