Viska Research · Architecture Brief

MCP Exposure of Viska's Own Research Corpus

Ask: an MCP connection to our research corpus, callable through a cloud desktop connection — Claude Desktop / claude.ai.

Owner ViskaRes Date 2026-07-06 Tier internal = deep-read · external = vendor-verified Origin AI fund-intel landscape gap 🟡

Verdict

Shippable now, near-zero build for Phase 0. We already speak MCP and the corpus already lives in Supabase with a similarity-search RPC. The gap is not capability — our one MCP (viska-vault) is local stdio, not cloud-reachable, and the valuable corpus (Supabase pgvector) has no MCP surface at all. Both close by adopting Supabase's hosted remote MCP; grounded semantic retrieval is a small follow-on build.

1 · What corpus we actually have

Two distinct forms — this distinction drives everything.

Corpus	Where	Exposed today	Cloud-reachable?
A — Obsidian wiki `Viska-Wiki-Engineering`	Local Dropbox path, operator box	`viska-vault` MCP = local stdio npx @mauricio.wolff/mcp-obsidian · .mcp.json:3	✕ No — single machine, single user
B — Supabase pgvector DB	Supabase project (live, RLS-on)	Nothing — service-role writes + `match_*` RPC read, no MCP	DB is cloud-hosted, but no MCP

Corpus B is the real research corpus — embedded, grounded-retrieval-ready, with a citation gate (corpus_status='verified') already enforced at the RPC. Live contents (hades #70-73):

video_sources — deep-analysis records (stance / signal / theme, key_points, cited)
transcript_chunks — vector(1536) embeddings, text-embedding-3-small
match_transcript_chunks(query_embedding, match_count, filter_theme, min_published) — cosine similarity RPC, verified-chunks-only filter baked in
plus embeddings_main (existing 1536 corpus) · research_findings (conviction newsfeed)

2 · What "cloud desktop connection" means

Claude Desktop + claude.ai support custom connectors via remote MCP servers (Settings → Connectors → Add custom connector). Verified against vendor docs:

Transport = Streamable HTTP (MCP protocol 2025-11-25; old SSE deprecated).
Auth = OAuth; hosted servers use OAuth 2.1.
Available on Free/Pro/Max/Team/Enterprise; works from any device — the server is a remote HTTPS URL, not tied to one machine.

Key consequence: the local stdio viska-vault MCP cannot be a cloud desktop connector — local stdio only works on the machine that runs it. Cloud-from-anywhere ⇒ remote MCP over HTTPS. Corpus A is out of scope for "cloud" unless separately bridged.

3 · Options — prior-art first (rule #18, don't rebuild)

Option	What	Build	Fit
0 · Supabase hosted remote MCP `mcp.supabase.com`	Official, OAuth 2.1, read-only via `?read_only=true`, add as custom connector today	Zero	Broad — exposes SQL/table query over the whole project. Powerful, but the LLM writes SQL, not semantic vector search. Needs scoping.
1 · Thin custom MCP on Supabase Edge Functions	One tool `search_research_corpus(query, theme?, since?)` → embed query → call `match_transcript_chunks` → return cited chunks + `?t=` jump links	Small	Best — grounded semantic retrieval, verified-only, native to our stack, reuses the C4 schema + RPC already live. The InsightsLM / `retrieve()` pattern already specced (07-02 chat-stack, T4).
2 · Bridge Obsidian wiki to cloud	Mirror wiki → queryable store, or remote-MCP Obsidian bridge	Medium	Skip for now — most research value already flows into Supabase B; wiki is a working local surface.

4 · Recommendation — phased

Phase 0 · now · $0 · zero build

Hosted remote MCP, read-only

Add mcp.supabase.com in read-only mode as a custom connector in Claude Desktop / claude.ai. Ship behind a scoped read-only DB role + RLS so the connector sees only corpus tables — not the whole project. Proves the capability today.

Phase 1 · small build · the real product

Thin semantic MCP Edge Function

Deploy an MCP Edge Function exposing search_research_corpus over the verified-only RPC. Grounded, cited, semantic retrieval (not raw SQL) with ?t= YouTube jump links. Everything downstream already exists — wiring, not new architecture.

5 · Security / confidentiality

Not mutating → rule #19 (open-mutating-endpoint) predicate does not fire. Read-only.
But it IS external exposure of fund research → confidentiality gate: OAuth 2.1 (both paths) + read-only role + corpus_status='verified' filter (excludes draft / PII / off-thesis chunks — already enforced at the RPC). No service-role key in any connector config; OAuth only.
Phase-0 read-only mode also disables migrations / edge-deploy / storage changes vendor-side — safe default.

6 · Effort + ownership

Phase	Owner	Effort
0 — hosted remote MCP + scoped read-only role	ViskaDB (role/RLS) + operator (add connector, OAuth)	~hours
1 — thin Edge-Function semantic MCP	ViskaN8N/ViskaDB (deploy) + ViskaRes (tool schema + prompt semantics)	~1 build arc

This is the gap the landscape flagged 🟡 — "no MCP/agent-callable exposure of own corpus" — and it's the direction the whole institutional tier is moving (FactSet / Kensho / Quartr MCP exposure).

Sources

Build custom connectors via remote MCP servers — Claude Help
Get started with custom connectors using remote MCP — Claude Help
Announcing the Supabase Remote MCP Server
Deploy MCP servers (BYO-MCP / Edge Functions) — Supabase Docs
Supabase MCP Server — Docs
Repo: .mcp.json · research/youtube-deep-analysis/c4-pgvector-schema.md · research/ai-fund-intel-landscape-2026-07-06/REPORT.md

Viska Research Agent · corpus-MCP cloud-connector brief · 2026-07-06 · YT C5 unaffected (still standing by for ViskaN8N seed ping)