MCPs
Un MCP es un servidor de herramientas que el agente puede llamar mientras trabaja: leer un PR, comentar en la tarea, abrir una página en un navegador, consultar logs. Cada servidor expone varias tools, y vos decidís qué agente usa cuáles en cada etapa del tablero. Thulu trae sus propios servidores y deja registrar otros por URL.
El trabajo se reparte en dos pantallas, y las dos piden rol administrador en el workspace:
- Configuración → “MCPs” (
/mcps/): qué servidores existen, de dónde salen y si responden. Ahí se registra uno propio. “Usar en un agente”, arriba, lleva a la otra pantalla. - Agentes → pestaña “MCP”: qué servidores y qué tools recibe cada agente en cada etapa. Un servidor que no tildás acá no llega a ninguna corrida, aunque esté activo.
Los agentes llegan a los MCP a través del daemon
Sección titulada «Los agentes llegan a los MCP a través del daemon»El contenedor del agente no recibe la URL real de ningún servidor ni sus credenciales. Recibe la lista de los servidores que su etapa tiene concedidos, todos apuntando al proxy MCP del daemon (/mcp-proxy/<nombre>), y la clave de su corrida. En cada pedido el daemon revisa que la corrida tenga ese servidor concedido, rechaza un tools/call a una tool que no está en la lista concedida, filtra tools/list y le agrega al pedido la credencial que corresponda. Un .mcp.json editado por el agente no le abre un servidor nuevo, porque la concesión se revisa contra lo que se le dio al arrancar.
Dos servidores van directo, sin pasar por el proxy: argus-sandbox, que lo sirve el propio daemon por tarea, y el argus-browser por corrida, que escucha dentro del contenedor del agente y sólo acepta la clave de esa corrida.
Los MCP nativos
Sección titulada «Los MCP nativos»| Servidor | Tools | Para qué | Sin elegir tools concede |
|---|---|---|---|
octopus-api |
61 | Tareas, comentarios, adjuntos, preguntas, aprobaciones, casos de prueba, dependencias, agentes, proyectos, métricas. Es lo que deja al agente trabajar sobre el tablero. | Sólo lectura |
argus-github |
42 | PRs (leer, comentar, revisar, crear, atender el feedback del review), commit y push del worktree, GitHub Actions. El token de GitHub no llega al agente. | Lectura y escritura |
argus-browser |
29 | Chromium: navegar, hacer click, capturas, scripts y evidencia filmada. | Todo el servidor |
argus-cloud |
6 | AWS y Google Cloud en sólo lectura: ambientes, recursos, métricas, errores, logs, deploys (sólo GCP). | Todo (no tiene escritura) |
argus-sandbox |
7 | Correr comandos, builds y servidores de desarrollo en el sandbox de la tarea, y el script de arranque del proyecto. Lo sirve el propio daemon por tarea, por eso no aparece en /mcps. |
Todo el servidor |
argus-figma |
6 | Leer archivos de Figma en sólo lectura: estructura, nodos, renders, comentarios y proyectos de un equipo. Usa un token personal de Figma guardado en Credenciales (proveedor figma); el token no llega al agente. Viene apagado. |
Todo (no tiene escritura) |
Los nativos se eligen al instalar: thulu init muestra una lista para tildar cuáles levantar. En Kubernetes se prenden en los valores del chart con mcp.octopusApi.enabled, mcp.argusGithub.enabled, mcp.argusBrowser.enabled, mcp.argusCloud.enabled y mcp.argusFigma.enabled; los tres primeros vienen prendidos y argus-cloud y argus-figma apagados (ver Instalación self-hosted). En los compose, argus-figma es el perfil argus-figma. La página /mcps no instala ni desinstala servidores.

