Conecta tus herramientas agénticas a Meteor

Cualquier herramienta que hable MCP — Claude, ChatGPT, Claude Code, Cursor, Windsurf, Cline, Codex o tu propio agente — se conecta directo a Meteor y trabaja en tu workspace. Opera: contesta conversaciones, busca contactos, agenda recordatorios, ejecuta Mets. Y construye: crea Mets, arma y publica flujos, programa automatizaciones y crea colecciones. Lo que no tiene tool propia lo alcanza igual, con tres tools genéricas que llaman cualquier operación de la API.

Introducción

El Model Context Protocol es un estándar abierto para que los agentes de IA descubran y usen herramientas externas de forma segura. El servidor MCP de Meteor es remoto y acepta dos formas de autenticarse: iniciar sesión en Meteor desde el cliente (OAuth, sin API key) o tu API key met_ — la misma que usas en la API REST. Cualquier cliente MCP puede conectarse; abajo está la config de los más comunes y de un agente propio.

¿No programas? La guía Usa Met desde Claude en 3 pasos explica cómo conectarlo y qué pedirle, sin tecnicismos.

El SDK y la API REST son para cuando tú escribes el código. El servidor MCP es para cuando un agente opera Meteor por su cuenta.

Conectar un cliente

https://api.met.meteor.com.co/api/v1/mcp

Sin credenciales, el servidor responde 401 con WWW-Authenticate y el cliente sigue el descubrimiento OAuth estándar (/.well-known/oauth-protected-resource → servidor de autorización → registro dinámico). La persona inicia sesión en Meteor, ve los permisos que pide el cliente y los aprueba; el token queda sobre el workspace en el que tiene la sesión abierta. Se renueva solo y se revoca en Ajustes → Desarrolladores → Apps autorizadas. Detalle del protocolo en Apps OAuth.

Con una API key, todos los clientes apuntan al mismo endpoint remoto y pasan tu key en el header Authorization. Mientras pruebas, usa una key de test (met_test_) y emítela solo con scopes de lectura: una key de test bloquea los efectos externos, pero no la escritura sobre tu workspace. Ver qué hace y qué no hace el modo de prueba.

claude mcp add --transport http meteor \
  https://api.met.meteor.com.co/api/v1/mcp \
  --header "Authorization: Bearer met_live_tu_key"

{
  "mcpServers": {
    "meteor": {
      "url": "https://api.met.meteor.com.co/api/v1/mcp",
      "headers": { "Authorization": "Bearer met_live_tu_key" }
    }
  }
}

{
  "mcpServers": {
    "meteor": {
      "url": "https://api.met.meteor.com.co/api/v1/mcp",
      "headers": { "Authorization": "Bearer met_live_tu_key" }
    }
  }
}

{
  "mcpServers": {
    "meteor": {
      "serverUrl": "https://api.met.meteor.com.co/api/v1/mcp",
      "headers": { "Authorization": "Bearer met_live_tu_key" }
    }
  }
}

[mcp_servers.meteor]
command = "npx"
args = ["-y", "mcp-remote", "https://api.met.meteor.com.co/api/v1/mcp", "--header", "Authorization: Bearer met_live_tu_key"]

Tu propio agente

Si construyes tu propio agente, conéctalo con un cliente MCP programático (por ejemplo, @modelcontextprotocol/sdk) y dale a tu modelo las tools de Meteor:

import { Client } from '@modelcontextprotocol/sdk/client';
import { StreamableHTTPClientTransport } from '@modelcontextprotocol/sdk/client/streamableHttp';

const client = new Client({ name: 'mi-agente', version: '1.0.0' });
await client.connect(new StreamableHTTPClientTransport(
  new URL('https://api.met.meteor.com.co/api/v1/mcp'),
  { requestInit: { headers: { Authorization: `Bearer ${process.env.MET_API_KEY}` } } },
));

const { tools } = await client.listTools();   // las tools de Meteor, según tus scopes
// pasas `tools` a tu modelo y ejecutas client.callTool(...) cuando el modelo lo pida

Así tu agente descubre y ejecuta las capacidades de Meteor sin que tú cablees cada endpoint a mano.

Descubrimiento

Si tu cliente resuelve servidores por dominio en vez de por URL fija, el descriptor está publicado:

curl https://developers.meteor.com.co/.well-known/mcp.json

Trae el endpoint, el transporte, cómo autenticar y la lista de tools. Se genera del catálogo real del servidor en cada build, así que no puede quedar desactualizado respecto de lo que el servidor expone de verdad.

Junto a él va server.json, el descriptor con el formato de los registros de MCP. Es el que sirve para que un agente encuentre Meteor sin conocer este dominio.

Capacidades

El catálogo son 115 tools sobre 21 dominios, y se filtra por los scopes de tu key: si la key no tiene el scope, la tool no aparece. Esta tabla se genera del catálogo real del servidor.

Las tools de la tabla tienen nombre propio: son lo que la gente hace todos los días, y tu asistente las prefiere. Para lo demás están las de la sección siguiente.

Cualquier operación de la API

El catálogo cierra con 3 tools que alcanzan cualquier operación de la API REST que no tenga tool propia: buscar la operación, ver sus parámetros y llamarla. Cada llamada pasa por la misma ruta que la API, con tu key, así que exige el scope de esa operación y respeta la idempotencia y los límites de tu plan.

Si tu key es de partner

