Prototipo · Versión preliminar: todos los servidores del registro oficial, sincronizados cada 30 minutos. Las reseñas y las cuentas llegarán en una etapa posterior.
PopNx MCPServidores MCP para quienes usan IA · explicados con palabras sencillas

Gateway

de bolyraversión 0.2.1i★ –iSe ejecuta en tu computadora
Nombre en el registroio.github.bolyra/gateway

Instalar

Resumen

Descripción del creador (original en inglés)

MCP auth gateway: verify agent identity, enforce per-tool permissions, block replays, emit receipts.

Los tres pilares de PopNx MCP

Estos tres nunca se combinan en una sola puntuación: las opiniones, las mediciones y la popularidad son cosas distintas.

Qué puedes hacer con él

Todavía no escribimos un resumen sencillo para este. Abajo están los datos que leímos del registro.

  • Conexión: Se ejecuta en tu computadora
  • Transporte: stdio
  • Categoría: Otros

Instalación

Elige la app de IA que usas y copia la configuración.

Antes de instalar

Necesitas

  • npmNode.js instalado (para el comando npx)

¿Qué app usas?

Elige tu app arriba. La recordamos, así que la próxima vez el botón dirá “Instalar en …”.

Abre Claude Desktop → Settings → Developer → Edit Config y pega esto en claude_desktop_config.json

{
  "mcpServers": {
    "gateway": {
      "command": "npx",
      "args": [
        "-y",
        "@bolyra/gateway"
      ]
    }
  }
}

Ejecuta esto en tu terminal

claude mcp add gateway -- npx -y @bolyra/gateway

Abrir en Cursor

O copia la configuración tú

Pégalo en .cursor/mcp.json de tu proyecto, o en ~/.cursor/mcp.json

{
  "mcpServers": {
    "gateway": {
      "command": "npx",
      "args": [
        "-y",
        "@bolyra/gateway"
      ]
    }
  }
}

Tu navegador te pide permiso para abrir la app; luego la app muestra la configuración y te pide confirmar. Los valores de las claves quedan vacíos para que los completes tú.

Abrir en VS Code

O copia la configuración tú

Pégalo en .vscode/mcp.json de tu proyecto

{
  "servers": {
    "gateway": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y",
        "@bolyra/gateway"
      ]
    }
  }
}

Tu navegador te pide permiso para abrir la app; luego la app muestra la configuración y te pide confirmar. Los valores de las claves quedan vacíos para que los completes tú.

Este se ejecuta en tu computadora, y ChatGPT solo puede conectarse a servidores en internet. Elige otra app.

Tu elección se guarda en una cookie en este dispositivo; no necesitas cuenta.

Esta configuración se genera a partir de la ficha del creador en el registro. Si el README dice otra cosa, sigue el README.

Qué puede hacer

Se ejecuta en tu computadora; la lista de herramientas aparece en tu app de IA después de instalarlo.

Revisiones básicasi

Revisamos información que cualquiera puede ver; no hemos leído el código. Las revisiones que no aplican no se cuentan. · Revisado el 7 nov 2026

  • ✓ Superada

    El creador coincide con el repo

    El nombre en el registro se verificó con la cuenta de GitHub bolyra, dueña del repo

  • … Aún sin revisar

    Sigue en mantenimiento

    Todavía no hemos leído este repo en GitHub

  • … Aún sin revisar

    Tiene licencia

    Todavía no hemos leído este repo en GitHub

  • – No aplica

    El endpoint responde

    Este se ejecuta en tu computadora; no hay endpoint en internet

  • – No aplica

    Inicio de sesión con OAuth

    Se ejecuta en tu computadora y usa ajustes locales en su lugar

  • … Aún sin revisar

    Sin instrucciones ocultas en las descripciones de herramientas

    Se ejecuta en tu computadora; solo podemos leer listas de herramientas de endpoints en internet

Comparado con otros en Otrosi

  • Más estrellas que el 0% de los otros 32568 servidores de esta categoría
  • Publicado en el registro más recientemente que el 14% de los otros 32568 servidores de esta categoría
  • Revisiones básicas iguales o mejores que el 100% de los otros 32568 servidores de esta categoría

Comparado con todos los servidores activos de esta categoría en el registro. Las estrellas solo cuentan cuando quien lo publica es dueño del repo.