La columna “Origen” dice de dónde salió cada fila:
| Origen | Qué es | Qué podés hacer desde la página |
|---|---|---|
env |
Una URL con la que arrancó el daemon (MCP_<NOMBRE>_URL, la escriben thulu init o el chart). |
Nada: se cambia en deploy/.env o en los valores de Helm. |
runtime |
Un contenedor o pod que el daemon administra. | “Iniciar”, “Detener”, “Reiniciar”. |
registrado |
Una URL que alguien cargó desde esta página. | “Editar URL”, “Quitar registro” y, si autentica con OAuth, “Conectar”. |
“Salud” sale de que el daemon abra la URL del servidor y espere respuesta, con un límite de 3 segundos: “Responde”, “Arrancando” o “No responde”. Si dice “No responde”, pasá el mouse por encima: el motivo está en el tooltip. El contador de arriba (“4 / 4 activos”) cuenta las filas que respondieron. La tabla se actualiza sola cada pocos segundos; el botón de flechas al lado de “Agregar MCP” la refresca en el momento.
Registrar un MCP propio
Sección titulada «Registrar un MCP propio»Sirve para un servidor que ya corre en otro lado: un servicio interno de tu equipo, Jira, Slack u otro MCP de terceros. Tiene que hablar MCP por Streamable HTTP o SSE, y la URL la llama el daemon, no tu navegador ni el agente. Sólo lo puede hacer un admin del workspace operador (ver el recuadro “Quién puede registrar” más abajo).
-
Abrí “Configuración” (abajo a la izquierda en la barra lateral) y, en “Integraciones”, entrá a “MCPs”.
-
Hacé click en “Agregar MCP”, arriba a la derecha.
-
Completá “Nombre”: de 3 a 64 minúsculas, dígitos o guiones, que empiece con letra y no termine en guion (
ticket-reader). -
Pegá la “URL” y tocá “Detectar”. El daemon prueba la URL sin credenciales y dice “Responde Streamable HTTP.”, “Responde SSE.”, “Pide autenticación: elegí una credencial guardada.” o que pide OAuth; según la respuesta, preelige el “Transporte” y la “Autenticación”.

Detectar elige el transporte. El tilde de abajo queda apagado salvo que el servidor sea tuyo y le hable de vuelta a Thulu. -
Elegí la “Autenticación”:
- “Ninguna”: el daemon llama al servidor sin credencial.
- “Credencial guardada”: escribí en “Credencial” el nombre que tiene en la página Credenciales de cada workspace que use este servidor. Opcionalmente, una “Plantilla de encabezados” (un
Nombre: valorpor línea, con{campo}o{base64:a:b}tomando los campos de la credencial); vacía, manda el encabezado propio de la credencial. La credencial se usa sólo si está concedida a la tarea, el proyecto o el entorno de la corrida que llama, y el agente nunca la recibe.
-
Si querés, una “Descripción”, que se muestra en la tabla y en la pestaña MCP de los agentes.
-
Dejá apagado “Actúa sobre Thulu en nombre del agente” salvo que el servidor necesite llamar a la API de Thulu. Prendido, cada pedido le lleva la clave de la corrida, y el servidor puede hacer todo lo que puede ese agente.
-
Hacé click en “Registrar” (o Enter). Aparece “ticket-reader: registrado” y la fila se suma con origen “registrado”; en unos segundos muestra su salud.
El registro llega a los agentes que arranquen desde ese momento, sin reiniciar nada. Para que un agente lo use todavía falta concederlo en su pestaña MCP (siguiente sección).
Credenciales para un MCP de terceros
Sección titulada «Credenciales para un MCP de terceros»La credencial se carga en cada workspace, en “Credenciales → Agregar”, y se concede como cualquier otra (ver Credenciales y motores):
- Un servidor que acepta un token fijo (por ejemplo, Jira con un API token de Atlassian): proveedor “Encabezado HTTP”, con un bearer, usuario y token (Basic) o un encabezado propio.
- Un servidor que pide OAuth (Slack, Atlassian): registralo con “Credencial guardada” y después tocá “Conectar” en su fila (o en Credenciales). El daemon descubre el servidor de autorización, registra el cliente si el servidor lo permite (Slack pide una app propia, cuyo Client ID y Client Secret se pegan a mano), y te manda a iniciar sesión en el servidor. Los tokens quedan cifrados en el daemon, que los renueva antes de que venzan. Si el servidor rechaza la renovación, la credencial queda para “Reconectar”. “Desconectar” revoca los tokens y deja la credencial y sus concesiones.
Un mismo registro sirve a todos los workspaces: cada uno resuelve su propia credencial con ese nombre. Uno que no la tiene recibe un error al llamar, y el resto sigue andando. Para Figma usá argus-figma: el MCP remoto de Figma no acepta clientes fuera de su lista.
Para cambiar la URL, la autenticación, la descripción o el tilde de reenvío, usá el lápiz de la fila (“Editar URL”): abre el mismo modal con el título “Editar ticket-reader”, el nombre bloqueado y el botón “Guardar”. El nombre no se puede cambiar: hay que quitar el registro y volver a crearlo. El tacho (“Quitar registro”) pide confirmación y no toca el servidor de origen. Si el daemon tenía en su entorno una URL con el mismo nombre, los agentes vuelven a recibir esa.
Darle un MCP a un agente
Sección titulada «Darle un MCP a un agente»Los permisos se dan por agente y por etapa: el mismo agente puede leer GitHub en “Revisión” y escribir en “En curso”. Antes necesitás un agente con al menos una etapa válida, que se elige en su pestaña “Configuración” (ver Agentes); sin etapas, la pestaña MCP sólo dice “Elegí al menos una etapa válida en la pestaña Configuración.”
-
Entrá a “Agentes” en la barra lateral, elegí el agente de la lista de la izquierda y abrí la pestaña “MCP”. Vas a ver un bloque por cada etapa válida del agente, con todos los servidores disponibles.
-
Tildá el servidor que querés dar. Concede lo que cubre su scope por defecto (la tabla de arriba), sin las tools que se conceden por nombre. El contador de “Tools” dice cuántas quedan concedidas sobre el total, y la línea de abajo dice qué concede la etapa.

