Vc Finder MCP server

vc-finder

VC / angel investor graph: which investors fit a raise, who is on which round, and which investing person at a firm to approach — every fact carrying the page it came from. Built for Mojibake's own raise first (Bruce ask 2026-09-29) and public since fleet #2663 (Bruce 2026-10-01: "just make it live; it will be easier to test"). Not npm-published — that is a separate Bruce-gated path. See docs/vc-graph-plan.md, docs/vc-graph-architecture.md, docs/vc-finder-staging-contract.md.

Part of Pipeworx — an MCP gateway connecting AI agents to 1688+ live data sources. This is an independent, unofficial integration — not affiliated with, endorsed by, or published by the upstream provider.

Store: D1, not Postgres (fleet #2526 store-change)

The architecture doc (§1) originally called for a dedicated Supabase Postgres project. Superseded 2026-09-30 by the PM (Bruce ruled out new Supabase spend): the store is ONE Cloudflare D1 database. Schema: sql/vc-finder-schema.sqlite.sql — a narrow port (only the tables this pack's 8 tools need) written because Liesel's full port was not yet on origin/main when this was built in parallel. Reconcile the two when hers lands; delete this one rather than let two schema files drift.

Shape

vcIndex service-binding-shaped object (RPC methods, not fetch — see VcIndexBinding in src/index.ts), the same shape as the PODINDEX precedent (workers/pod-index, docs/pod-researcher-design.md).

• mcps/vc-finder/ — this pack. 10 tools, vc_ prefixed. Calls a

WorkerEntrypoint exposing one RPC method per tool, backed by src/queries.ts (parameterized SQL against the D1 binding — no stored procedures; D1 has none). Deployed (fleet #2579) against the pipeworx-vc-finder D1 database; CI redeploys the code on push (.github/workflows/deploy-vc-index.yml) and never touches the data.

• workers/vc-index/ — the pipeworx-vc-index worker skeleton. A

Sequoia, SignalFire, two companies, two rounds, claims with provenance, precomputed investorsectorportfoliocounts / investorobserved_stats rows) for local testing only.

• scripts/vc-finder/fixtures/seed.sqlite.sql — fixed-id fixtures (a16z,

Local test (never a remote D1 database)

wrangler d1 execute VC_INDEX_DB --local --cwd workers/vc-index \
  --file sql/vc-finder-schema.sqlite.sql -y
wrangler d1 execute VC_INDEX_DB --local --cwd workers/vc-index \
  --file scripts/vc-finder/fixtures/seed.sqlite.sql -y

Then either query directly (wrangler d1 execute VCINDEXDB --local --cwd workers/vc-index --command "...") or run the pack's callTool() against the resulting local D1 sqlite file (workers/vc-index/.wrangler/state/v3/d1/...) via a harness that mocks _vcIndex with src/queries.ts's functions — see fleet #2526's task record for the exact harness used to produce the acceptance evidence (compiled with tsc, run with Node's node:sqlite).

People and contact routes (fleet #2561)

Bruce's 2026-09-30 case ruling: investing people are served with the contact routes they published. vcsearchpeople and vcgetperson are the two people tools; vcgetinvestor lists a firm's partners with their routes, and vcfindinvestorsforcompany names a relevantpartner per firm when one is known (most senior investing role, then one with a published route). Every path serves only exposurehold = 0 people and checks the removal list (removal_entry, mirrored from scripts/vc-finder/removal-list.json) at read time. Tests: workers/vc-index/src/queries.people.test.mts. Load/ER details: docs/vc-finder-staging-contract.md "How the store loads and serves them".

Shortened. The full README is on GitHub.