Preguntas frecuentes

¿Es seguro Gateway?

Superó 1 de 1 revisiones básicas aplicables. No hemos leído el código. Antes de agregar una clave o un token, revisa qué acceso pide el servidor y usa una clave que tenga solo los permisos que necesitas.

¿Qué claves o códigos necesita?

El registro no indica ninguna clave obligatoria, aunque algunos servidores te piden iniciar sesión la primera vez que los usas.

¿Se ejecuta en mi computadora o en la nube?

Se ejecuta en tu computadora. Tu app de IA lo inicia cuando hace falta, y los datos no pasan por los servidores del creador (a menos que el propio servidor llame a un servicio en línea).

¿Sigue en mantenimiento?

El repo de GitHub cambió por última vez –, y la última versión (0.2.1) llegó al registro hace 5 meses.

¿Qué apps pueden usarlo?

Las apps compatibles con MCP, como Claude Desktop, Claude Code, Cursor y VS Code. También necesitas Node.js en tu computadora.

¿Qué puedo usar en su lugar?

En la misma categoría: Spec Driven Development, Remote Desktop Commander, FlyDocs

Alternativas

Servidores de la misma categoría hechos por otros creadores, ordenados por estrellas.

Cómo leer una tarjeta:★ Estrellas de GitHubiTres pilares: reseñas · revisiones · usoiActualizado = fecha en que se publicó la última versión en el registroi

Spec Driven Development

de formulahendry

MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.

Se ejecuta en tu computadora★ 440MITActualizado hace 14 meses
Instalar

Remote Desktop Commander

de desktop-commander

Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.

Se ejecuta en la nube★ 211Actualizado ayer
Instalar

FlyDocs

de flydocs.ai

Spec-driven development workflow: your agent works issues, sessions and the status lifecycle.

Se ejecuta en tu computadoraActualizado hoy
Instalar

README del creador

Abrir el README

Copiado tal cual del repo del creador. PopNx MCP no lo ha revisado ni lo respalda. Se quitaron HTML, imágenes y scripts. Los enlaces llevan fuera de este sitio.

@bolyra/gateway

Bolyra MCP Auth Gateway -- standalone reverse proxy that verifies agent ZKP credentials before forwarding requests to upstream MCP servers.

Put @bolyra/gateway in front of your MCP server; it verifies agent authority, prevents replay, enforces delegated scopes, and gives you signed audit logs for every tool call.

Quickstart

# Install

npm install @bolyra/gateway

Create a config file (optional)

cat > gateway.yaml << 'EOF' target: http://localhost:3000/mcp port: 4100 devMode: true EOF

Run

npx @bolyra/gateway --config ./gateway.yaml

Or run directly with CLI flags:

npx @bolyra/gateway --target http://localhost:3000/mcp --dev --port 4100

How It Works

                  +----------------------------------+

| @bolyra/gateway | Agent -------->| |--------> Upstream MCP Server (with proof | 1. Parse Authorization header | (unmodified) bundle) | 2. verifyBundle() from @bolyra/mcp| | 3. checkToolPolicy() | | 4. Nonce replay check | | 5. Emit signed receipt | | 6. Proxy request + X-Bolyra-* hdrs| | | | Config: gateway.yaml | | Receipts: ./receipts/ or stdout | +----------------------------------+

Request routing:

  1. GET /healthz -- returns gateway status (intercepted, not proxied)
  2. JSON-RPC method != tools/call -- forwarded to upstream without auth
  3. JSON-RPC method == tools/call -- auth verified, then forwarded if authorized

CLI Reference

npx @bolyra/gateway [options]

Options: --target Upstream MCP server URL (required unless in config) --port Gateway listen port (default: 4100) --config Path to gateway config file (default: ./gateway.yaml) --dev Enable Bolyra Core mode (classical checks: tool policy, nonce replay, signed receipts, credential binding against registered credentials; ZK proof verification off. Without registered credentials, permission claims are self-asserted — see Credential Binding below) --credentials Credentials file (YAML/JSON map: commitment -> { permissionBitmask, expiryTimestamp? }); overrides the config's credentials section --receipt-dir Directory for receipt JSON files (default: ./receipts/) --receipt-stdout Write receipts to stdout (NDJSON) --no-receipts Disable receipt generation --network Bolyra network (default: base-sepolia) --help Show help --version Show version

