Read-only MCP exposure (v.next) — 2-phase, security-gated #11

New Issue

2026-07-10T16:17:02Z

Leonard commented

2026-07-10 16:17:02 +00:00

Category: Roadmap / v.next · Priority: LOW (parked until MVP Phase 1–2 confirmed)

Summary
Expose Athena as a read-only MCP server so any MCP-capable AI client (Grok, Claude, Hermes) can query oracle.db over the internet — same ingress pattern as the existing gitea MCP (giteaMCP.vps1.afterthedemo.com → Caddy route /mcp* → reverse_proxy 127.0.0.1:8081). Turns Athena from a closed cron job into a queryable knowledge store.

Why it matters

Layer 1 (plain DB-query MCP): low-risk, low-complexity — just wraps existing oracle.db queries as MCP tools (query_entries, get_trends, get_source_health). No new data pipeline.
Layer 3 (semantic MCP): with nomic-embed-text (#6), MCP primitives gain weighted relationships (semantic similarity scores) and deep real-time trend analysis — the cross-source convergence case keyword/hash matching misses.
Layer 4 (external-AI consultant): an outside AI reviewing Athena's own metadata/schema could flag curation gaps and tune queries/feeds. ASPIRATIONAL — no concrete criteria yet (what counts as a "curation gap," frequency, reviewer). Do not treat as planned.

Proposed sequencing (2 phases)

Phase 1 — plain-DB MCP: expose oracle.db read tools via MCP on a localhost port; add Caddy route /mcp* reverse-proxy to preprod1/2. Ships first, no embeddings required.
Phase 2 — semantic MCP: after #6 (nomic-embed-text) + #8 (Ollama) land, add weighted-relationship + real-time semantic trend tools.

CRITICAL — security pass required (do not inherit gitea MCP config by default)
Exposing a research DB to any MCP client is a different threat model than a private pipeline. Before any internet exposure:

Explicit auth (not just inherited header pass-through) — strength + key rotation
Rate limiting per client/key
Blast-radius analysis: what happens if the API key leaks (read-only scope, but still data disclosure)
Own Caddy block reviewed independently, not copied from gitea MCP

What happens if not done
Athena stays a closed system; its research can't be composed into other AIs' work without manual copy-paste. Lower leverage, but no risk.

Dependencies

#6 (embeddings) + #8 (Ollama) for Phase 2 semantic layer
Preprod SSL slots already exist (Caddy) — ingress ready
BLOCKED until MVP Phase 1–2 confirmed: pipeline runs unattended end-to-end, daily-cron reliability proven over a week. Do NOT fold into MVP-milestone docs (scope-creep risk).

External review notes (Claude, relayed)

Layer 1 genuinely low-risk; ship cheap useful thing first.
Layer 4 softest part — aspirational until it has actual criteria.
Security posture change is real; deserves its own explicit pass.

**Category:** Roadmap / v.next · **Priority:** LOW (parked until MVP Phase 1–2 confirmed) **Summary** Expose Athena as a **read-only MCP server** so any MCP-capable AI client (Grok, Claude, Hermes) can query `oracle.db` over the internet — same ingress pattern as the existing gitea MCP (`giteaMCP.vps1.afterthedemo.com` → Caddy `route /mcp* → reverse_proxy 127.0.0.1:8081`). Turns Athena from a closed cron job into a queryable knowledge store. **Why it matters** - Layer 1 (plain DB-query MCP): low-risk, low-complexity — just wraps existing `oracle.db` queries as MCP tools (`query_entries`, `get_trends`, `get_source_health`). No new data pipeline. - Layer 3 (semantic MCP): with nomic-embed-text (#6), MCP primitives gain **weighted relationships** (semantic similarity scores) and **deep real-time trend analysis** — the cross-source convergence case keyword/hash matching misses. - Layer 4 (external-AI consultant): an outside AI reviewing Athena's *own* metadata/schema could flag curation gaps and tune queries/feeds. **ASPIRATIONAL — no concrete criteria yet** (what counts as a "curation gap," frequency, reviewer). Do not treat as planned. **Proposed sequencing (2 phases)** - **Phase 1 — plain-DB MCP:** expose `oracle.db` read tools via MCP on a localhost port; add Caddy `route /mcp*` reverse-proxy to preprod1/2. Ships *first*, no embeddings required. - **Phase 2 — semantic MCP:** after #6 (nomic-embed-text) + #8 (Ollama) land, add weighted-relationship + real-time semantic trend tools. **CRITICAL — security pass required (do not inherit gitea MCP config by default)** Exposing a research DB to any MCP client is a **different threat model** than a private pipeline. Before any internet exposure: - Explicit auth (not just inherited header pass-through) — strength + key rotation - Rate limiting per client/key - Blast-radius analysis: what happens if the API key leaks (read-only scope, but still data disclosure) - Own Caddy block reviewed independently, not copied from gitea MCP **What happens if not done** Athena stays a closed system; its research can't be composed into other AIs' work without manual copy-paste. Lower leverage, but no risk. **Dependencies** - #6 (embeddings) + #8 (Ollama) for Phase 2 semantic layer - Preprod SSL slots already exist (Caddy) — ingress ready - **BLOCKED until MVP Phase 1–2 confirmed:** pipeline runs unattended end-to-end, daily-cron reliability proven over a week. Do NOT fold into MVP-milestone docs (scope-creep risk). **External review notes (Claude, relayed)** - Layer 1 genuinely low-risk; ship cheap useful thing first. - Layer 4 softest part — aspirational until it has actual criteria. - Security posture change is real; deserves its own explicit pass.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Tony_tech/athena-oracle#11