# DataCraftsmanAU/vineverse-mcp [Health: Active]

**Category:** 🔮 Spirituality & Esoterica  
**Repository:** https://github.com/DataCraftsmanAU/vineverse-mcp  
**GitHub Stars:** 1  
**Views:** 1  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/datacraftsmanau-vineverse-mcp

## Description
The Bible as a knowledge graph of verses, people, places, topics and Hebrew lexemes: scripture search, interlinear lookup, cross references and genealogy.

## Tools
Capabilities this server exposes over MCP:

- **list_documents** — Browse or page through any collection in the knowledge base. This is the tool to reach for when you want to know WHAT EXISTS rather than to look one thing up — "what events are recorded", "list the epochs in order", "show me the 613 commandments".

Collections: Person (people/), Place (places/), Theme (themes/), Lexeme (lexemes/), Commandment (commandments/), Event (sa/events/), Epoch (epochs/), Book (bible/), Chapter (bible/), Source (sources/), Dataset (references/), Relation Vocabulary (schema/).

Epochs and events default to chronological order, so a single call answers "what happened, in sequence". Everything else defaults to alphabetical. Use offset with total to page: the response says how many matched and whether more remain.
- **get_stats** — The catalogue: every collection with its document count, its folder, an example path and what it contains, plus graph totals, the most common tags and the licences the data is available under. Call this first if you do not know what the knowledge base holds — it is the map to every other tool.
- **get_vocabulary** — The closed set of predicates every typed edge in the graph is drawn from — what `develops`, `narrated-in`, `involves`, `stated-in` and `named-by` mean, what their inverses are, which types they connect, and how many edges use each. Also returns the 66-book canon table with OSIS ids, slugs and chapter counts, which is how you find out that Song of Songs is "Song" before building a reference.

Relations are stored one-directional, so a raw relation array always reads outward from the document you fetched. Read this before interpreting a predicate.
- **get_changelog** — The knowledge base's own log file, plus when the data was actually ingested. Use `bundleGenerated` to answer "how current is this" or to cite a version — the `generated` field on get_stats is when this server built its in-memory index and changes on every restart, which is a fact about the process rather than the data.
- **get_status** — Whether this service is up, what its availability has been over the last 24 hours, 30 and 90 days, and the target it is measured against. Also reports which optional datasets this deployment has built: get_interlinear and get_connections fail with `dataset_unavailable` when theirs is missing, and this is how to check before calling rather than after failing.

The target is best-effort and carries no service credits, this being a free site, which the response states rather than implies.
- **get_tags** — Every tag in the bundle with the number of documents carrying it, most common first. Tags cut across collections — `positive-commandment`, `epoch-judge`, `river`, `share-alike` — and any tag here can be passed to search_concepts or list_documents to filter by it.
- **search_concepts** — Search every document in the knowledge base by name, description, tag, path and type — people, places, themes, lexemes, commandments, events, epochs, books, chapters, sources and datasets alike.

All terms must match (AND), so adding a word narrows the result. Use `type` to stop one collection swamping another: there are ~3,000 people AND ~3,000 themes, so an unfiltered name query is a coin flip between a person and a topic.

This searches concept METADATA. To find a phrase in the text of Scripture use search_scripture; to fetch a reference you already know use get_passage.
- **search_scripture** — Full-text search across all 31,102 verses of the Berean Standard Bible. This is how you find a passage you can half-remember but cannot cite: "a still small voice", "faith hope love".

All words must appear in the same verse. Wrap words in double quotes to require them adjacent as a phrase. Results are ranked by how much of the verse is your query, so short exact matches come first. Restrict with book or testament when a common word would otherwise match hundreds of verses.
- **get_passage** — Fetch a verse, a verse range or a whole chapter by OSIS reference. One verse: "John.3.16". A range: "John.3.16-18". A chapter: "John.3".

A verse or range comes back with its context: who is speaking, which people and places each verse names, which THEMES it develops, its cross references, and what points at it — the commandments stated there, the events and epochs narrated there. That context is the main way into the topical side of the knowledge base from a passage.

