Spec 006: hosting reactome-mcp

[adamjohnwright]

Three questions answered: is it the right server, does it have what we want, and where should it run.

A correction I owe

Spec 005 called reactome-mcp "just a prototype". That was the GitHub description field, not the code. It registers 40+ tools and 10 resources across the Content and Analysis Services, and 1.4.0 fetches the graph schema live via APOC, cached per session.

That stale sentence was an argument against adopting it. Second time this week I trusted a description over the thing itself.

It has the capability that justifies the work

Analysis. Gene list in, over-representation out, with p-values, FDR and found/not-found identifiers. No bundle at any freshness produces that — it is a computation over the user's list, not a lookup of stored text.

Direct Neo4j stays off, verifiably — not by convention:

// Graph database tools — only when NEO4J_URI is set
if (isNeo4jConfigured()) {
  registerCypherTools(server);
}

With the variable unset, the Cypher tools are absent from the tool list, not merely disabled. The model cannot see them.

The alternatives

Six Reactome MCP servers exist. Ours is the most recently pushed and the only one Reactome controls — depending on a third party for the interface to our own knowledgebase would be the strange choice. tc2fh/reactome-db-mcp goes direct to MySQL, which is exactly the coupling you ruled out.

The blocker is transport, and it is in the other repo

reactome-mcp is stdio-only — src/index.ts constructs a StdioServerTransport and nothing else. That is a local subprocess protocol: one client, one process, over pipes. It cannot be publicly accessible as written.

The fix is supported, not custom: the SDK ships server/streamableHttp, and the existing ^1.12.0 pin already resolves to 1.30.0, which has it.

Hosting it beats spawning it on every axis:

	subprocess (#127)	hosted over HTTP
Node.js in our Python image	required	not needed
process supervision	ours to write	none
other MCP clients	one per chatbot process	anyone

That last row is why it is worth doing properly: a hosted reactome-mcp is a Reactome service, not a chatbot implementation detail. Which is the instinct behind running it alongside the website.

Two decisions

D1 — who adds Streamable HTTP to reactome-mcp? It blocks everything and lives in that repository.

D2 — where does it run? Recommendation: alongside the website, public, rate-limited. The chatbot then becomes its first client rather than its owner.

Recorded as unverified: nobody has run it from here. Every number is a count of code, not a measurement of behaviour. A plan should open by running it once.

🤖 Generated with Claude Code