Skip to main content
Glama

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.

License Python Status Tests Patreon

⬇️ 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

Aurora_x.x.x_x64-setup.exe (recommended)

Run the setup wizard.

Windows 10/11

Aurora_x.x.x_x64_en-US.msi

Alternative MSI installer (same app).

macOS (Apple Silicon · M1/M2/M3/M4)

Aurora_x.x.x_aarch64.dmg

Open the .dmg, drag Aurora to Applications.

Linux (Debian / Ubuntu / Mint)

Aurora_x.x.x_amd64.deb

sudo apt install ./Aurora_x.x.x_amd64.deb

Linux (Fedora / RHEL / openSUSE)

Aurora-x.x.x-1.x86_64.rpm

sudo dnf install ./Aurora-x.x.x-1.x86_64.rpm

Aurora_aarch64.app.tar.gz is an auto-updater artifact, not a download — use the .dmg on 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.py

Open 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 extras

For 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; aurora ◆ titlebar with min/max/close

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.json on disk, status-coded

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 y = ½·a·t² from a falling-ball video

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.app

Full 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:8000

Open 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 cohort

Drop 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 fabricated chip (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 dev

Open 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:8000

One 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 bank

  • Preflight data-quality — schema validation, missingness pattern detection, irregular-sampling check before any analysis runs (the data ok / N issues chip 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.json bundles

  • Custom 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.json

  • Honest 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 tampered

Layer

Audience

What it does

Aurora SDK (docs)

Python devs, notebooks, pipelines

pip install away from cited, glass-box quantitative reasoning

Aurora Jupyter (docs)

Notebook users

aurora.run(df) with rich HTML reprs, to_html_report() exports

Aurora MCP (docs)

LLM agents (Claude Desktop, Claude Code, Cursor, custom)

uvx aurora-mcp — 7 tools via stdio or HTTP transport; path-allowlisted, output-capped, JSON-only

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 .aurora.json

Plugin SDK (docs)

Domain specialists

Register third-party methods via the aurora_plugins entry-point group; same finding contract as built-ins

Custom KB ingestion

Researchers with private libraries

Drop a folder of PDFs / TXT / MD into your workspace KB

Bundle Attestation

Anyone consuming a shared .aurora.json

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

methods.md + references.bib + replication.json + .zenodo.json for DOI minting

→ 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_count chip is a contractual 0 — 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), or not_yet_calibrated — never a silent default

  • a verdict downgrade: findings the data cannot support flip to not_identifiable, with the raw statistic still reported and the configured ceiling disclosed

  • derived 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_demo

Details, 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 SDKimport aurora_sdk in notebooks, scripts, pipelines, agent frameworks

  • Decision 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.json artifact 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.csv at 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 appended

What'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|events with SSE event bus, per-finding dedupe, opt-in Decision Contracts bridge, Live Findings strip in the Studio

  • Aurora Cloud (Phase 1 + 2) — Docker + docker-compose + cloud-deploy guide. Multi-tenant auth + per-workspace data isolation + usage logging behind AURORA_AUTH_REQUIRED=1

  • BYO-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 gate

  • Preflight data-quality — schema + missingness + irregular-sampling checks. data ok / N issues pill alongside the fabricated chip

  • Jupyter integrationaurora.run(df) with rich HTML reprs, to_html_report(), sample notebook

  • KB 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 output

  • Multi-dataset joins/api/joins/analyze produces shared keys + schema compatibility + cross-correlation hints + inheritance candidates between two finished runs

  • Composable findings — extract priors from a finished run, inherit them into the next; aligned findings get a PRIOR · matches / drifts / novel badge

  • Plugin SDK — third-party methods register via aurora_plugins entry-point group; same contract as built-ins; failures are isolated

  • Custom 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.json

  • KB 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 embeddingsAURORA_EMBEDDINGS_DEVICE=cuda|mps|auto env-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 them PREVIEW and disables install until the next manifest revision

  • Some 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.


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 gate

  • v1.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:

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 tools
aurora_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.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesCSV path, existing run_dir, or .aurora.json
depthNo
sectionsNo
full_bundleNo

TDQS

A4.3/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes
claim_idYes

TDQS

A4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters2/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes
limitNo
methodNo
severityNo

TDQS

A4.6/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes
return_peakNo
horizon_hoursNo

TDQS

A3.9/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes
max_depthNo
perturbationYes
source_entity_idYes

TDQS

A3.9/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes
verifyNo

TDQS

A3.8/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters2/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes
n_stepsNo
target_entity_idNo
ci_pause_thresholdNo

TDQS

A3.6/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters2/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

  1. 7 tool updatesv0.1.0
    • First observedaurora_analyze
    • First observedaurora_explain
    • First observedaurora_findings
    • First observedaurora_forecast
    • First observedaurora_intervene
    • First observedaurora_load_bundle
    • First observedaurora_simulate

TDQS

A3.9/5.0
Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness4/5

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

ActivityActive
ResponsivenessSyncing

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    An 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
  • A
    license
    A
    quality
    B
    maintenance
    Deterministic 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.
    17
    MIT

Latest Blog Posts

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