CLI flags override config file values.

Config File Reference

# gateway.yaml

target: http://localhost:3000/mcp port: 4100 network: base-sepolia

Bolyra Core mode: classical checks only, ZK proof verification skipped

devMode: false

Registered credentials (see "Credential Binding" below).

Core mode (devMode: true): claims are checked against this registry —

unknown commitments, forged masks, and expired credentials are denied.

Production mode: this map becomes the resolveCredential source for

verifyBundle's Poseidon3 scopeCommitment binding (expiryTimestamp

required per entry).

type: registry (on-chain resolution) is not supported by the packaged

gateway yet and fails validation — use the library resolveCredential

option for custom resolution.

credentials: type: static map: "48201394857102938471029384": # credential commitment (decimal) permissionBitmask: 3 # READ_DATA | WRITE_DATA expiryTimestamp: "1893456000" # unix seconds; optional in Core mode

Per-tool policies

tools: write_file: requireBitmask: 2 # WRITE_DATA (0b10) delete_file: requireBitmask: 6 # WRITE_DATA + FINANCIAL_SMALL (0b110) maxChainDepth: 0 # Direct credentials only transfer_funds: requireBitmask: 28 # FINANCIAL_* (0b11100) minScore: 90

Nonce replay protection

nonce: store: memory # "memory" (default) or "redis" maxProofAge: 300 # seconds

Redis config (required when store: redis)

redis:

url: ${REDIS_URL} # required

keyPrefix: "bolyra:nonce:" # optional, default shown

connectTimeout: 5000 # optional, ms

Receipt signing — every allow/deny decision is ES256K-signed (see

"Signed Receipts" below). Without privateKey an ephemeral key is

generated at startup; set it for a stable, pinnable signer address.

receipts: enabled: true issuer: "my-gateway" keyId: "k1" privateKey: "${BOLYRA_RECEIPT_KEY}" # 32-byte hex secp256k1 key, env var substitution output: file # "file", "stdout", or "webhook" dir: ./receipts/

Health check

health: enabled: true path: /healthz

Optional HMAC signing for X-Bolyra-* headers

hmac:

secret: "hex-encoded-shared-secret"

Environment variables are substituted in string values using ${VAR_NAME} syntax.

Library API

For embedding the gateway middleware in your own server:

import {

createGatewayMiddleware, createGatewayProxy, loadConfig, injectBolyraHeaders, computeHmac, verifyHmac, createReceiptWriter, createHealthHandler, } from '@bolyra/gateway'; import type { GatewayConfig, GatewayMiddlewareOptions, GatewayRequest, } from '@bolyra/gateway';

// Option 1: Full proxy server const config = loadConfig({ target: 'http://localhost:3000/mcp', dev: true }); const server = createGatewayProxy({ config }); server.listen(4100);

// Option 2: Just the middleware (for custom servers) const middleware = createGatewayMiddleware({ config }); // Use in your request handler: // const authorized = await middleware(req, res, toolName);

Exports
ExportDescription
createGatewayProxy(options)Create full reverse proxy HTTP server
createGatewayMiddleware(options)Auth verification middleware only
loadConfig(flags?)Load and validate gateway configuration
injectBolyraHeaders(authCtx, receiptId?)Build X-Bolyra-* headers
computeHmac(headers, secret)HMAC-SHA256 sign X-Bolyra-* headers
verifyHmac(headers, secret, hmac)Verify HMAC on X-Bolyra-* headers
createReceiptWriter(config)Create pluggable receipt output
createGatewayReceiptSigner(config, override?)Resolve the ES256K receipt signer (configured key or ephemeral)
createHealthHandler(config)Create /healthz endpoint handler
extractToolName(body)Extract tool name from JSON-RPC body
loadCredentialsFile(path)Load a --credentials file (bare map or full section)
buildCredentialRegistry(credentials)Compile a static credentials section into a lookup registry
checkCredentialBinding(bundle, authCtx, registry)Core-mode registered-credential check (see Credential Binding)
createStaticCredentialResolver(credentials)Static resolveCredential for production scopeCommitment binding
hasStaticCredentials(credentials)True when a usable static credential map is configured
RedisNonceStoreRedis-backed NonceStore for multi-instance deployments

