AI Astrology Chat Endpoint: Why We Do Not Ship One

There is a category of astrology API that sells one seductive endpoint: post birth data plus a question, get back a paragraph of interpretation. One call, no LLM plumbing, ship by Friday. It is the most expensive convenience in this market, and the invoice is the smallest part of the price. What you actually pay is control, in the four places that decide whether an insight app keeps users past week two. This is the due-diligence version of that trade, written by the vendor that refuses to sell you the endpoint. Every number below was captured live against production, and every line of code is copied out of a repository you can clone.

Does a bundled AI chat endpoint actually save you any time?

Barely. It removes the glue code between a model and a tool call, which is a few minutes to an hour at best, and it shrinks every quarter because every major model vendor now speaks Remote MCP natively. In exchange it takes four things permanently. That is not a shortcut, it is a mortgage.

Here is the hour it saves, itemized honestly:

Now what it takes, and none of it comes back. The first four decide whether the product survives:

You are being asked to trade all six for an hour of integration work the model vendors have already automated.

On the cost row specifically: their unit is an AI query, yours is a user session, and an agent that chains four tool calls to answer one question spends four units. Deterministic calculations also cache and generated prose does not, so a repeat natal chart came back from us with x-cache: HIT while a chat endpoint bills again every time a user re-reads the same reading. The full markup arithmetic against published model token prices is in AI astrology API vs calculation infrastructure. This post is about what money cannot buy back.

Ready to keep all six? The Astrology API returns structured, typed JSON across 209+ endpoints and 14 insight domains on one key. See pricing.

How does an AI astrology chatbot actually work?

Three moving parts, and none of them are astrology-specific. An MCP client that fetches tool definitions once and caches them, a system prompt you own, and one streaming call that runs the tool loop until the model has what it needs. Everything below is copied from our MIT template at Templates, running on Next.js and the Vercel-maintained AI SDK (npm i ai, over 20M weekly downloads as of August 2026). That package is why switching models is no longer a project: one surface, one tool set, and every major provider behind the same call.

Step 1. Mount the servers. Tools from every server you connect merge into one set the model picks from. Mount location beside the domain server, because every chart tool needs latitude, longitude and an IANA timezone, and without it the user has to type coordinates by hand.

import { createMCPClient } from "@ai-sdk/mcp";

const client = await createMCPClient({
  transport: {
    type: "http",
    url: "https://roxyapi.com/mcp/astrology", // and /mcp/location, /mcp/tarot, ...
    headers: { Authorization: `Bearer ${process.env.ROXYAPI_KEY}` },
  },
});
const tools = await client.tools(); // fetched once, cached for the process lifetime

Step 2. Own the prompt. This is the artifact a bundled endpoint hides from you. Excerpted from src/lib/prompts.ts:

You are a warm, knowledgeable spiritual advisor powered by RoxyAPI.

PERSONALITY:
- Warm but direct. Not overly mystical or vague.
- Always ground interpretations in the actual data from tool results.

LOCATION FIRST, CHART SECOND (mandatory for every chart tool):
1. Call the location search tool with the nearest well-known city.
2. Read latitude, longitude, and timezone from the first returned city.
3. Call the chart tool and ALWAYS include timezone as that exact IANA string.

Ambiguous numeric dates: when both the day and the month could be 1-12,
do NOT guess the order. Ask once, naming both readings, then proceed.

MULTILINGUAL: detect the language of the incoming message and reply in it.

RESPONSE STYLE: never dump raw JSON. Interpret, explain, stay concise.

Sixty lines, every rule learned from a real failure. You can read it, version it, run evals against it, add your own guardrails and disclaimers, and rewrite one line at two in the morning when a user complains. None of that is possible with a prompt you cannot see, which is the part that matters most in a category where the model is writing about health, money and relationships under your brand.

Step 3. Run the loop. The whole handler, minus validation and rate limiting:

