aurora-mcp
Enables sending automated Discord messages and cited anomaly alerts when Aurora's decision contracts trigger, allowing communities to receive quantitative findings in real time.
Enables sending Slack pings and alerts when Aurora detects regime shifts or anomalies, keeping teams informed of verified quantitative results.
Aurora
Glass-box quantitative intelligence. Local. Open. Cited.
Aurora is the verification cortex for serious quantitative work — for humans analyzing hard data, and for AI systems that can't afford to hallucinate.
Cloud LLMs guess. Aurora computes.
⬇️ Download the desktop app · Run from source · Aurora Sentinel demos · See it in action · Aurora Copilot · Aurora Cortex (MCP + SDK) · Roadmap · FantasyLab.ai
⬇️ Download the desktop app
The easiest way to run Aurora — no Python, no terminal, no setup. Download the installer for your OS, double-click, and Aurora opens as a native app with the analysis backend bundled inside it.
→ Download the latest release
Pick the file that matches your OS (filenames carry the version, e.g. 0.2.0):
OS | File to download | Install |
Windows 10/11 |
| Run the setup wizard. |
Windows 10/11 |
| Alternative MSI installer (same app). |
macOS (Apple Silicon · M1/M2/M3/M4) |
| Open the |
Linux (Debian / Ubuntu / Mint) |
|
|
Linux (Fedora / RHEL / openSUSE) |
|
|
Aurora_aarch64.app.tar.gzis an auto-updater artifact, not a download — use the.dmgon macOS. There is currently no Intel-Mac (x86_64) or Linux AppImage build; Intel-Mac users can run from source.
On first launch Aurora bootstraps a small knowledge-bank seed, then runs fully offline — no API keys, no cloud, no telemetry. Drop a CSV on the window and watch it analyze. Aurora is local-first: your data never leaves your machine unless you explicitly share a single finding — see PRIVACY.md.
Heads up on the "Unknown Publisher" warning. Current releases are not yet code-signed, so Windows SmartScreen may show "Windows protected your PC" and macOS Gatekeeper may say "unidentified developer." This is expected for a young open-source project. On Windows: More info → Run anyway. On macOS: right-click the app → Open. Code-signing is on the roadmap.
Desktop app — tips & known quirks
A few things that are expected behavior, not bugs:
First launch shows a welcome screen, not a run. That's intentional — a fresh start is clean. Drop a CSV (or click a demo card) to begin; your past runs are always available under Data → Bundles.
Give the backend a few seconds on first launch. Aurora starts a local analysis server (
127.0.0.1:8001) the first time you open it; the status dot reads "connecting…" for ~5–10 s before it goes live. If it lingers, the app is still warming up — it is not frozen.Big datasets take longer, and results land all at once. A large file can spend a while in "analyzing…". When it finishes you'll see "analysis complete" and the views populate. If the Overview looks momentarily empty right after completion, give it a few seconds or click another tab and back — the assembled state is still being fetched, and it will fill in.
Re-running the same file is instant. Identical data + settings reuse a cached analysis; the banner reads "instant · cached." That's a speed win, not a skipped run.
Knowledge Bank starts small on a fresh install. The bundled app ships with a seed bank that grows over time; the large multi-thousand-entry bank you may see in screenshots is built up on a machine that's been ingesting data for a while. Citations still work against whatever is local.
Want to build it yourself or run from source? Keep reading.
Related MCP server: Prophet MCP Server
⚡ Quickstart (60 seconds)
# 1. Clone + create a virtualenv
git clone https://github.com/FantasyLab-ai/aurora.git
cd aurora
python -m venv .venv
# Windows:
.\.venv\Scripts\Activate.ps1
# macOS / Linux:
source .venv/bin/activate
# 2. Install
pip install -r requirements.txt
# 3. Run the Studio
python studio_api.pyOpen http://127.0.0.1:8000. Click ▶ Try a demo for an instant smoke test, or drop your own CSV / Parquet / JSON / XLSX.
First run will download a small knowledge-bank seed (~50 MB). After that, Aurora runs fully offline — no API keys, no cloud, no telemetry.
Optional extras (only if you need them):
pip install cryptography # Ed25519 bundle signing
pip install mcp # MCP server for LLM agents (Claude Desktop, Cursor, etc.)
pip install -r requirements-dev.txt # contributor / test extrasFor the optional Vite + TypeScript frontend build (developers only), see § Optional frontend build.
🖥️ The desktop app
A native, installable app — frameless window, sidebar navigation, drag-and-drop any file onto it. Built with Tauri 2, with Aurora's full analysis backend bundled inside the installer, so it runs with zero setup: no Python, no venv, no terminal.
Most people should just download it. The rest of this section is for developers who want to build it from source or hack on the UI.
What it does
Surface | Behavior |
Frameless window | Rounded card on transparent OS background; |
Sidebar (left) | Workspace · Data · Full Studio sections + live "aurora: online / offline" status dot |
Tab strip (top) | Overview / Findings / Data with one shared sliding underline |
Drag & drop ANY file | CSV, TSV, JSON, JSONL, Parquet, XLSX — drop anywhere on the window, or click to browse |
Overview | Stat cards (Findings · Methods · Anomalies · Regimes) + Aurora's narrative in plain English |
Findings | Severity-filtered card grid; click a card for the full evidence panel |
Methods | Per-run method tally with share-bars |
Datasets | Bundled fixtures + demo datasets — click any card to run it |
Bundles | Past runs — every signed |
Aurora Studio sidebar | Full legacy UI in an iframe — every feature still reachable |
Build it from source / develop
The desktop app lives in desktop/. To build the installer
yourself (PyInstaller backend + Tauri shell) or run the UI in hot-reload
dev mode, see desktop/README.md — it covers the
prerequisites (Node, Rust), the one-command launcher (launch.ps1), the
installer build (build_installer.ps1), and the Windows Smart App Control
caveat. A git tag vX.Y.Z push triggers the cross-platform release CI.
🚨 Aurora Sentinel — Decision Contracts in the room
Aurora ships a complete demo rig under demos/ that turns a Decision Contract trip into something tangible — a Discord ping, a Slack alert, an OBS overlay card, a smart-plug flipping in your room. Five "I gave my local AI X and watch what it caught" videos, all built on the same scaffolding.
# | Demo | Hero shot | What it shows |
1 | Aurora Alarm | A physical light flips when the data breaks | The closed loop is real — software → cited reason → real-world consequence |
2 | Community Sentinel | A Discord embed lands with method + row + | z |
3 | The Save | A Slack ping arrives at the regime shift | The "human watching dashboards would have slept through this" demo |
4 | Verification Cortex | An agent calls Aurora's MCP and acts on a verified number | Sells the agent-builder use case; no more confidently-wrong z-scores |
5 | Rediscover the Law | Aurora derives | The flagship hook — a free local AI rediscovers gravity, cited to SINDy |
Quickstart for the demos (after the install above):
# Generate the synthetic datasets one time:
python -m demos.datasets.falling_ball.generate
python -m demos.datasets.server_metrics.generate
# Install the demo contracts into Aurora's contracts dir:
cp demos/contracts/*.json ~/.aurora/decision_contracts/ # macOS / Linux
copy demos\contracts\*.json $env:USERPROFILE\.aurora\decision_contracts\ # Windows
# Configure your webhooks once (copy the template + paste your URLs):
cp demos/.env.demos.example demos/.env.demos # macOS / Linux
copy demos\.env.demos.example demos\.env.demos # Windows
# Run the relay (it reads .env.demos for Discord/Slack URLs):
python -m demos.relay.appFull step-by-step recording walkthrough with OBS setup, contract installation, and a per-demo runbook lives at demos/README.md.
See Aurora in action
A real run on an environmental air-quality dataset — captured straight from a Studio session.
The moat: every sentence cites a source
Captured on a 9,357-row cross-sectional air-quality dataset at AUTO tier. Run took ≈14 seconds local on consumer hardware. 0 fabricated. 12 cited knowledge entries. Three methods deferred with reason.
Verifying the install
After python studio_api.py starts, you should see something like:
[aurora] frontend = /path/to/aurora/frontend
* Running on http://127.0.0.1:8000Open the URL. The Studio greets you with a "drop a dataset" zone. Use any of:
data/fixtures/factory_bearing_demo.csv # ships with the repo — bearing failure
data/fixtures/climate_buoy_demo.csv # ships with the repo — NOAA-style buoy data
data/fixtures/patient_cohort_demo.csv # ships with the repo — clinical cohortDrop one, click AUTO + ▶ RUN ANALYSIS. In ~10-20 seconds you'll see:
The six analytical lenses populate (Overview, Anomalies, Regimes, Motifs, Forecast, Physics)
The Findings cards list every cited claim
The
0 fabricatedchip (always — that's Aurora's contract)
If that worked, you're production-ready.
Optional: enhanced frontend build (v0.10 Phase 2)
You do NOT need this to run Aurora. python studio_api.py is the only command required. This section is for developers who want type safety + a Vite hot-reload dev loop for future panel work.
The Phase 2 bundle adds a Vite + TypeScript layer with typed API helpers, hardened Server-Sent Events, and a Nanostores-backed state model. It runs side-by-side with the existing frontend and is fully non-breaking — the visible Studio looks identical with or without it.
Requirements: Node 18+ and npm.
Activation is a one-time build:
cd frontend
npm install # installs Vite, TypeScript, @types/node, Nanostores
npm run build # produces frontend/dist/aurora.js + aurora.css
cd ..That's it. The next time anyone loads the Studio (whether Flask was already running or not), the bundle activates automatically — Flask's static route serves the new files, and index.html HEAD-probes for them on load. Open DevTools console after a page reload and you'll see ⚡ Aurora 0.10.0+phase2 loaded plus window.Aurora.api / .store / .stream available for custom panel work.
To turn it back off: rm -rf frontend/dist/ (or delete the folder). The page reverts to pure-legacy mode with no console warnings.
For active TypeScript development with hot-reload (two terminals):
# Terminal 1 — Flask backend on :8000
python studio_api.py
# Terminal 2 — Vite dev server on :5173 with HMR + Flask proxy
cd frontend && npm run devOpen http://127.0.0.1:5173 (not :8000). Edits to anything under frontend/src/ hot-reload instantly. Full guide: docs/frontend-build.md.
Status: v1.1 shipped (May 2026). v1.2 substantially shipped (streaming, cloud, Jupyter, contracts actions, runs library, MCP HTTP). v2.0 actively shipping on
main(causal do-calculus, multi-dataset joins, Plugin SDK, custom KB ingestion, bundle attestation, KB marketplace, Kafka + Postgres CDC connectors, GPU embeddings). 599 tests passing locally; ~625 in CI. Real users running it on real data.
Run it in Docker (BYO-LLM)
cp .env.example .env # pick a provider + paste your key
docker compose up # → Aurora Studio at http://localhost:8000One command, persistent state on the host (./aurora-data/), no cloud
dependency. See docs/cloud-deploy.md for Fly /
Railway / Render / VPS recipes + the new multi-tenant auth model.
One engine. Two surfaces. Same glass-box.
Aurora has two faces sharing one analytical engine. Same code, same principles, two integration shapes — one for humans clicking through findings, one for AI systems calling APIs.
🧠 Aurora Copilot — for humans
For analysts, quants, scientists, engineers.
A local quantitative copilot for the work that matters too much to trust to a model that hallucinates. Drop in a dataset and get rigorous findings — anomalies surfaced, causal relationships tested, forecasts with confidence bounds, every claim cited to the underlying computation. No cloud LLM guessing. No black-box math.
Glass-box studio — six analytical lenses (Overview, Anomalies, Regimes, Motifs, Forecast, Physics), spacetime system graph, phase-space projection
24+ research-grade methods — Isolation Forest, robust z-score (Hampel), Granger, HMM Baum-Welch, persistent homology, SINDy, Gaussian processes, mutual information, VAR, DTW, BOCPD, Robust PCA, EMD, Kalman, Spectral entropy, and more
Knowledge-grounded synthesis — every "What This Means" sentence cites a
seed:*entry in a public, licensed knowledge bankPreflight data-quality — schema validation, missingness pattern detection, irregular-sampling check before any analysis runs (the
data ok / N issueschip next to the fabricated counter)Causal inference (do-calculus) — Pearl-style backdoor identification + adjustment-OLS estimation. The legacy WHAT-IF panel now ships a "do() causal verdict" beneath every simulator output; the v2.0 LAB has a dedicated full-screen Causal tab for explicit treatment/outcome/intervention queries + counterfactuals
Streaming / continuous mode — point Aurora at a directory; findings refresh as new data lands. Per-finding dedupe so the bus only fires on genuinely new findings; opt-in Decision Contracts auto-fire bridge. Kafka + Postgres CDC connectors for non-file sources (deps gated, listed in the v2.0 LAB → Connectors tab)
Composable findings — a finished run's fitted physics / regime / baseline becomes a prior for the next run; aligned findings get a PRIOR badge
Multi-dataset joins — pair two finished runs to see shared keys, schema compatibility, and inheritance candidates
Runs Library — pin runs across sessions, A/B compare any two runs, share runs as portable
.aurora.jsonbundlesCustom KB ingestion — drop a folder of PDFs / TXT / MD; Aurora walks it, extracts text, folds chunks into your workspace KB. Browse-folder UI in the v2.0 LAB
KB pack marketplace — install curated domain KB packs (Climate / Finance / Biomed / Industrial); preview-state packs labelled honestly
Bundle attestation — three-check rollup (integrity + Ed25519 signature + trusted-signer registry) on any
.aurora.jsonHonest disclosure — sampling, timeouts, and skipped methods are surfaced; never silently faked
→ See it in action: examples/factory-bearing/
→ Conceptual overview: docs/concepts.md
🛡️ Aurora Cortex — for AI systems
For AI builders, agent developers, AI product teams.
The verification layer your AI agents and AI products call when they can't afford to hallucinate quantitative claims. Every LLM today invents numbers; Aurora is the structurally different fix — it computes and verifies rather than predicts. Connect via MCP, the Python SDK, or Decision Contracts.
Four programmable surfaces, all consuming the same .aurora.json bundle format:
import aurora_sdk as aurora
r = aurora.run("data.csv", depth="standard")
r.findings.critical().by_method("iso-forest")
r.forecast.peak(horizon_hours=24)
r.bundle.save("audit.aurora.json") # SHA-256 integrity + optional Ed25519 signing
# Verify on any machine with Aurora installed
b = aurora.Bundle.load("audit.aurora.json")
b.verify() # raises if tamperedLayer | Audience | What it does |
Aurora SDK (docs) | Python devs, notebooks, pipelines |
|
Aurora Jupyter (docs) | Notebook users |
|
Aurora MCP (docs) | LLM agents (Claude Desktop, Claude Code, Cursor, custom) |
|
Decision Contracts (docs) | Automation pipelines | Programmable predicates → webhook / log / file / Slack / Discord / email when findings match. SSRF + recipient-cap guards. Streaming bridge fires contracts on live findings |
Aurora Streaming (docs) | Live data feeds | File-watcher + rolling window + SSE event bus; per-finding dedupe; optional contracts auto-fire. Kafka + Postgres CDC connectors (deps gated) |
Aurora Causal (docs) | Analysts asking "what if X?" | Pearl do-calculus: backdoor identification + adjustment OLS + counterfactual queries on the run's system_model DAG |
Runs Library (docs) | Anyone iterating on a dataset | Pin runs across sessions, A/B compare two runs, export portable |
Plugin SDK (docs) | Domain specialists | Register third-party methods via the |
Custom KB ingestion | Researchers with private libraries | Drop a folder of PDFs / TXT / MD into your workspace KB |
Bundle Attestation | Anyone consuming a shared | Verify integrity + Ed25519 signature + trusted-signer registry in one call |
Aurora Cloud (docs) | Self-hosted deployments | Docker image, BYO-LLM, multi-tenant auth, per-workspace data isolation, usage logging |
Research Kit (docs) | Researchers, academics |
|
→ Wire Aurora into Claude Desktop in 5 minutes: examples/mcp-claude-desktop/
→ Build a "fire when 3+ critical anomalies appear" automation: examples/decision-contracts/
Why Aurora exists
Every AI today — including the best cloud LLMs — hallucinates on quantitative claims. Bigger models don't fix it. RAG alone doesn't fix it. Chain-of-thought just produces longer confident lies.
Aurora is the rarest kind of fix — structurally different. It computes and verifies rather than predicts. It runs locally on your machine. It shows its math. Every relationship Aurora reports is computed, not guessed. Every claim cites its source. Every uncertain finding is rendered as uncertain — never confident-looking math over shaky ground.
Core principles
🔍 Glass-box at every layer. Every node, edge, finding, and recommendation traces to its source. Bundles carry a SHA-256 content hash and can be Ed25519-signed.
💻 Local-first, always. Your data stays on your machine. No telemetry. No phone-home. The MCP server enforces a per-call path allowlist; Decision Contracts block private-IP webhook targets by default.
🎯 Honesty rule. Uncertain relationships render as uncertain. When methods sample or time out, the user is told. Aurora's
fabricated_countchip is a contractual0— and it's audited live.📖 Open source. Apache 2.0. Inspectable. Forkable. Yours to audit, vendor, embed, redistribute.
Calibrated, not just cited
A referee that can't quantify its own error rate isn't a referee. As of v0.10.0, Aurora ships a calibration engine: for the changepoint family (BOCPD, CUSUM, PELT), every finding carries the empirically measured rate at which that detector fires on data containing nothing to find — data shaped like yours.
The measured headline, from Aurora's own production CUSUM detector (n=90, 4,000 seeded null trials per cell): it fires on 0.1% of independent stationary series, 48.3% at lag-1 autocorrelation φ=0.6, and 89.5% at φ=0.8. Autocorrelation that ordinary for daily demand or sensor data turns a "detection" into a coin flip — and without calibration, nothing downstream can tell. It compounds with length, too: at φ=0.4 the rate climbs from 13.6% (n=90) to 39.6% (n=180) — collecting more data makes this failure mode worse, not better. Meanwhile the same corpus shows what does not fool the detectors: a strong 7-day seasonal cycle (0 fires in 4,000 trials) and heavy-tailed noise (0.4%) barely register. Autocorrelation is the killer, and now it's measured.
So Aurora tells you, at the moment the finding is produced:
the measured false-fire rate with a Wilson 95% interval, matched to your data's fingerprint (length, bias-corrected autocorrelation, tails, seasonality, missingness)
an honest status —
calibrated,interpolated(with disclosed max error),unavailable(outside the measured envelope, offending dimension named), ornot_yet_calibrated— never a silent defaulta verdict downgrade: findings the data cannot support flip to
not_identifiable, with the raw statistic still reported and the configured ceiling disclosedderived remediation — required consecutive confirmations, pre-whitening with the estimated φ — only where the math supports it
the corpus version + SHA-256 in the finding and the bundle, so a skeptic can verify which table produced the claim
Watch it catch a constraint-legal action taken for a phantom reason:
python -m demos.phantom_signal.run_demoDetails, schema, and the full honesty ruleset: docs/CALIBRATION.md. What it does not claim: no power/sensitivity numbers, no real-data ground truth, and corpus v1 covers the changepoint family — the other methods say not_yet_calibrated out loud instead of pretending.
How it connects
Aurora is built to be infrastructure both humans and AI systems can call:
MCP Server — connect any MCP-compatible AI client (Claude Desktop, Claude Code, Cursor, custom agents). 7 tools advertised; path-allowlisted; 2 MB output cap; JSON-only error wrapping
Python SDK —
import aurora_sdkin notebooks, scripts, pipelines, agent frameworksDecision Contracts — programmable predicates fire actions (webhook / log / append-only file). SSRF-guarded, rate-limited, audited
Webhooks — deliver verified findings to Slack / Discord / PagerDuty / your own intake API (Slack/Discord/PagerDuty action types coming in v1.2; generic webhook ships now)
Local Studio — full glass-box exploration of findings, intelligence panels, system graph, cube navigator
Aurora Bundle Format v1 — a portable, signable, citeable
.aurora.jsonartifact that every layer above produces and consumes
Quick examples
As a Copilot — drop a CSV, read what Aurora found
python studio_api.py
# Open http://127.0.0.1:8000 → click "Try a demo → factory_bearing_demo"
# 10 seconds later: 11 cited findings, 3 critical, confidence 84%, 0 fabricated.As a Cortex — give Claude Desktop the ability to cite real math
Add to your claude_desktop_config.json:
{
"mcpServers": {
"aurora": {
"command": "uvx",
"args": ["aurora-mcp", "--allow-root", "/Users/you/data"]
}
}
}No install step — uvx fetches aurora-mcp from PyPI on first run. (Running from a source checkout instead? Use "command": "/path/to/aurora/.venv/bin/python", "args": ["-m", "aurora_mcp.server", "--allow-root", "/Users/you/data"].)
Then ask Claude:
Run Aurora on
/Users/you/data/factory_bearing.csvat standard depth, then drill into the most critical anomaly with full evidence.
Claude chains aurora_analyze → aurora_findings(severity=crit) → aurora_explain(claim_id=…) and writes you back a response citing every method — never inventing a row number or a z-score.
Full walkthrough: examples/mcp-claude-desktop/
As a Cortex — wire findings into automation
~/.aurora/decision_contracts/bearing-watch.json:
{
"id": "bearing-watch",
"trigger": {"field": "findings.crit_count", "op": ">=", "value": 3},
"actions": [
{"type": "webhook", "url": "https://hooks.example.com/aurora"},
{"type": "file", "path": "alerts.jsonl"}
],
"rate_limit": {"max_per_hour": 12}
}from aurora_sdk import Bundle
from fantasyai.aurora.decision_contracts import load_contracts, fire_contract
bundle = Bundle.load("latest.aurora.json").doc
for c in load_contracts():
fire_contract(c, bundle) # webhook fires, audit row appendedWhat's working today
The v1.1 substrate — Bundle Format, SDK, MCP, Decision Contracts, Research Kit, six analytical lenses — is shipped and stable. The v1.2 sprint is substantially complete; v2.0 work is landing continuously on main.
Analytical methods (17 → 24+):
v1.1: Isolation Forest, Hampel z-score, HMM, mutual information, Granger, wavelet, Lomb-Scargle, Gaussian process, persistent topology, SINDy, multivariate outliers, cluster stability, Bayesian, panel, survival, spatial, network, DiD
v1.2 added: VAR, DTW, BOCPD, Robust PCA, EMD, Kalman, Spectral entropy — each with skip reasons + glass-box compliance
v1.2 surfaces (mostly shipped):
Streaming / continuous mode —
/api/stream/start|stop|status|eventswith SSE event bus, per-finding dedupe, opt-in Decision Contracts bridge, Live Findings strip in the StudioAurora Cloud (Phase 1 + 2) — Docker + docker-compose + cloud-deploy guide. Multi-tenant auth + per-workspace data isolation + usage logging behind
AURORA_AUTH_REQUIRED=1BYO-LLM — pluggable provider abstraction with 5 backends (Anthropic / OpenAI / Gemini / Ollama / OpenAI-compatible)
Decision Contracts: Slack / Discord / Email actions — extend the v1.1 webhook / log / file types. SSRF + recipient caps + URL token redaction
Runs Library UI — pin / A/B compare (via the joins endpoint) / share-as-bundle, all from a top-toolbar chip
MCP HTTP transport —
/mcp/v1/*endpoints for remote agents that can't subprocess locally; standalone server mode with optional token gatePreflight data-quality — schema + missingness + irregular-sampling checks.
data ok / N issuespill alongside the fabricated chipJupyter integration —
aurora.run(df)with rich HTML reprs,to_html_report(), sample notebookKB pack distribution — manifest + downloader + 4 starter packs + registry auto-detection
v2.0 surfaces (shipping, exposed in the ⚡ v2.0 LAB modal):
Causal inference (do-calculus) —
fantasyai/aurora/causal/. Backdoor identification + adjustment-OLS estimation + counterfactual queries. The legacy WHAT-IF panel now also returns a "do() causal verdict" beneath every simulator outputMulti-dataset joins —
/api/joins/analyzeproduces shared keys + schema compatibility + cross-correlation hints + inheritance candidates between two finished runsComposable findings — extract priors from a finished run, inherit them into the next; aligned findings get a
PRIOR · matches / drifts / novelbadgePlugin SDK — third-party methods register via
aurora_pluginsentry-point group; same contract as built-ins; failures are isolatedCustom KB ingestion — drop a folder of PDFs / TXT / MD; Aurora walks it and folds chunks into the workspace KB. Folder picker + drag-and-drop in the v2.0 LAB
Bundle attestation — three-check rollup (integrity + Ed25519 signature + trusted-signer registry) on any
.aurora.jsonKB pack marketplace — install curated domain KB packs (Climate / Finance / Biomed / Industrial). Preview-state packs honestly labelled "not yet released"
Streaming connectors — Kafka + Postgres CDC connectors for non-file sources. Deps are gated; the v2.0 LAB → Connectors tab lists install hints
GPU embeddings —
AURORA_EMBEDDINGS_DEVICE=cuda|mps|autoenv-var device selection with graceful CPU fallback
Counts:
599 tests passing locally; ~625 in CI (scipy + flask-dependent tests run there)
16 backend modules import cleanly
0 fabricated findings — contractual
Local execution end-to-end. No cloud dependency after initial knowledge bank download.
What's rough
Named honestly:
The knowledge bank ships with a seed set; the full pack is downloaded separately and is still expanding
The 4 v2.0 marketplace packs (Climate / Finance / Biomed / Industrial) are reserved in the manifest but not yet hosted — SHAs are
PENDING_FIRST_BUILD. The Studio labels themPREVIEWand disables install until the next manifest revisionSome advanced methods skip on datasets that lack required structure (no time axis, no entity column) — these skips are correct glass-box behavior; can be confusing without reading the skip reason
Per-method timeouts (90 s default) defer some methods on very large datasets; disclosed honestly
Mobile / tablet responsiveness still pending
Browser security prevents Aurora from reading absolute folder paths from a
<input type="file">picker; KB ingest seeds the folder name + asks the user to type the absolute path
Build-in-public log: CHANGELOG.md.
Built in the open. By a real person. For real work.
Aurora is fully open source under Apache 2.0. The engine, the schema, the baseline templates, the MCP server, the SDK, the webhook layer — all of it. No black box at any layer, including the codebase itself.
The roadmap is public. The build is documented on YouTube. Domain experts who contribute knowledge bank entries or templates will be able to earn from the upcoming marketplace (v2.0). Aurora gets smarter as the community grows.
⭐ Star on GitHub — visibility
💜 Back on Patreon — recurring support funds the build
Roadmap
See ROADMAP.md for the full picture. Recent progress:
v1.2 — substantially shipped: Streaming Phase 1+2 · Aurora Cloud Phase 1+2 (Docker + BYO-LLM + multi-tenant auth) · 7 new analytical methods · Jupyter integration · KB pack distribution · Preflight data-quality · Slack/Discord/Email contract actions · Runs Library UI · MCP HTTP transport
v2.0 — actively shipping on
main: Causal inference (do-calculus) · Multi-dataset joins · Composable findings · Plugin SDK · Custom KB ingestion (PDFs → KB) · Bundle attestation service · KB pack marketplace (preview) · Kafka + Postgres CDC streaming connectors · GPU embedding device gatev1.2 tail (still open): Bundle Format v1.1 (signed delta updates) · conversational copilot polish · KB community contribution flow · domain template packs · DuckDB ingest · mobile/tablet responsiveness pass
v2.0+ (6–12 months): Federated knowledge contribution · marketplace with creator revenue share · Aurora kernels · Aurora-as-CI · Web Component embeds · mobile companion
Project Family
Aurora is part of FantasyLab.ai — local-first AI tools for serious work. Sister project:
Fantasy Studio — AI-directed cinematic 3D rendering using real path-traced light simulation. Same philosophy applied to creative work instead of analytical work.
Contributing
We welcome contributions. See CONTRIBUTING.md for setup, code style, testing requirements, and the development workflow.
Good places to start:
Issues labeled
good first issueIssues labeled
help wantedKnowledge bank contributions — adding cited entries for new domains. See docs/knowledge-bank.md
Aurora MCP integrations — example notebooks, demo agents
Security
Aurora processes data locally. The SDK and MCP server have no telemetry, no phone-home, no analytics. The verification cortex is the moat — and it's audited. See SECURITY.md for the full security model and how to report a vulnerability.
License
Aurora is licensed under Apache License 2.0. Use it commercially, modify it, redistribute it. Just keep the copyright notice and don't claim we endorse your derivative.
For deployment in customer-managed cloud environments with enterprise support, contact enterprise@fantasylab.ai.
Acknowledgments
Aurora stands on the shoulders of decades of statistical and analytical research. Citations are baked into every Aurora output. Foundational methods come from researchers including:
Vipin Chandola, Arindam Banerjee, Vipin Kumar (anomaly detection)
Judea Pearl (causal inference)
Rob Hyndman, George Athanasopoulos (forecasting)
Steven Brunton, Joshua Proctor, Nathan Kutz (SINDy / sparse identification)
Frank Hampel (robust statistics, 1974)
Fei Tony Liu, Kai Ming Ting, Zhi-Hua Zhou (Isolation Forest)
Carl Edward Rasmussen, Christopher K. I. Williams (Gaussian processes)
C. W. J. Granger (causality)
L. E. Baum, T. Petrie, G. Soules, N. Weiss (Baum–Welch HMM)
Thomas Malthus (exponential dynamics, 1798)
Reverend Thomas Bayes (Bayesian inference)
…and the broader open scientific community whose work makes Aurora possible
The Aurora project itself is built as part of FantasyLab.ai.
Aurora is part of FantasyLab.ai · Glass-box, local-first, source-available AI tools for serious work
Available Tools
7 toolsaurora_analyzeA
Statistical analysis of a dataset (CSV, TSV, Parquet, XLSX): runs Aurora's battery of 19 research-grade methods on-device — anomaly detection (isolation forest + robust-z), change-point detection, trend and seasonality, correlation screening with FDR control, forecasting, causal system-model discovery, and more. Returns CITED findings (each carries its method, threshold, and claim_id), an overall confidence, and a fabricated_count that is contractually zero: every number is computed from the data, never generated. Changepoint findings carry a calibration block: the empirically measured false-fire rate for data shaped like this series, with a verdict downgrade to not_identifiable when the data cannot support the claim. Use this FIRST whenever a user asks to analyze data, find anomalies, check what changed, or wants real statistics instead of estimates. Read-only; local; compact summary unless full_bundle=true.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | CSV path, existing run_dir, or .aurora.json | |
| depth | No | ||
| sections | No | ||
| full_bundle | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so richly: read-only, local, on-device execution, cited findings with claim_id, contractually zero fabricated_count, changepoint calibration blocks, and verdict downgrade behavior. It does not discuss error conditions or limits, but it goes far beyond a minimal description. No contradiction with annotations because none exist.
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 dense but well-structured: purpose and formats lead, followed by methods, return characteristics, and finally usage guidance. Each sentence carries substantive information; the only mild redundancy is the closing list ('analyze data, find anomalies, check what changed'), which is acceptable as a routing hint. It is longer than typical, but length is justified by the richness of the tool's behavior.
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, this description covers input types, return payload (cited findings, confidence, fabricated_count), behavioral guarantees (calibration, downgrade), and usage routing. The only notable omission is parameter semantics for depth and sections. For a statistically complex tool, this is strong coverage — an agent can invoke it correctly without opening the schema.
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 25%, meaning depth, sections, and full_bundle are undocumented in the schema. The description clarifies full_bundle ('compact summary unless full_bundle=true') and partially clarifies path ('CSV path, existing run_dir, or .aurora.json'), but it does not explain the semantic meaning of depth (auto/quick/standard/full) or sections. The description compensates somewhat but not enough to fully bridge the parameter meaning gap.
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 a specific verb ('Statistical analysis'), a clear resource ('dataset CSV, TSV, Parquet, XLSX'), and enumerates concrete capabilities (anomaly detection, changepoint detection, forecasting, causal discovery). It strongly distinguishes this tool from siblings by positioning it as the primary analysis entry point, name-dropping methods that no other sibling claims.
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 provides explicit when-to-use guidance: 'Use this FIRST whenever a user asks to analyze data, find anomalies, check what changed, or wants real statistics instead of estimates.' This directly tells the agent when to invoke this tool and implicitly routes around alternatives like aurora_forecast or aurora_simulate. This is exactly the kind of usage context an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
aurora_explainA
Full evidence for ONE finding by claim_id: the computed values behind the claim plus the method's registry spec — assumptions, parameters, and references. Use whenever you are about to cite, verify, or defend a specific statistical claim; this is the receipt, not a summary.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| claim_id | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does a good job: it reveals the tool returns full evidence, computed values, assumptions, parameters, and references, and clarifies it is not a summarized response. It does not explicitly state that the operation is read-only, but the 'evidence/receipt' framing makes an informational read behavior clear.
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 compact and front-loaded: the core action and target ('Full evidence for ONE finding by claim_id') appear first, followed by contents and a crisp usage rule. Every sentence earns its place with no redundancy.
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?
The return content is described well enough at a high level, and the tool is not complex, but the absence of any explanation for the required path parameter is a real gap. Since there is no output schema and no annotations, the description should have clarified both inputs to be fully 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 coverage is 0%, so the description must compensate for the bare parameter names, but it only clarifies claim_id ('ONE finding by claim_id'). The required path parameter is never explained, leaving the agent to guess whether it is a bundle path, workspace path, or something else.
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 uses a specific verb ('explain') with a precise resource ('ONE finding by claim_id') and clearly states what is delivered: computed values plus the method's registry spec. The phrase 'this is the receipt, not a summary' explicitly distinguishes it from a higher-level findings tool, so an agent can separate it from siblings like aurora_findings.
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 gives an explicit condition for use: 'Use whenever you are about to cite, verify, or defend a specific statistical claim.' This is clear context but it does not name alternative tools or state when not to use it beyond the implicit contrast with a summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
aurora_findingsA
List the verified findings from an Aurora run or bundle: each one carries severity (crit/warn/info), the exact statistical method and threshold that produced it, a plain-language citation, and a claim_id for evidence drill-down via aurora_explain. Filter by severity or method. Use after aurora_analyze to enumerate what was actually found — quote findings from here instead of paraphrasing from memory.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| limit | No | ||
| method | No | ||
| severity | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full transparency burden. It clearly discloses what the returned findings contain and that they are 'verified,' so the agent knows this is an enumeration/read operation rather than a mutation. It does not mention ordering, default limit, or empty-result behavior, but the core behavior is well described.
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 compact yet information-dense: two sentences covering purpose, output shape, filtering, sequencing, and usage guidance. It front-loads the core action and does not waste words.
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 listing tool with no output schema, the description provides strong context: what to do first, what results contain, how to filter, and how to follow up via aurora_explain. It lacks explicit mention of limit behavior and result ordering, but otherwise the agent has enough to invoke the tool 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?
The input schema has 0% description coverage, so the description must compensate. It defines path as 'an Aurora run or bundle,' method as 'statistical method,' and severity with its allowed values ('crit/warn/info'). It does not explain the limit parameter, but the name and schema constraints make it reasonably inferable.
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 starts with the specific verb 'List' and identifies the exact resource: 'verified findings from an Aurora run or bundle.' It enumerates the key output attributes (severity, method, threshold, citation, claim_id), which makes the tool's purpose unmistakable and distinguishes it from siblings like aurora_explain and aurora_analyze.
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 tells the agent when to use this tool: 'Use after aurora_analyze to enumerate what was actually found.' It also gives a concrete behavioral directive—'quote findings from here instead of paraphrasing from memory'—and points to aurora_explain for evidence drill-down, effectively routing between alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
aurora_forecastA
Model-based forecast for the run's target column, fitted and validated on the actual data with the method disclosed. Returns point predictions with an honest horizon, or just the peak within horizon_hours (return_peak=true). Use for any 'what will X be / when does it peak' question instead of extrapolating by eye.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| return_peak | No | ||
| horizon_hours | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses that the forecast is model-based, fitted and validated on actual data, that the method is disclosed, and that output is either point predictions with an honest horizon or a peak within horizon_hours. Side effects, failure modes, and result structure are not covered, but the core behavior is transparent.
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 filler. The core behavior is front-loaded and the usage hint wraps up efficiently; every clause contributes 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?
The description is sufficient for choosing the tool but not fully complete for invoking it: path's meaning is unresolved and the relationship between return_peak and horizon_hours (e.g., whether horizon_hours is required for peak mode) is underspecified. With no output schema or annotations, a bit more detail on expected inputs and return shape would make it 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 0%, so the description must compensate. It adds meaning for return_peak ('just the peak within horizon_hours') and implies horizon_hours controls the forecast window, but the required path parameter is left unexplained. This is a meaningful gap since the agent cannot tell what path refers to.
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?
States a concrete resource and operation: model-based forecast for the run's target column, returning point predictions or a peak. It clearly conveys what the tool does and is distinguishable by function, though it does not name or differentiate against sibling tools like aurora_explain or aurora_simulate.
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 user intent: 'what will X be / when does it peak' questions, with a directive 'Use for... instead of extrapolating by eye.' This is clear context for when to invoke, but there are no when-not conditions or named alternative tools, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
aurora_interveneA
What-if intervention: perturb one variable in the data's discovered system model and propagate the shock through validated relationships (up to max_depth hops). Returns per-node deltas WITH confidence intervals. Use for 'what happens to Y if X changes by Δ' questions — answers come from the data's own causal graph, not from priors.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| max_depth | No | ||
| perturbation | Yes | ||
| source_entity_id | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description itself carries the behavioral burden and does so reasonably: it discloses the mechanism (one-variable perturbation, propagation up to max_depth hops) and the return shape (per-node deltas with confidence intervals). It does not explicitly state that data is unmodified or describe prerequisites, but the 'what-if' framing and computed-deltas wording largely convey the read-only analytical intent.
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 two dense sentences with the operation front-loaded and the use case in the second sentence. Every clause adds information: mechanism, output type, usage context, and evidential basis, with no filler.
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 sparse schema with no annotations and no output schema, the description covers purpose, usage, and output type well. But it omits the meaning of the required path parameter, the role of source_entity_id, and any prerequisite like having a discovered/loaded model available, so an agent may still be uncertain about how to assemble a valid call.
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?
At 0% schema description coverage, the description must compensate. It usefully explains max_depth as 'hops' and perturbation as 'Δ', and 'perturb one variable' loosely maps to source_entity_id. However, the required path parameter is never semantically clarified, so the required parameter set is only partially documented.
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?
Clearly identifies a specific operation: what-if causal intervention on a discovered model, perturbing one variable and propagating through validated relationships. It is distinct from forecast/simulate by emphasizing 'data's own causal graph' and 'not from priors', but it does not explicitly name or contrast a sibling, so it stops short of a 5.
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?
Explicitly gives a use-case template ('what happens to Y if X changes by Δ'), which tells an agent when to select this tool. However, it offers no exclusions or named alternatives among the sibling group, leaving routing to aurora_simulate or aurora_forecast partly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
aurora_load_bundleA
Load a portable .aurora.json analysis bundle and verify its SHA-256 integrity hash (and Ed25519 signature when present) BEFORE trusting its findings. Use when someone shares an Aurora bundle and you need proof it is untampered. Returns run identity, confidence, fabricated_count, and findings-by-severity counts.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| verify | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses verification behavior (SHA-256 and Ed25519) and the summary return values. However, it does not state what happens when verification fails, whether the operation is read-only, or any side effects, which are important for a file-loading tool.
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 with no filler. It front-loads the core action and verification requirement, then gives usage context, then return values. Every sentence contributes 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?
The tool has moderate complexity with 2 parameters, no output schema, and no annotations. The description covers the main purpose and return values, but omits failure handling and the behavior of the 'verify' parameter. An agent calling this tool would still need to infer the effect of verify=false, which is a notable completeness gap.
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%, so the description must compensate. It implies 'path' points to the bundle file, but it does not explain the 'verify' boolean parameter's meaning or that it defaults to true and could potentially be set false. This is a significant gap because the description emphasizes verification without mapping to the 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 uses a specific verb 'Load' and resource '.aurora.json analysis bundle', and clearly states its purpose: verify integrity before trusting findings. It also lists the return values (run identity, confidence, fabricated_count, findings-by-severity counts), which distinguishes it from the sibling analysis tools.
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?
It explicitly provides a use case: 'Use when someone shares an Aurora bundle and you need proof it is untampered.' This gives clear context for when to call the tool. It does not mention alternatives or exclusion scenarios, but the 'BEFORE trusting its findings' hint implies it should precede analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
aurora_simulateA
Simulate the system forward n_steps using dynamics fitted and validated on the data — and it PAUSES honestly when confidence intervals grow too wide to keep going, rather than extrapolating noise. Use for trajectory questions ('where is this heading') on a completed run; pass target_entity_id to simulate a specific node.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| n_steps | No | ||
| target_entity_id | No | ||
| ci_pause_threshold | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden, and it does disclose an important non-obvious behavior: it pauses rather than extrapolating when confidence intervals grow too wide, and it uses dynamics fitted and validated on the data. It does not clarify what a pause looks like in the output or whether the operation mutates anything, but the key behavioral guarantee is present.
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 two sentences with no filler. The core mechanism and purpose are front-loaded, and the pause behavior is integrated naturally rather than tacked on.
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 there is no output schema and no annotations, the description should be more self-sufficient. It leaves the required path parameter undefined, does not explain ci_pause_threshold, and does not describe what is returned when the tool pauses. It is enough to select the tool but not enough to confidently invoke it without additional assumptions.
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%, so the description must explain parameters. It gives meaning to n_steps and target_entity_id, but the required path parameter is never explained, and ci_pause_threshold is only indirectly inferable from the pause behavior rather than explicitly defined.
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 a specific operation—simulate the system forward n_steps—and scopes it to 'trajectory questions' on a completed run, optionally for a specific node. It is clear enough to distinguish from analyze/explain, but it does not explicitly contrast itself with aurora_forecast, so it stops short of full sibling differentiation.
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?
It gives a clear when-to-use context: trajectory questions on a completed run, with the optional target_entity_id instruction. It does not name alternative sibling tools or provide exclusion criteria, so it lacks the explicit when-not/alternative guidance needed for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
7 tool updates
v0.1.0- First observed
aurora_analyze - First observed
aurora_explain - First observed
aurora_findings - First observed
aurora_forecast - First observed
aurora_intervene - First observed
aurora_load_bundle - First observed
aurora_simulate
TDQS
Most tools have clearly distinct roles: analyze runs the initial analysis, findings lists the results, explain provides evidence for a single claim, and load_bundle verifies shared bundles. The main ambiguity is between forecast and simulate, both forward-looking, and between analyze and findings, which both return findings; however, the descriptions give enough guidance to separate them.
All tools share the aurora_ prefix and use lowercase snake_case, which makes them immediately recognizable. Most names are verb-led (analyze, explain, forecast, intervene, simulate), with aurora_findings being the one noun-style outlier, but the convention is still predictable.
Seven tools is a well-scoped count for a statistical analysis server. Each tool addresses a distinct part of the workflow: analysis, result enumeration, evidence drill-down, bundle loading, forecasting, intervention, and simulation.
The core analysis lifecycle is well covered: analyze, list findings, explain evidence, and load external bundles, plus forward-looking tools for forecasting, intervention, and simulation. Minor gaps exist, such as no explicit run comparison or bundle export tool, but agents can work around these without major failures.
Maintenance
Related MCP Connectors
The statistical analyst in your AI chat — validated, citable, re-runnable analysis of your data.
Precision math engine for AI agents. 203 exact methods. Zero hallucination.
Valid and reliable data engineering and statistical analysis without hallucinations.
Reproducible benchmarks and reliability evidence for agent tools.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceA local, agentic AI pipeline that analyzes tabular data, detects anomalies, and generates interpretive summaries using local LLMs orchestrated via the Model Context Protocol.-
- AlicenseNot gradedqualityDmaintenanceAn MCP server powered by Meta's Prophet that enables LLMs to perform time-series forecasting, trend analysis, and predictive modeling on historical data. It provides LLM-friendly statistical summaries, automated business-rule validation, and ready-to-render Chart.js visualizations.MIT
- AlicenseAqualityBmaintenanceDeterministic time-series statistics for AI agents. This MCP server gives any LLM agent unit-tested statistical tools — anomaly detection, changepoint detection, seasonal decomposition, stationarity/trend tests, data-quality audits, baseline forecasts — with schema-validated structured output and no arbitrary code execution.17MIT
- FlicenseNot gradedqualityCmaintenanceComputes AI agent reliability metrics like success rates, latency statistics, and failure patterns from provided numbers, with zero external API cost.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/FantasyLab-ai/aurora'
If you have feedback or need assistance with the MCP directory API, please join our Discord server