Privacy workflow · agent-safe defaults
How to protect birth data in astrology agent workflows
A practical boundary map for minimizing sensitive inputs, keeping chart computation local and being precise about the one optional network step.
Direct answer
To protect birth data in an astrology agent workflow, minimize the payload, resolve the birthplace only when needed, compute locally, use privacy_mode=summary for follow-ups, and keep the model's interpretation separate from the raw input.
Astral MCP is stateless: No birth data is persisted and there is no account or reading history. An optional birthplace lookup sends only the place-name string to OpenStreetMap. This is an implementation boundary, not a privacy certification.
Five bounded steps
Minimize first. Explain second.
Privacy is a workflow property as well as a server property. The client decides what enters prompts, logs and traces after a tool returns.
- Minimize the payloadAsk for the date, optional time and birthplace fields needed for this question only. Do not attach names, addresses, contact details or unrelated context to a chart call.
- Resolve only the locationIf you already have latitude, longitude and the historical IANA timezone, skip
astral_search_birthplace. Otherwise send a deliberate place-name string, inspect the result and retain only the selected location fields. - Compute locallyCall
astral_compute_natal_chart,astral_current_transitsorastral_synastryin the local stateless process. The chart tools do not persist birth data or reading history. - Constrain the contextUse
privacy_mode=summarywhen the model needs only the high-signal result. Keep raw birth fields out of unrelated prompts, analytics events and debug logs. - State the boundaryPreserve the tool's precision status and tell the user what was sent over the network. Product behavior is not a privacy certification, legal opinion or security audit.
For the full tool sequence, read How to Generate a Natal Chart with MCP.
Smallest useful request
Keep raw context out of the chart call.
Pass only the fields the computation needs. A summary response reduces what the model must carry forward; it does not replace redaction in the surrounding application.
{
"birth_date": "1989-02-23",
"birth_time": "14:30",
"latitude": -3.7319,
"longitude": -38.5267,
"timezone": "America/Fortaleza",
"verify_precision": true,
"privacy_mode": "summary",
"response_format": "json"
}What Astral actually guarantees
Facts, not vague privacy language.
These are observable product boundaries. They should be carried into the agent's user-facing explanation and reviewed again when the deployment changes.
The local MCP process computes the chart and does not persist birth data, accounts or reading history.
astral_search_birthplace sends only the place-name string to public OpenStreetMap Nominatim. Skip it when you already know the coordinates and timezone.
privacy_mode separates full, structured and summary verbosity. It limits the result sent to the model, not your application's own logs.
Redact names and unrelated personal data, restrict telemetry, and set retention rules around the MCP client, model provider and observability stack.
The Nominatim service has its own usage policy. Do not use the public endpoint for autocomplete, bulk or confidential queries.
Do not overclaim
Implementation boundaries are not certification.
“Stateless” describes Astral MCP's process and storage behavior. It does not certify the MCP client, model provider, proxy, logs, backups or downstream analytics.
Likewise, a verified result means two computational paths agreed within tolerance. It does not validate astrology or make the output scientific, medical, legal or psychological advice.
This guide is not a privacy certification, legal opinion or substitute for a threat model and data-retention review of your complete deployment.
Before production
Run a small privacy review.
- Map the fieldsList every birth-data field, derived field and identifier that enters the client, model, logs or analytics.
- Test egressConfirm that only a deliberate place-name lookup can leave the local process and that its policy/rate limits are respected.
- Check retentionSet retention and access rules for prompts, traces, crash reports and backups outside Astral MCP.
- Publish the disclosureTell users that Astral is stateless, name the optional OpenStreetMap lookup and avoid saying “certified” unless a separate audit supports it.
Astral MCP returns structured astrology data for agent workflows. It is not financial, medical, legal or psychological advice.
Frequently asked
Short answers for builders and users.
Is birth data stored by Astral MCP?
No. Astral MCP is stateless, computes locally and does not persist birth data or reading history. Your MCP client, model provider and observability stack still need their own retention review.
What leaves the local process during a birthplace lookup?
Only the place-name string is sent to OpenStreetMap's public Nominatim service. Skip the lookup when coordinates and the historical IANA timezone are already known.
Does privacy_mode=summary delete the raw input?
No. It limits the returned chart payload. The calling agent remains responsible for redacting prompts, logs, traces and analytics events.
Is this a privacy certification?
No. These are product and workflow boundaries, not a privacy certification, legal opinion or security audit.
Continue learning
Keep the protocol and the privacy story aligned.
Start with What Is an Astrology MCP Server? for the computation/interpretation boundary, then follow the natal-chart workflow with this privacy checklist beside it.