DataCraftsmanAU/Vineverse

CI

vineverse-mcp MCP server

A stdio bridge to the hosted VineVerse MCP server — the Bible as a knowledge graph.

If your client speaks streamable HTTP, you do not need this package. Point it straight at the endpoint:

https://vineverse.bible/api/mcp

No API key, no account. This package exists for clients that can only launch a local process, and it does nothing except carry JSON-RPC messages between that process and the hosted server.

Install

// claude_desktop_config.json, or any client's equivalent
{
  "mcpServers": {
    "vineverse": {
      "command": "npx",
      "args": ["-y", "github:DataCraftsmanAU/vineverse-mcp"]
    }
  }
}

Or with Docker:

docker build -t vineverse-mcp .
docker run -i --rm vineverse-mcp

Node 20 or newer. There are no dependencies.

What is behind it

One immutable bundle of 12,761 documents in Open Knowledge Format, built from public-domain Scripture and openly licensed scholarship:

Sources and their licences are listed at vineverse.bible/attribution. The MIT licence on this repository covers the bridge, not the corpus.

Tools

15, unchanged from the hosted server — this package neither adds nor filters any.

Configuration

Useful for running against a local checkout of the site:

VINEVERSE_MCP_URL=http://localhost:3100/api/mcp node index.js

Test

npm run build   # syntax check — there is nothing to compile
npm test

CI runs both on every push and weekly on a schedule, against Node 20 and 24. The scheduled run is deliberate: because the test talks to the live endpoint, a green badge on a repository that has not changed in months still means the server answers today.

build exists because hosted builders (Glama among them) run install then build unconditionally. Rather than a no-op, it runs node --check, which is the only meaningful build step a dependency-free single file has.

The test spawns a real child process rather than importing the module, because two of the four things being checked — that a notification draws no reply, and that the process exits 0 without truncating a response — are properties of the process, not of any function in it.

Spawns the bridge as a real child process and drives it over stdio: initialize, notifications/initialized, tools/list, then a get_passage call for John 3:16. It talks to the live endpoint, so a failure means either the bridge or the hosted server.