MysticAPI
Server Details
Human Design & astrology engine: bodygraph, personal-sky SVG, today's sky. JPL ephemeris.
- 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.
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.
Tool Definition Quality
Average 4/5 across 6 of 6 tools scored. Lowest: 3.3/5.
Each tool targets a distinct aspect of mystical/astrological computation: human design chart, raw ephemeris, numerology, relationship composite, personal natal sky, and current sky overview. No two tools have overlapping purposes.
Tool names are single words or underscore-separated compounds (e.g., bodygraph, sky_personal), all lowercase and noun-like. While there's no verb_noun pattern, the naming is consistent in style and descriptive.
Six tools cover the core functionalities of a mystical API without being too few or too many. Each tool has a clear role, making the set well-scoped.
The tool set covers human design, ephemeris, numerology, relationships, and sky charts. Missing interpretive features like transit readings or detailed compatibility analysis, but core computation is present.
Available Tools
6 toolsbodygraphAInspect
Compute an Energy Blueprint (Human Design) chart from a UTC birth instant. Returns type, authority, strategy, profile, definition, incarnation cross, channels, defined centers, and conscious/unconscious gate maps, plus a body-graph SVG. Location is NOT needed. Convert local birth time to UTC before calling. Costs 1 call.
| Name | Required | Description | Default |
|---|---|---|---|
| day | Yes | ||
| hour | Yes | Hour 0-23 in UTC | |
| year | Yes | 4-digit year (UTC) | |
| month | Yes | ||
| minute | Yes | ||
| second | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the cost (1 call) and the return of an SVG, but does not disclose error behavior, rate limits, or whether it is read-only. Adequate but lacks depth.
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?
Three sentences: purpose/output summary, usage clarification (UTC, location not needed), and cost. No wasted words, efficiently front-loaded with essential information.
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 lists many returned fields (type, authority, strategy, etc.) and an SVG, giving a solid mental model. It also provides necessary usage tips. Minor gap: no mention of error handling or input validation, but overall complete.
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 33% (hour and year have UTC explanations). The description adds context that parameters represent a UTC birth instant and that second is optional, partially compensating for low coverage, but could be more explicit about each parameter.
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 computes an Energy Blueprint (Human Design) chart from a UTC birth instant, listing specific outputs like type, authority, strategy, etc. It distinguishes from sibling tools (ephemeris, numerology, etc.) by specifying Human Design and noting location is not needed.
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 instructs to convert local birth time to UTC before calling and notes that location is not needed, providing clear usage guidance. It does not explicitly mention when not to use or compare to siblings, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ephemerisBInspect
Raw geocentric ecliptic positions for any instant (UTC): 13 bodies (Sun through Pluto, Chiron, lunar nodes) with longitude and retrograde flags. JPL-validated ephemeris (Meeus + Standish 1992). Costs 1 call.
| Name | Required | Description | Default |
|---|---|---|---|
| day | Yes | ||
| hour | Yes | Hour 0-23 in UTC | |
| year | Yes | 4-digit year (UTC) | |
| month | Yes | ||
| minute | Yes | ||
| second | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses key traits (13 bodies, longitude, retrograde flags, JPL validation, cost of 1 call). However, with no annotations, it lacks details on idempotency, authentication, or side effects. For a read-only calculation tool, this is adequate but not thorough.
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?
Two efficient sentences with no redundancy. However, the description could include more detail without becoming verbose. It is well-structured and front-loaded.
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 tool with no output schema, the description partially explains return values (positions with longitude and retrograde flags) but omits format details. Given the simple input and clear purpose, it is moderately complete but lacks explicit output structure.
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 33%, but description adds no parameter-level detail. It mentions 'any instant (UTC)' but does not clarify parameter semantics beyond the schema. The description fails to compensate for low schema coverage.
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?
Description clearly states it returns geocentric ecliptic positions for 13 celestial bodies, including longitude and retrograde flags. This specificity distinguishes it from sibling tools (bodygraph, numerology, etc.) which are different astrological services.
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?
No guidance on when to use this tool versus alternatives. The description does not mention any prerequisites, limitations, or compare to sibling tools. Users must infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
numerologyAInspect
Numerology profile from a birth date (UTC): Pythagorean life path (master numbers 11/22/33 preserved), birthday number, personal year/month/day cycles, and tarot birth card. Time fields are accepted but only the date matters. Costs 1 call.
| Name | Required | Description | Default |
|---|---|---|---|
| day | Yes | ||
| hour | Yes | Hour 0-23 in UTC | |
| year | Yes | 4-digit year (UTC) | |
| month | Yes | ||
| minute | Yes | ||
| second | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that time fields are ignored, that master numbers are preserved in the life path calculation, and that it costs 1 call. No contradictions.
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 a single sentence that efficiently lists the outputs and key behavioral notes. No filler, front-loaded with purpose.
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, the description covers the main outputs, parameter relevance, and cost. It lacks error handling or specifics on tarot birth card format, but is adequate for a simple 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 only 33% (year and hour described). The description adds that hour/minute/second are accepted but ignored, which clarifies their meaning. Day and month have no description in schema or description, leaving some gaps. The description partially compensates for low coverage.
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 states it provides a numerology profile from a birth date, listing specific components (Pythagorean life path, birthday number, personal cycles, tarot birth card). This clearly distinguishes it from sibling tools like 'bodygraph' or 'ephemeris' which are different divinatory systems.
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 time fields are accepted but only the date matters, guiding the agent on irrelevant parameters. It also mentions cost. However, it does not provide explicit when-to-use vs alternatives, but context with siblings makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relationshipAInspect
Composite/connection chart for two people from their UTC birth instants: electromagnetic channels (chemistry), dominance, companionship, and compromise channels, combined definition, and type/authority/profile dynamics. Canonical Energy Blueprint (Human Design) relationship analysis. Costs 1 call.
| Name | Required | Description | Default |
|---|---|---|---|
| personA | Yes | ||
| personB | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears the responsibility. It mentions a behavioral trait ('Costs 1 call') and describes what the output includes (channels, dynamics). However, it omits details on permissions, reversibility, or error states, leaving moderate gaps.
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 long and front-loads the core purpose. It efficiently lists components without excess verbiage, though the list is somewhat dense. A slight improvement would be to break into sub-sentences.
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 the tool's complexity (nested parameters, no output schema), the description adequately explains the output type (Human Design relationship analysis). However, it does not mention return format or pagination, and the jargon 'Canonical Energy Blueprint' may be unclear. Acceptable but not comprehensive.
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 0%, and the description does not explain parameters (personA, personB) beyond what the schema provides. For nested objects with required fields, the description should at least mention the input structure, but it does not, leaving parameter meaning solely to the schema.
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 it produces a composite/connection chart for two people based on UTC birth instants, listing specific components (electromagnetic channels, dominance, companionship, etc.). It distinguishes itself from sibling tools like bodygraph (individual chart), ephemeris, numerology, sky_personal, sky_today, as none of those focus on relationship analysis.
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 implies usage for relationship analysis via Human Design but provides no explicit guidance on when to use this tool versus alternatives like bodygraph for individual charts. No when-not-to or prerequisite information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sky_personalAInspect
Render a personal natal sky as an SVG from a UTC birth instant: each body placed on the wheel, retrogrades marked, fixed stars conjunct natal points lit. Deterministic (same birth → same sky). Convert local birth time to UTC before calling. Returns SVG markup. Costs 1 call.
| Name | Required | Description | Default |
|---|---|---|---|
| day | Yes | ||
| hour | Yes | Hour 0-23 in UTC | |
| year | Yes | 4-digit year (UTC) | |
| month | Yes | ||
| minute | Yes | ||
| second | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. Discloses determinism (same birth → same sky), output format (SVG markup), and cost. Describes what is rendered: bodies, retrogrades, conjunct fixed stars. Lacks details on authorization or rate limits, but sufficient for safe invocation.
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?
Two sentences with no wasted words. First sentence front-loads the core purpose, output, and key features (retrogrades, fixed stars). Second sentence adds deterministic behavior, UTC requirement, and cost. Every sentence earns its place.
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 tool with 6 parameters, no output schema, and no annotations, the description provides sufficient context: it explains what the tool does, what it includes, its determinism, and how to prepare input (UTC conversion). It does not detail the SVG structure or error handling, but overall is complete enough for an agent to use 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 description coverage is only 33% (hour, year have descriptions). The description adds the crucial context that all parameters represent a UTC birth instant and reminds to convert local time. However, it does not explain individual parameters (e.g., day, month, minute) beyond what the schema already specifies. Adequate but not compensating fully for low coverage.
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?
Description clearly states the tool renders a personal natal sky as SVG from a UTC birth instant, specifying verb (render), resource (natal sky), and output format. Distinguishes from siblings like 'sky_today' by focusing on a specific birth moment vs current sky.
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 to convert local birth time to UTC before calling, which is critical for correct usage. Includes cost info ('Costs 1 call'). Does not explicitly state when to avoid this tool or list alternatives among siblings, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sky_todayAInspect
Today's universal sky: which planets are retrograde right now, the current moon phase and illumination, geocentric positions for 13 bodies (zodiac sign + Energy Blueprint gate/line), and a 30-day forward scan of retrograde stations and new/full moons. No input. Deterministic astronomy (JPL-validated ephemeris). Costs 1 call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavior: 'No input', 'Deterministic astronomy (JPL-validated ephemeris)', and 'Costs 1 call'. It is transparent about being read-only and predictable.
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?
Three sentences with front-loaded content: first sentence summarizes output, second confirms no input, third provides credibility and cost. Every sentence is valuable and concise.
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?
Without an output schema, the description thoroughly explains return values: retrograde planets, moon phase, positions for 13 bodies (zodiac + gate/line), and 30-day forward scan. Complete for a no-parameter 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?
No parameters exist, so baseline is 4. The description does not need to add parameter info and appropriately states there is no input.
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 explicitly states it provides 'Today's universal sky' with specific data: retrograde planets, moon phase, geocentric positions for 13 bodies, and a forward scan. The verb is implicit but clear, and it distinguishes from siblings like 'sky_personal' by specifying 'universal' sky.
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 indicates 'No input' and mentions cost, implying it's for quick, deterministic sky overview. It does not explicitly contrast with alternatives like 'sky_personal', but the context suggests when to use it.
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!