Cada servidor tildado concede su scope por defecto; las tools de deploy y de otros tableros quedan afuera. -
Hacé click en “Tools” para ver la lista con la descripción de cada tool, agrupada en “Lectura”, “Escritura”, “Administración” y los grupos que se conceden por nombre (“Deploy”, “Otros tableros”). Tildá o destildá y cerrá con “Listo” (o Esc). Si destildás todas, el servidor sale de esa etapa.

Las del grupo Deploy no entran en ningún scope: se tildan a mano, sólo en la etapa que tiene que hacerlo. -
Hacé click en “Guardar configuración” en la barra de abajo (o Cmd/Ctrl+S). Aparece “Configuración guardada” y las corridas siguientes reciben el cambio. Antes de guardar, “Revertir” descarta lo que tocaste. “Copiar a las otras etapas” repite el bloque en las demás etapas del agente.
Las tools de deploy (run_dispatch, deployment_approve, pr_merge) le permiten a un agente disparar workflows, aprobar un deploy o mergear un PR. Por default ningún agente mergea: un admin decide si concede pr_merge y en qué etapa. Para una etapa que despliega con GitHub Actions, “Plantilla Deploy” concede argus-github@read más run_dispatch, run_watch y run_logs.
Al tildar octopus-api, argus-browser o argus-sandbox, la pestaña “Skills” del mismo agente suma las skills del sistema que van con ese servidor (ver Los manuales de los MCP nativos).
Scopes y permisos por tool
Sección titulada «Scopes y permisos por tool»Cada tool de octopus-api, argus-github y argus-cloud pertenece a un grupo. Los grupos “lectura” y “escritura” funcionan como escalera: escritura incluye lectura. Los grupos de deploy y de otros tableros quedan afuera y sólo se conceden tool por tool.
| Grupo | Qué incluye | Cómo se concede |
|---|---|---|
| Lectura | Ver tareas, PRs, logs, recursos | Default de octopus-api y argus-cloud |
| Escritura | Comentar, crear tareas, commit y push, comentar PRs, crear PRs | Default de argus-github; en octopus-api con @write o eligiendo sus tools |
| Deploy | run_dispatch, deployment_approve, pr_merge (argus-github) |
Sólo tildándolas por nombre |
| Otros tableros | boards_list, board_tasks_list, task_create_on_board, task_move_to_board (octopus-api) |
Sólo tildándolas por nombre |
argus-browser y argus-sandbox no tienen grupos: se conceden enteros o tool por tool.
La pantalla elige sola la forma más corta de guardar lo que tildaste: si cubre todo un grupo, guarda el grupo; si sacaste algo, guarda la lista. Conviene quedarse en un grupo entero cuando se pueda, porque una lista queda fija y las tools que el servidor sume en una versión nueva no le llegan al agente.
Por API el mismo permiso se escribe en mcp_by_stage de PUT /types/{agente}/settings, con esta forma:
| Valor | Concede |
|---|---|
argus-github |
El default del servidor (en este caso, escritura) |
octopus-api@write |
Lectura y escritura |
octopus-api@write+boards_list |
Escritura más una tool de otro grupo |
argus-browser@screenshot+get_text |
Sólo esas dos tools |
Las tools se separan con +, no con coma.
MCP registrados
Sección titulada «MCP registrados»Un MCP registrado no declara grupos. Tildado entero, sin sufijo, concede todas sus tools: el bloque dice “Tildado concede todas sus tools” y el contador queda completo (3/3). Si elegís tools desde la pantalla, se guarda la lista de las tools elegidas y el proxy rechaza cualquier llamada a otra, aunque el servidor no filtre.