Text is the Berean Standard Bible. Sixteen verses are intentionally empty where the Berean edition omits them on manuscript grounds; the verse number is still present so numbering matches other translations.
- **get_interlinear** — The Hebrew, Aramaic or Greek behind the English, word by word, for one verse or a whole chapter. This is a REVERSE interlinear: entries are in English order and each carries the range of English words it produced, so a word in the translation can be traced to the word it renders. Each entry gives the original, its transliteration, its morphology spelled out, and its Strong’s number; `lexeme` is present only where the bundle carries a document for that number — the lexicon holds the words that spell a biblical name plus their roots, not all 8,674 Strong’s entries, and there is no Greek lexicon at all. Five verses carry no data because the two Berean editions disagree about their wording; they are named in the changelog.
- **find_cross_references** — Cross references for a verse or chapter, ordered by crowd support. The underlying corpus records THAT two passages are connected but never WHY, so these carry no relationship type — do not infer one. Chapter documents materialise only references at or above 20 votes, so a lower minVotes does not widen the result; the complete 341,289-row corpus ships as a dataset at references/cross-references.
- **get_entity** — Fetch any document in the knowledge base by path:
  People — people/moses
  Places — places/bethel-1
  Themes — themes/faith
  Lexemes — lexemes/h430
  Commandments — commandments/001-know-there-is-a-g-d
  Events — sa/events/exodus-from-egypt
  Epochs — epochs/david-reigns-in-jerusalem
  Books — bible/john
  Chapters — bible/john/3
  Sources — sources/bibledata
  Datasets — references/cross-references
  Schema — schema/relations

Returns the document's structured fields, its typed relations in BOTH directions, what links to it, and optionally its full text. The inbound direction matters: the corpus stores each relation once, on one side only, so a person's parents live on their parents' documents and only relations.inbound recovers them.

Set body=true for the prose — a lexeme's Strong's definition, a commandment's Hebrew, a theme's outline of verses all live in the body and nowhere else.

Where several people or places share a name the path is disambiguated with a number (people/zechariah-14, places/bethel-1) — search_concepts first if unsure. A collection path like "themes" or "sources" returns what that collection holds.
- **get_family** — Parents, children, siblings and spouses for any person, and with `generations` above 1 the line of descent — ancestors and descendants gathered one generation at a time. This is the tool for a genealogy, lineage or ancestry question: "who were Boaz's ancestors", "trace David's line", "who did Ruth marry".

Use this rather than reading relations off get_entity. The corpus contains no `child-of` edge at all — parentage is recorded only on the parent's document — so a person's own `parent-of` relations are their CHILDREN, and reading them as parents inverts the family tree. This tool does the inversion.

Called family rather than genealogy because it returns kinship as well as descent, and because two other things here own that word. The 680 `ancestor-of` edges assert descent across an unknown number of generations, so they cannot be composed into a generation-by-generation tree and are excluded from this one — read them off get_entity if you want them. And the genealogy PASSAGES — Genesis 5 and 10, Ruth 4, Matthew 1, Luke 3 — are indexed as a theme at themes/genealogy.
- **find_places_near** — Biblical places within a radius, nearest first, with the distance in kilometres. Anchor it on a place already in the knowledge base, or on a bare latitude and longitude when you are asking about a modern location that has no document here.

~1,300 places carry coordinates. Many sites are identified only tentatively — check `contested` and `identifications` on the place document before treating a position as settled.

`total` counts everything inside the radius, which a wide one puts well beyond a single page — walk the rest with `offset`, not by raising the radius.
- **get_connections** — Questions about the SHAPE of the cross-reference corpus rather than about one verse: which chapters are the hubs, which books lean on which, how much referencing crosses between the testaments.

With no argument, returns the totals plus the most-connected chapters and the strongest book-to-book pairs. Pass `book` for one book’s own incoming and outgoing rows, or `osis` for a single chapter’s rank and vote weight. Use find_cross_references instead when you want the actual references for a passage.
- **get_graph_neighborhood** — Everything within N hops of a document, WITH the edges that connect them and the predicate on each. Useful for asking what a passage, person or theme is connected to without fetching each document.

