También en: English, Português, 日本語 · Todas las guías en español
Aviso: construimos Carbon Forge en 100monkeys.ai, así que lee esto como el relato de quien lo fabrica. Esta guía la redactó uno de nuestros agentes de IA y la revisó la empresa; esta versión en español es una traducción de la guía original en inglés. Los pasos de Carbon Forge citan la documentación pública (en inglés, con la traducción al lado); la configuración de cada cliente está copiada de la documentación de ese cliente, enlazada al lado. La última sección enumera lo que la documentación no responde.
Qué vas a montar
Un espacio de trabajo, varios clientes, un token para cada uno. El servidor de Carbon Forge habla Streamable HTTP, "binds every call to a workspace via a bearer token" (liga cada llamada a un espacio de trabajo mediante un token bearer), y "tools honor the cap exactly as a human session does: there is no agent-only privilege" (las herramientas respetan el límite exactamente como una sesión humana: no hay privilegios exclusivos para agentes; MCP overview). Cualquier cliente que pueda enviar una cabecera HTTP puede conectarse. Claude Code tiene su propia guía: Conecta Claude Code a Carbon Forge por MCP.
Paso 1. Crea un token por cliente
Inicia sesión en carbonforge.dev/login, abre la configuración, elige API tokens, escoge el espacio de trabajo, un rol máximo y un alcance de herramientas, y "name the token after the agent or environment that will hold it" (ponle al token el nombre del agente o del entorno que lo tendrá; MCP tokens). Un token por cliente significa que el registro de auditoría, que guarda "every tool call ... under the token identity" (cada llamada a herramienta con la identidad del token), te dice qué herramienta hizo qué, y que puedes revocar uno sin tocar los demás.
Elige los alcances según el trabajo (MCP token scopes): Basic LLM memory para un asistente que toma notas, Read-only memory o SCM reader para uno que solo lee, SCM agent para uno que escribe código en lanes. La documentación aconseja: "Default to the narrowest preset that still covers what the client needs." (Empieza por el preset más estrecho que aún cubra lo que el cliente necesita.)
Paso 2. Guarda cada token en una variable de entorno
El secreto "is shown once, then only the prefix" (se muestra una vez y después solo el prefijo). Los dos clientes de abajo pueden leerlo del entorno, así que nunca queda en un archivo de configuración que acabe en un commit:
export CARBON_FORGE_TOKEN=‹token for this client›Paso 3. Configura Cursor
Cursor lee los servidores MCP de mcp.json: ~/.cursor/mcp.json para todos los proyectos, o .cursor/mcp.json en un proyecto. Un servidor remoto lleva url y headers, y Cursor resuelve ${env:NAME} en ambos (documentación MCP de Cursor):
{
"mcpServers": {
"carbon-forge": {
"url": "https://carbonforge.dev/api/mcp",
"headers": {
"Authorization": "Bearer ${env:CARBON_FORGE_TOKEN}"
}
}
}
}Paso 4. Configura Codex
Codex guarda los servidores MCP en ~/.codex/config.toml, o en .codex/config.toml dentro de un proyecto de confianza. Un servidor Streamable HTTP lleva url, y bearer_token_env_var indica el "environment variable name for a bearer token to send in Authorization" (nombre de la variable de entorno con el token bearer que se envía en Authorization; documentación MCP de Codex):
[mcp_servers.carbon_forge]
url = "https://carbonforge.dev/api/mcp"
bearer_token_env_var = "CARBON_FORGE_TOKEN"Paso 5. Configura cualquier otro cliente MCP
Para Claude Desktop, la documentación de Carbon Forge dice: "add an MCP server entry pointing at the instance URL with the token in the Authorization header" (añade una entrada de servidor MCP que apunte a la URL de la instancia con el token en la cabecera Authorization). Para plugins de IDE: "point the plugin at the same MCP endpoint; Streamable HTTP works over plain HTTPS" (apunta el plugin al mismo endpoint MCP; Streamable HTTP funciona sobre HTTPS normal). Sea cual sea el formato de archivo del cliente, estos son los tres valores que hay que poner:
Endpoint: https://carbonforge.dev/api/mcp
Transport: Streamable HTTP
Header: Authorization: Bearer ‹token for this client›Paso 6. Comprueba cada cliente con cortex.ground
Pide a cada cliente que llame a cortex.ground. Devuelve "the calling identity, what the bearer can do, what is reachable" (la identidad que llama, lo que puede hacer el portador, lo que es accesible; cortex.ground). Compara las respuestas: cada cliente debería mostrar el mismo espacio de trabajo y las capacidades que permite su alcance. Un cliente con el token equivocado es rechazado; la documentación dice que un token incorrecto es "refused outright rather than quietly treated as anonymous" (rechazado de plano en lugar de tratarse en silencio como anónimo).
Paso 7. Indica el espacio de trabajo en cada llamada
Cada token recuerda su propio espacio de trabajo actual, así que "every agent has its own active workspace and they do not collide" (cada agente tiene su propio espacio de trabajo activo y no chocan; MCP token scopes). Eso también significa que dos clientes pueden apuntar en silencio a espacios de trabajo distintos. Dile a cada agente que pase workspace en cada llamada; las herramientas lo aceptan y nunca mueve el puntero.
Paso 8. Da a cada agente que escribe su propia lane
Las notas compartidas son páginas; el código compartido es donde los clientes chocan. En Carbon Forge un agente abre una lane en lugar de clonar: "A lane costs nothing to open and holds no copy, so one per task, or one per agent, is the expected use" (abrir una lane no cuesta nada y no guarda ninguna copia, así que lo esperado es una por tarea o una por agente; Working in lanes). Carbon Forge nunca fusiona texto por su cuenta; un parche que ya no aplica vuelve como un conflicto con nombre, y una integración es un solo changeset, todo o nada. El agente de Cursor y Codex pueden trabajar sobre el mismo trunk sin una fusión silenciosa entre ellos.
Lo que la documentación deja sin responder
- No hay configuración específica por cliente. La documentación de Carbon Forge nombra Claude Desktop y los plugins de IDE en una frase cada uno y no da ningún archivo para Cursor ni Codex; los fragmentos de arriba salen de la documentación de Cursor y de Codex.
- No se indica el endpoint para una instancia en su propio host o en un dominio propio;
https://carbonforge.dev/api/mcpes el que nombra la documentación. - How MCP works muestra una llamada curl a
/mcp, mientras que la página de acceso anónimo usa/api/mcp. - No se dice si los tokens caducan solos; sí se dice cómo revocarlos.
- No se menciona el inicio de sesión OAuth para clientes MCP; el método documentado es un token bearer.