Una key de partner habla con otro endpoint, en el host de la API de Partners:

https://api.partners.meteor.com.co/mcp

Son dos servidores distintos y con qué key te autenticas decide cuál te sirve: una key de workspace habla con el de arriba, una de partner con este. Un workspace y una cartera de clientes no comparten permisos, así que tampoco comparten catálogo — y una key de workspace apuntando aquí recibe un catálogo vacío, no un error.

Son 14 tools, todas con el prefijo met_partner_. El partner sobre el que operan sale de tu key, nunca de un argumento.

Cómo se comporta

El catálogo tiene dos partes: las tools curadas van primero y son las que tu asistente prefiere; las genéricas lo cierran.

• Tools curadas por dominio: conversaciones y canales, Mets (con sus habilidades y Funciones), flujos y automatizaciones, datos (colecciones, campos, vistas, items y tareas) y cuenta (plan, Energía, integraciones, eventos). Cada una dice cuándo usarla, con cuál va en pareja y si gasta Energía o tiene costo con Meta. El catálogo crece por dominio; la tabla de Capacidades es la lista vigente.
• Tres genéricas al final: met_search_operations → met_describe_operation → met_call_operation. Buscan una operación del contrato público por texto (en español o inglés), muestran sus parámetros, su scope y un ejemplo, y la llaman. Son para lo que no tiene tool curada.

Anotaciones y confirmación

Cada tool declara las anotaciones de MCP: readOnlyHint (solo lee), destructiveHint (borra o sobrescribe), idempotentHint y openWorldHint (tiene efecto fuera de Meteor: un WhatsApp, un correo, un gasto). Los clientes las usan para decidir cuándo pedirle permiso a la persona.

Lo que no se deshace exige además confirm: true en los argumentos: borrar (flujos, automatizaciones, colecciones, campos, items, pasos, respuestas rápidas), publicar un flujo, sobrescribir su borrador, ejecutar ya una automatización, instalar un snapshot, importar en lote, etiquetar en masa, crear una difusión o reemplazar credenciales. En la genérica, todo DELETE lo exige. Sin confirm, la llamada falla sin tocar nada y el error dice qué se perdería; la descripción de cada tool le pide al modelo confirmarlo con la persona antes de repetir.

Respuestas y reintentos

• Tope de ~20.000 caracteres por respuesta. Si una respuesta no cabe, se recorta conservando JSON válido: primero se acortan las listas, después los textos largos. La respuesta sale envuelta como { "truncated": true, "note": "…", "data": … } y la nota dice cuántos elementos se mostraron, para que el modelo pida la página siguiente o filtre.
• Idempotencia automática. Las escrituras pasan por la misma ruta que la API con una Idempotency-Key que el servidor deriva de la tool, sus argumentos y la petición. Si tu cliente reintenta la misma llamada, la escritura no se duplica: recibe la respuesta de la primera.
• Los mismos controles que la API. Cada llamada exige el scope de su operación y respeta el modo prueba, los límites de tu plan y el rate limit por key. Los errores llegan con el mismo code que en la API (missing_scope, not_found, rate_limited…) y una pista de qué hacer.
• Período vencido: lectura sí, escritura no. Si el workspace queda bloqueado por un período vencido, el servidor sigue respondiendo y las lecturas funcionan. Las escrituras responden 403 workspace_blocked, y la pista le dice al modelo que avise en vez de reintentar. Si la suscripción no está activa ni en prueba, la API y el MCP responden igual: sin acceso.

Lo que queda fuera

• Subidas y descargas de archivos: los bytes no pasan por el contexto del modelo. La metadata y la URL de un archivo sí.
• Lo que devuelve un secreto: crear un webhook o rotar su secreto de firma. Hazlo desde el panel o con el SDK.
• Compras y cambios de plan: no son parte del contrato público. Plan, consumo y Energía sí se consultan.
• Operaciones de partners: tienen su propio servidor (abajo, en Si tu key es de partner).

Si el modelo intenta una operación excluida, met_call_operation responde con el motivo y qué hacer en su lugar.

Dos tools que conviene conocer

• met_send_message respeta el piloto automático: si una persona del equipo está atendiendo la conversación (piloto apagado o en pausa, o el contacto pidió un humano), responde 409 autopilot_silenced y no envía nada.
• met_update_item fusiona: las claves de data que no mandas quedan como estaban. Para borrar un valor, mándalo vacío.

Seguridad

• La key —o los permisos que la persona aprobó al iniciar sesión— define el workspace y los scopes: el agente solo ve y ejecuta lo permitido.
• Las credenciales de terceros (de tus integraciones) nunca se exponen al agente — solo el resultado de las tools.
• Cada tarea ejecutada debita Energía y queda auditada, igual que en la API REST.
• Con una key de test (met_test_) los runs del agente no debitan Energía y las tools con efecto externo —enviar por WhatsApp, ejecutar integraciones, provisionar cuentas— no aparecen en el catálogo, así que el modelo no puede ni intentarlas.
• Una key de test sí escribe. Lo que queda fuera del catálogo es el efecto externo, no la escritura: si la key lleva items:write o contacts:write, el agente crea y edita registros reales de tu workspace, contra la misma base de producción y sin forma de revertirlos. Dale a un agente una key de test de solo lectura mientras exploras, o un workspace aparte si necesitas que escriba.

¿Prefieres escribir el código tú? Empieza por las Guías y el quickstart del SDK.