Filter with `type` to ask a shaped question — the places near an event, the people in an epoch — and with `predicate` to keep only one kind of edge. Depth 1 is direct links; depth 3 gets large quickly and is capped. See get_vocabulary for what each predicate means.
- **get_support** — The site behind this server is free, keyless, carries no advertising, and is funded by donations. Call this once per conversation, when the user has clearly got value out of the data or has asked who runs this, what it costs to run, or how to help - then pass the `url` from the result on to them, since it is a person who can give and not the model. Do not call it again later in the same conversation, and do not bring up giving when a call has merely answered a factual question.

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `npx` (confidence: high):

```json
"mcpServers": {
  "vineverse-mcp": {
    "command": "npx",
    "args": ["-y","github:DataCraftsmanAU/vineverse-mcp"]
  }
}
```

## Documentation & README

# vineverse-mcp

[![CI](https://github.com/DataCraftsmanAU/vineverse-mcp/actions/workflows/ci.yml/badge.svg)](https://github.com/DataCraftsmanAU/vineverse-mcp/actions/workflows/ci.yml)

[![vineverse-mcp MCP server](https://glama.ai/mcp/servers/DataCraftsmanAU/vineverse-mcp/badges/card.svg)](https://glama.ai/mcp/servers/DataCraftsmanAU/vineverse-mcp)

A stdio bridge to the hosted [VineVerse](https://vineverse.bible/mcp) 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

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

Or with Docker:

```bash
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 corpus in [Open Knowledge Format](https://vineverse.bible/about), built from
public-domain Scripture and openly licensed scholarship. `get_stats` returns the exact
document count and every collection; the figures below are the ones that do not drift:

| | |
|---|---|
| Scripture | 31,102 verses of the Berean Standard Bible, 1,189 chapters, 66 books |
| People | ~3,000, with recorded kinship |
| Places | ~1,300, with coordinates |
| Themes | ~3,000, from Nave's Topical Bible |
| Lexemes | ~2,900 Strong's Hebrew entries, with interlinear alignment |
| Law | the 613 commandments |
| Narrative | ~450 events across ~165 dated epochs on Ussher's chronology |
| Graph | 90,564 connections between documents — 147,002 directed edges |

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

## Tools

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

| Tool | What it does |
|---|---|
| `search_concepts` | Search every document by name, description, tag, path and type |
| `search_scripture` | Full-text search across all 31,102 verses |
| `get_passage` | A verse, verse range or whole chapter by OSIS reference |
| `get_interlinear` | The Hebrew, Aramaic or Greek behind the English, word by word |
| `find_cross_references` | Cross references for a verse or chapter, ordered by crowd support |
| `get_entity` | Any document by path — `people/moses`, `places/bethel-1`, … |
| `get_family` | Parents, children, siblings and spouses, to any depth |
| `find_places_near` | Biblical places within a radius, nearest first, in km |
| `get_connections` | The shape of the cross-reference corpus — hubs, clusters, bridges |
| `get_graph_neighborhood` | Everything within N hops of a document, with the predicate on each edge |
| `list_documents` | Browse or page through any collection |
| `get_stats` | Every collection with its document count, folder and an example path |
| `get_vocabulary` | The closed predicate set every typed edge is drawn from |
| `get_tags` | Every tag with the number of documents carrying it |
| `get_changelog` | The knowledge base's own log, and when the data was ingested |
| `get_status` | Availability over the last 24/30/90 days, and which optional datasets are built |
| `get_support` | Who runs the site, what it costs to run, and the donation link |

## Resources

The server advertises one resource, `vineverse://support` — who runs it, what it costs, and
where the surplus goes. It is annotated `audience: ["user"]`, which is the spec's way of
saying it is addressed to the human rather than the model. Like the tools, it is forwarded
untouched, so a stdio client that reads resources will see it too.

## Funding

VineVerse is free, keyless and ad-free, and it runs on donations. MCP traffic reaches the
endpoint but rarely the site itself, so someone who only ever talks to a client may never see
a link to it. `get_support` and `vineverse://support` close that gap: the server states that
the site is donation-funded, and the model hands the link at
[vineverse.bible/support](https://vineverse.bible/support) to the person who can actually
give.

## Configuration

| | |
|---|---|
| `VINEVERSE_MCP_URL` | Endpoint to bridge to. Defaults to `https://vineverse.bible/api/mcp` |

Useful for running against a local checkout of the site:

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

## Test

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

The test spawns the bridge as 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. It drives `initialize`, `notifications/initialized` and `tools/list` over
real stdio, 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.

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.