Loomen.documentación
Ir a la consola
cliente

Inicio rápido

Del cero a una invocación real. Los seis pasos son los mismos para todos; tres de ellos cambian según el cliente que uses, porque conectar un servidor MCP no se hace igual en un diálogo de aplicación, en un archivo de configuración o en una llamada HTTP.

Elegiste claude code. Tu elección se guarda y viaja con vos por toda la documentación. Tres de los seis pasos cambian con eso; los otros tres son idénticos para todos.

01

Conectá un canal

Un canal es por dónde sale lo que el agente haga: una casilla de correo, un canal de Slack, un endpoint propio, una tabla. Se configura una vez, en la consola, y la conexión guarda también a dónde entrega — sin eso, la acción sale a ninguna parte y falla en el último tramo.

Para una primera prueba, SMTP con una contraseña de aplicación es el camino más corto. «Probar conexión» hace el saludo real contra el proveedor y no envía nada a nadie.

El remitente no es el usuario. Con una casilla común son la misma dirección, pero Mailtrap, SendGrid y SES entregan un token como usuario: ese token no es una dirección y el servidor rechaza el envío después de aceptar el login.

Las credenciales se guardan cifradas y no se vuelven a mostrar. Volver a abrir el formulario con el campo de contraseña vacío no borra la que está guardada: en blanco significa «no la estoy cambiando».

02

Registrá el agente y vinculá la acción

Registrar el agente es lo que emite su clave, y se muestra una sola vez: copiala antes de cerrar. La plataforma guarda un hash, así que no se puede volver a ver, solo rotar.

Un agente registrado no está autorizado a nada todavía. La vinculación es la que dice que ese agente puede ejecutar notificar sobre humano por ese canal. Sin ella, la primera llamada vuelve rechazada nombrando el par que falta.

Podés crear dos vinculaciones del mismo par apuntando a canales distintos: una sola llamada sale por las dos.

consola · vinculaciones / nuevarecreación
Agente
agente de cobranzas
Acción
notificar
Destino
humano
Canal
slack · #pagos
Política
firma humana sobre 1.000 USD

Con esa política, toda invocación que caiga en esta vinculación devuelve pending y un id hasta que alguien firme en la consola.

vinculación
avisar-a-pagos
clave del agente
sk_live_TU_CLAVE
la clave se muestra una sola vez
La segunda vinculación del mismo agente no muestra una clave nueva, y está bien: la credencial es del agente, no de la vinculación. Una sola clave cubre todo lo que ese agente tenga autorizado.
03varía · claude code

Conectá tu cliente

Claude Code agrega el servidor con un comando. El alcance decide quién lo ve: local es solo este proyecto, user te sigue a todos, project lo deja en un .mcp.json versionado con el repo.

En un .mcp.json versionado escribí ${LOOMEN_AGENT_KEY} en vez de la clave: Claude Code expande la variable del entorno al conectarse, y así el secreto no viaja en el repositorio.
terminal · claude mcp add
terminal
export LOOMEN_AGENT_KEY="sk_live_TU_CLAVE"
claude mcp add --transport http --scope user loomen \
https://mcp.loomen.dev/mcp \
--header "Authorization: Bearer $LOOMEN_AGENT_KEY"
04varía · claude code

Comprobá que el agente ve la herramienta

Antes de pedirle nada, confirmá el handshake. Si la herramienta no está listada, el problema es la conexión y no la vinculación.

dónde mirar · claude code
claude mcp list tiene que mostrar loomen conectado, y dentro de una sesión /mcp lista sus herramientas y sus recursos. La herramienta llega como mcp__loomen__loomen_execute_action.
05varía · claude code

Provocá la primera invocación

No hay nada que programar: le pedís al agente lo que querés que pase y él arma la llamada. Fijate que en tu pedido no nombrás ningún canal.

Quién recibe y por dónde lo decide la vinculación, no el prompt.
lenguaje natural · claude code
lo que escribís
Avisale al equipo de pagos que el cobro pag_9f31 falló tres veces seguidas.
el agente traduce eso a
lo que llama el agente
{
"name": "loomen_execute_action",
"arguments": {
"action": "notificar",
"destination": "humano",
"summary": "El cobro pag_9f31 falló tres veces seguidas",
"context": {
"pago": "pag_9f31",
"intentos": 3,
"monto": "12400.00 ARS"
}
}
}
06

Leé la respuesta

A partir de acá todos los clientes reciben exactamente lo mismo: un id de invocación, un estado y la lista de entregas. Una invocación puede tener varias entregas porque el par puede estar autorizado por varias vinculaciones.

Ese id es el que vas a buscar en Auditoría, donde la llamada se lee como un recorrido con sus pasos debajo.

respuesta.json
1{
2 "invocation_id": "inv_01a0c0e8-0dae-779d-ae1e-734593325e41",
3 "status": "delivered",
4 "deliveries": [
5 {
6 "action_id": "01a0c0e8-0db2-781a-a459-04e252223094",
7 "binding_id": "01a0c0e8-0cf1-7b34-9d2e-2b8b0f9a1f77",
8 "channel": "email",
9 "status": "delivered",
10 "provider_reference": "71b66c2b0289dd385120df0aee9a547c@core-api.loomen.dev"
11 },
12 {
13 "action_id": "01a0c0e8-0db4-7c61-bb90-6d2f5e0a44c1",
14 "binding_id": "01a0c0e8-0d02-7a55-8f41-93cf3d1b7a20",
15 "channel": "webhook",
16 "status": "delivered",
17 "provider_reference": "http-200"
18 }
19 ]
20}

Si no dijo delivered

Tres respuestas se leen mal la primera vez y ninguna es un fallo del sistema: la que nombra un par sin vinculación, la que queda esperando una firma humana y la que salió por dos canales y falló en uno.