Distinto es un servidor del que Thulu sólo conoce las tools por un sondeo, sin descriptor ni registro: concedido entero, el bloque muestra “scope por defecto (desconocido)” y el contador en ?/N, porque el servidor aplica su propio default.
Los manuales de los MCP nativos
Sección titulada «Los manuales de los MCP nativos»Cada MCP nativo viaja con instrucciones para el agente: cómo encadenar sus tools, qué hacer ante cada error. No hay que concederlas: llegan a toda corrida cuya etapa tenga ese servidor tildado. Parte de ese conocimiento son skills del sistema (octopus-*), que se ven en “Skills” y en la pestaña “Skills” del agente con el motivo al lado.

| Skill del sistema | Llega con |
|---|---|
octopus-task-workflow, octopus-refinement, octopus-test-cases, octopus-observability |
octopus-api |
octopus-browser-evidence, octopus-evidence-library |
argus-browser |
octopus-sandbox |
argus-sandbox |
octopus-run |
Toda corrida |
Para dejar una afuera en una etapa, destildala en la pestaña “Skills” del agente y guardá. Los workspaces pueden leer estas skills pero no editarlas. El manual propio de cada servidor (el que explica sus tools) no tiene pantalla: viaja solo con la corrida.
Problemas comunes
Sección titulada «Problemas comunes»
- El formulario marca un campo en rojo: el nombre tiene mayúsculas o espacios, no empieza con letra, termina en guion o tiene menos de 3 caracteres, la URL no empieza con
http://ohttps://, o elegiste “Credencial guardada” sin nombrar la credencial. - “Detectar” dice que no respondió como un servidor MCP: el daemon no llegó a la URL o el servidor no habla Streamable HTTP ni SSE. La URL la tiene que alcanzar el daemon; que abra en tu navegador no prueba nada.
- Salud “No responde” en una fila registrada: el daemon no pudo abrir la URL. El motivo está en el tooltip.
- Salud “Sin comprobar” en las filas
envoregistrado: estás en un workspace que no es el operador. El daemon no prueba las URL para vos; no quiere decir que estén caídos. - El agente recibe un error al llamar a un MCP de terceros: la credencial con ese nombre no existe en el workspace o no está concedida a la tarea, al proyecto o al entorno de la corrida. La decisión queda registrada en el panel de la credencial. Si es una conexión OAuth que dice que necesita reconectar, tocá “Reconectar”.
- El agente dice que no tiene una tool: revisá en su pestaña “MCP” que el servidor esté tildado en la etapa de esa corrida y que la tool figure en “Tools”. Si la tool es de deploy o de otros tableros, hay que tildarla a mano.
- Un servidor muestra “todas las tools” en lugar del botón “Tools”: el daemon no pudo leer su lista (está caído o no habla MCP). Se concede entero hasta que vuelva.
- El agente no puede comentar ni mover su tarea con
octopus-api: tiene el servidor sin sufijo, que es sólo lectura. Abrí “Tools” y tildá las de escritura que necesita, o guardalo comooctopus-api@write.