Redis Nonce Store (v0.2.0+)

For multi-instance deployments, use Redis for shared nonce replay protection:

# gateway.yaml

nonce: store: redis maxProofAge: 300 redis: url: ${REDIS_URL} keyPrefix: "bolyra:nonce:" # optional

Library usage:

import { createGatewayMiddleware, RedisNonceStore } from '@bolyra/gateway';

const store = new RedisNonceStore({ url: 'redis://localhost:6379' }); const middleware = createGatewayMiddleware({ config, nonceStore: store });

// Graceful shutdown process.on('SIGTERM', () => store.close());

Fail-closed behavior: If Redis is unreachable, the gateway returns HTTP 500, never passes requests through. Monitor Redis availability as a critical dependency.

X-Bolyra-* Headers

When a request passes verification, the gateway injects these headers into the proxied request:

HeaderValue
X-Bolyra-Verifiedtrue
X-Bolyra-DIDdid:bolyra:{network}:{commitment}
X-Bolyra-ScoreVerification score (0-100)
X-Bolyra-PermissionsEffective permission bitmask (decimal)
X-Bolyra-Chain-DepthDelegation chain depth (0 = direct)
X-Bolyra-Receipt-IDSigned receipt id for this decision (when receipts enabled)
X-Bolyra-HMACHMAC-SHA256 signature (when HMAC configured)

The upstream server can use these headers for logging/auditing without importing Bolyra.

Signed Receipts (v0.3.0+)

Every tools/call decision — allow and deny, dev mode and production — produces an ES256K-signed receipt (SignedReceipt from @bolyra/receipts: secp256k1 + keccak256, Ethereum-compatible recovery). This includes rejections with no usable proof bundle at all: a missing or malformed Authorization header still leaves a signed anonymous deny receipt, so the audit trail has no unsigned gaps.

Each receipt carries the verdict (decision.allowed), a human-readable reasonCode (which tool, which permissions were required vs. held), the agent DID when known, score, permission bitmask, delegation chain depth, hashes of the presented proof material, and the decision timestamp. Any edit to a receipt breaks its signature.

Signing key resolution:

  1. receiptSigner option (library embedders)
  2. receipts.privateKey from the config (recommended for production)
  3. Otherwise an ephemeral key is generated at startup. Receipts remain independently verifiable — the signer address is recoverable from every signature — but the address rotates on restart. The CLI prints the signer address in the startup banner and, in file output mode, persists it to {receipt-dir}/signer.json so auditors can pin the trust anchor.

Independent verification needs only the receipt (plus, optionally, the pinned signer address) — no gateway, no database:

import { verifyReceipt } from '@bolyra/receipts';

const receipt = JSON.parse(fs.readFileSync('receipts/2026-07-10/....json', 'utf8')); verifyReceipt(receipt); // true — signature + payload hash check verifyReceipt(receipt, pinnedSigner); // true — also pins the signer address

Hash-Chained Receipts (v0.5.0+)

Signatures make each receipt tamper-evident; hash-chaining makes the receipt stream tamper-evident. Every receipt the gateway signs carries chain: { seq, prevReceiptHash } inside the signed payload (seq is 0-based per gateway process; the first receipt links to the 32-zero-byte genesis sentinel) plus a top-level receiptHash that the next receipt links to. Deleting, reordering, or inserting receipts in a collected log breaks chain verification even though every remaining signature stays individually valid:

# stdout mode: collect NDJSON to a file, verify signatures + chain

bolyra receipt verify-chain receipts.ndjson --signer 0xPinnedSigner

Notes for auditors:

  • One chain per gateway process. A restart starts a new chain at seq 0 — rotate the collected log per process run (or verify each run's segment separately); a mid-file restart is reported as chain-restart.
  • File mode writes one JSON file per receipt; the chain fields still order and link them (concatenate in seq order to verify).
  • Tail truncation is not detectable from the log alone. Chain verification proves nothing was deleted, reordered, or edited *within* the log, but a log cut after any receipt is still internally consistent. Pin the head ha

Solo se muestra el principio; lee el resto en el repo

Pregunta a PopNx