const result = streamText({
  model: getModel(),
  system: getSystemPrompt(),
  messages: await convertToModelMessages(messages),
  tools,
  stopWhen: stepCountIs(5), // cap the tool round-trips per message
});

return result.toUIMessageStreamResponse();

Step 4. Switch the provider. Same prompt, same servers, same tools, three vendors:

// LLM_PROVIDER = gemini | anthropic | openai
export function getModel() {
  switch (provider) {
    case "anthropic": return anthropic("claude-haiku-4-5-20251001");
    case "openai":    return openai("gpt-5-mini");
    case "gemini":
    default:          return google("gemini-2.5-flash");
  }
}

One environment variable. Nothing else moves: not the prompt, not the tools, not the memory schema, not the rendering.

What one message actually does

A user types "Read my chart. 15 July 1990, 14:30, New York." The model then, unprompted by any routing code you wrote:

1. Calls the location search tool with New York, because the system prompt tells it to resolve a place before any chart call.
2. Reads back latitude 40.7143, longitude -74.006, timezone America/New_York.
3. Calls post_astrology_natal_chart with those three plus the date and time.
4. Receives typed JSON: planets with longitude, sign, degree, speed and retrograde state, house cusps, aspects.
5. Writes the reading in your voice, in the language the user wrote in.

Five steps, capped by stopWhen. You paid your model vendor for the thinking, you paid us two quota units for the two calculations, and nobody took a cut of the sentence at the end.

Or skip the SDK and call one provider directly

If you have already committed to a single model vendor and want nothing between you and their API, call the same two servers from their native surface. You give up the one-line provider swap and you gain total control of the request: every parameter, every beta flag, every streaming detail, and no dependency in the path.

# Messages API MCP connector, beta flag mcp-client-2025-11-20
client.beta.messages.create(
    model="claude-opus-5",
    max_tokens=4096,
    betas=["mcp-client-2025-11-20"],
    system=SYSTEM_PROMPT,
    mcp_servers=[
        {"type": "url", "url": "https://roxyapi.com/mcp/astrology",
         "name": "roxy-astrology", "authorization_token": ROXY_API_KEY},
        {"type": "url", "url": "https://roxyapi.com/mcp/location",
         "name": "roxy-location", "authorization_token": ROXY_API_KEY},
    ],
    tools=[
        {"type": "mcp_toolset", "mcp_server_name": "roxy-astrology"},
        {"type": "mcp_toolset", "mcp_server_name": "roxy-location"},
    ],
    messages=[{"role": "user", "content": "Read my chart. 15 July 1990, 14:30, New York."}],
)

# Responses API, mcp tool type
client.responses.create(
    model="gpt-5.6",
    instructions=SYSTEM_PROMPT,
    tools=[
        {"type": "mcp", "server_label": "roxy_astrology",
         "server_url": "https://roxyapi.com/mcp/astrology",
         "authorization": ROXY_API_KEY, "require_approval": "never"},
        {"type": "mcp", "server_label": "roxy_location",
         "server_url": "https://roxyapi.com/mcp/location",
         "authorization": ROXY_API_KEY, "require_approval": "never"},
    ],
    input="Read my chart. 15 July 1990, 14:30, New York.",
)

# Interactions API, mcp_server tool type. Server names are snake_case.
client.interactions.create(
    model="gemini-3.7-flash",
    system_instruction=SYSTEM_PROMPT,
    input="Read my chart. 15 July 1990, 14:30, New York.",
    tools=[
        {"type": "mcp_server", "name": "roxy_astrology",
         "url": "https://roxyapi.com/mcp/astrology",
         "headers": {"Authorization": f"Bearer {ROXY_API_KEY}"}},
        {"type": "mcp_server", "name": "roxy_location",
         "url": "https://roxyapi.com/mcp/location",
         "headers": {"Authorization": f"Bearer {ROXY_API_KEY}"}},
    ],
)

