Guía / artifact / MCP

Artifact MCP: conecta un servidor de tools

Usa un artifact MCP cuando el release configura un servidor que una herramienta de IA puede llamar por stdio o HTTP.

Cuándo usar MCP

Elige MCP cuando el payload principal sea una conexión a un servidor, no un archivo de instrucciones markdown. HubBound escribe una entrada MCP compatible con el provider y conserva metadata de ownership para que uninstall retire solo lo que HubBound posee.

MCP interpreta content directamente; no necesita un markdown entrypoint. El deployment sí necesita al menos un patrón seguro que haga match en files, así que incluye un README.md u otra documentación pequeña en el snapshot.

Props de content

content debe ser un objeto JSON con la forma de la configuración MCP. Mantén secretos como referencias, nunca tokens literales. transport.type determina si el provider recibe un servidor stdio basado en command o uno HTTP basado en URL.

id Identificador estable del servidor. Si existe, HubBound lo usa para derivar el nombre del provider; si no, lo deriva del nombre del artifact.
enabled Indica si la entrada generada empieza habilitada.
transport.type Usa stdio, http, streamable_http o streamable-http según el servidor. Copilot también entiende sse en su forma nativa.
transport.command / args Comando y argumentos ordenados para un servidor stdio.
transport.url / headers URL y headers opcionales para HTTP. Pon referencias a secretos en los valores, no secretos literales.
transport.env / cwd Referencias de entorno y directorio de trabajo para stdio.
secrets Metadata de inputs requeridos: label, type, required, description y placeholder.
permissions Arrays opcionales tools.allow, tools.deny y confirm. Codex usa allow/deny para sus tools habilitados/deshabilitados.

Un deployment completo

El ejemplo usa stdio. Para HTTP, reemplaza command/args por url y headers. README mantiene útil el snapshot requerido sin convertirlo en configuración de runtime.

{
  "kind": "artifact",
  "path": "packages/docs-search",
  "tag": "vendor/docs-search",
  "version": "1.0.0",
  "visibility": "org",
  "artifact_type": "MCP",
  "description": "Busca en el índice interno de documentación",
  "content": {
    "id": "docs-search",
    "enabled": true,
    "transport": {
      "type": "stdio",
      "command": "node",
      "args": ["server.js"],
      "cwd": ".",
      "env": { "DOCS_TOKEN": "{{secrets.DOCS_TOKEN}}" }
    },
    "secrets": {
      "DOCS_TOKEN": {
        "label": "Token de documentación",
        "type": "secret",
        "required": true,
        "placeholder": "Pega tu token"
      }
    },
    "permissions": {
      "tools": { "allow": ["search"], "deny": ["delete"] },
      "confirm": ["reindex"]
    }
  },
  "files": ["README.md", "server.js"]
}

Verifica antes de deploy

Valida sintaxis JSON, confirma que cada referencia a secreto sea intencional y ejecuta dry-run. En install los providers reciben referencias de entorno, no valores literales; el usuario todavía debe proveer el secreto en su entorno o configuración del provider.

  • No pongas tokens en content, files, historial Git ni descripciones.
  • Haz ejecutable el comando y pruébalo independientemente antes de empaquetar.
  • Usa una versión exacta y súbela cuando cambie el contrato del servidor.
  • Si un provider no soporta una forma de permisos, su applicator puede omitir ese campo opcional; prueba el provider objetivo después de instalar.