vineverse-mcp

Puente stdio hacia el servidor MCP alojado de VineVerse: la Biblia como un grafo de conocimiento.

Si tu cliente admite HTTP streamable, no necesitas este paquete. Apunta directamente al endpoint:

https://vineverse.bible/api/mcp

Sin clave de API, sin cuenta. Este paquete existe para clientes que solo pueden lanzar un proceso local, y no hace nada más que transportar mensajes JSON-RPC entre ese proceso y el servidor alojado.

Instalación

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

O con Docker:

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

Node 20 o posterior. No hay dependencias.

Related MCP server: KARP Word Graph

Lo que hay detrás

Un conjunto inmutable de 12.761 documentos en Open Knowledge Format, construido a partir de las Escrituras de dominio público y de trabajos académicos con licencia abierta:

Las fuentes y sus licencias se enumeran en vineverse.bible/attribution. La licencia MIT de este repositorio cubre el puente, no el corpus.

Herramientas

15, sin cambios respecto al servidor alojado: este paquete no añade ni filtra ninguna.

Configuración

Útil para funciona contra una copia local del sitio:

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

Prueba

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

El CI se ejecuta tanto en cada push como semanalmente, contra Node 20 y 24. La ejecución programada es deliberada: como la prueba habla con el endpoint real, una insignia verde en un repositorio que no ha cambiado en meses sigue significando que el servidor sigue respondiendo hoy.

build existe porque los sistemas de build alojados (Glama entre ellos) ejecutan install y luego build de forma incondicional. En lugar de ser un no-op, ejecuta node --check, que es el único paso de build significativo que puede tener un archivo único y sin dependencias.

La prueba lanza un verdadero proceso hijo en lugar de importar el módulo, porque dos de las cuatro cosas que se comprueban — que una notificación no obtenga respuesta y que el proceso salga con código 0 sin truncar una respuesta — son propiedad del proceso, de ninguna de sus funciones.

Inicia el bridge como un proceso hijo real y lo conduce mediante stdio: initialize, notifications/initialized, tools/list, y luego una llamada get_passage para Juan 3:16. Habla con el endpoint real, por lo que un fallo implica que hay un problema en el bridge o en el servidor alojado.