Wiring the integration with a coding agent rather than at runtime? Point GitHub Copilot, Claude Code or Cursor at the keyless docs server at /mcp/docs instead: it returns documentation and field contracts so the agent writes correct code, and never burns quota on a calculation nobody reads. Every client config is in the Remote MCP guide.

Do not let a landing page do your evaluation

A rotating 3D solar system on a homepage proves that somebody bought a WebGL template. It says nothing about whether the ephemeris behind it is correct, whether the advertised endpoints exist, or whether the numbers on the pricing page are real. In 2026 the cheapest thing in software is a convincing surface, and the gap between a generated landing page and shipped code has never been wider.

Every row below is a five-minute check that replaces a claim you cannot verify:

Two tests a sample response cannot pass

One: cast something twice. A divination endpoint that draws has to vary, and a good one also has to repeat on demand. Four unseeded GET /iching/cast calls against production returned hexagrams 8, 26, 45 and 25. The same endpoint with ?seed=roxy-demo returned hexagram 40 three times running. A canned response fails both halves at once: it repeats when it should vary, and it ignores the seed when it should honour it. Reproducible readings are a documented parameter, not an accident, which is the difference between determinism and a fixture.

Two: move the clock by one minute. The Ascendant is the fastest-moving number in a chart, so a real engine has to move it and a sample cannot. Measured live against production, same place, same date:

That is 0.196 degrees, about 706 arcseconds, from sixty seconds of clock. It is also why seconds are load-bearing on any endpoint returning an Ascendant or a house cusp, and why a provider that silently rounds birth time to the minute has decided on your behalf that house cusps do not matter. Run the same two calls against anyone and compare.

None of this is hostile, and we expect it to be pointed at us. It is why the spec is generated from production rather than hand-written, why the playground runs real calls with no signup and no key, why the benchmark is public and MIT licensed, and why every deploy runs 8,000+ automated tests with 1,900+ of them pinned to named external references. Verification is cheap when the thing being verified is real.

Who is in the request path when a vendor runs the model for you?

Someone you did not choose. A hosted chat endpoint takes your users birth date, birth time and birth place, which is personal data under GDPR, and forwards it to a model provider that is a subprocessor of your vendor and therefore a subprocessor of yours. You inherit that chain without selecting a single link in it.

Ask the vendor these, in writing, before you integrate:

• Which model provider processes the request, in which country, named in a dated subprocessor register you can read before you pay
• Whether prompts and completions are retained, for how long, and whether they are used to train anything
• Whether Article 28(2) prior authorization exists for a change of model provider, or whether they can switch silently
• What you are supposed to write in your own privacy policy about a subprocessor you cannot name

RoxyAPI is stateless by design. We hold no conversation, no journal, no profile and no end-user account. A calculation request goes in, structured JSON comes out, nothing about the user persists. The privacy policy states the country and the city rather than a region, and the DPA plus a dated subprocessor register are published free on every plan rather than gated behind a sales thread. When you bring your own model, that vendor sits in your own contract rather than hidden inside a stack you cannot inspect.

Why is memory and personalization your moat rather than theirs?

Because it is the only part of an insight app that compounds. Calculations are deterministic and identical everywhere: the same birth moment yields the same chart from every correct engine on earth. What makes a user open your app on day 90 is that it remembers the transit it flagged on day 12, learned that they skim the career section, and speaks in a voice they now recognize.

Hand that to a vendor and you have outsourced your retention curve: their conversation store, their schema, their export format, their outage. You cannot run an eval harness on a prompt you cannot read, you cannot A and B test a persona you do not control, and you cannot reproduce a support ticket that says the app told me something wrong, because the same input does not return the same output and the model version is not yours to pin.

Build the memory layer yourself on day one. It is a table and an embedding index, it is genuinely yours, and it is the thing a competitor cannot copy. We ship the pattern rather than the storage: the chatbot above is MIT licensed, clones in minutes, and leaves the memory exactly where it belongs, in your code.

Fifteen due-diligence questions for any vendor selling an AI query endpoint

Run these against any provider, including us. They are answerable in an afternoon, and a vendor that cannot answer them has told you something.

Question 15 has a short answer in our case, and it belongs in the open: calculations run on Roxy Ephemeris, our own engine, verified against NASA JPL Horizons and carrying no AGPL anywhere in the request path. The method, the tolerances and the reference set are on /methodology, and the benchmark is a public MIT repo you can re-run rather than a number you have to believe.

Question 13 is the one almost nobody runs, and it is decisive. A spec can list hundreds of paths and declare a response schema for none of them, which reads as breadth in a marketing table and gives an integrating developer nothing: no types, no autocomplete, no generated SDK, no way to know what comes back without paying and probing. Ours declares them, which is why six typed SDKs regenerate from it automatically.

Question 12 is the quiet one. A vendor that returns only interpretation has made a chart wheel, a dasha table and a bodygraph undrawable. Our responses return the positions, the houses, the aspects and the interpretations, all typed, so you can render a wheel with the drop-in UI components at /ui and hand the same JSON to a model.

When a bundled chat endpoint is the right call

There is one, and it deserves saying plainly. If you are building a throwaway demo, a hackathon entry, or an internal tool with under a hundred users and no retention goal, a bundled endpoint is genuinely faster and the markup at that volume is rounding error. Take it. The trade only turns bad when the product is meant to last, because that is when a locked prompt, a fixed model and a memory store you do not own become the ceiling you cannot raise.

FAQ

Does RoxyAPI have an AI chat or natural language query endpoint? No, and it is a deliberate design decision rather than a missing feature. RoxyAPI returns verified structured calculations and lets you run any model over them through Remote MCP or function calling. You keep the system prompt, the guardrails, the model choice and the conversation memory, which are the things that decide whether users come back.

How does an AI astrology chatbot work without an AI astrology API? The model does the talking and an MCP server does the maths. Connect a RoxyAPI Remote MCP server to Claude, GPT or Gemini, pass your own system prompt, and the model resolves the birthplace, calls the chart tool, reads typed JSON back and writes the reading in your voice. Our MIT template does this in one streamText call.

Is Remote MCP different from a local MCP server? Yes, and the difference is operational. A local or stdio MCP server is a process you install, supervise and update on every machine running an agent. RoxyAPI Remote MCP is Streamable HTTP at a public URL, so a hosted agent, a serverless function or a no-code platform calls it directly with an API key and no installation at all.

Can I switch LLM providers without rewriting my astrology integration? Yes. The server, the tools, the field names and the JSON are identical no matter which model calls them, so switching vendors is one environment variable in our template and one tools object on the raw APIs. Prompts, memory schema and rendering code are untouched, which is exactly what a bundled chat endpoint takes away.

How do I tell whether an astrology API is real or just a good landing page? Two calls settle it. Send the same birth data twice with the times one minute apart: a real engine moves the Ascendant about two tenths of a degree, a canned response returns identical numbers. Then cast an I Ching hexagram or draw a tarot card twice with no seed: real ones vary, samples repeat. Also fetch the OpenAPI spec and check it declares response schemas rather than just listing paths.

Does RoxyAPI store my users birth data? No. RoxyAPI is stateless: a request goes in, structured JSON comes out, and no birth data, conversation, profile or journal is retained. Servers, database and cache are in Nuremberg, Germany, the DPA and the dated subprocessor register are published free on every plan, and no model provider sits in the request path that you did not choose yourself.

Conclusion

The endpoint that writes the paragraph for you also decides what your product sounds like, what it remembers, what it costs and who processes your users data. We do not sell it because those are not our decisions to make. Take the verified numbers from the Astrology API, point Remote MCP at whatever model you want, and keep the layer that actually retains users. Every domain, endpoint and MCP server sits in one flat subscription: see pricing.