**Model Context Protocol (MCP)** se está convirtiendo en el patrón habitual para conectar agentes de IA a sistemas reales. Esta guía explica qué implica para su equipo, cómo participa **Dailybot** en ese ecosistema y cómo abordar configuración, herramientas y casos de uso cotidianos—sin tratar el protocolo como algo mágico.

## Qué es MCP

**MCP** es un **estándar abierto** para conectar agentes de IA a **herramientas y datos**. En lugar de que cada asistente defina su propio formato de plugins, MCP describe cómo un cliente (su agente en el IDE o en la terminal) habla con un **servidor** que publica **tools** (acciones invocables) y **resources** (contenido legible). Las respuestas suelen ser **JSON**, de modo que tanto personas como automatización puedan confiar en ellas.

En esencia: el modelo propone una acción, el runtime llama al servidor, el servidor devuelve hechos o efectos permitidos, y el modelo continúa con contexto real. Es la misma idea que hay detrás de buenas APIs internas, pero orientada a runtimes de agentes.

## Cómo encaja Dailybot como integración orientada a MCP

Dailybot es **orquestación y visibilidad de equipo**: check-ins, standups, reportes de agentes y el **agent inbox**, donde las personas encolan instrucciones para agentes de código. En términos de MCP, lo valioso es que Dailybot actúa como una **superficie controlada** de **contexto organizacional**—quién está bloqueado, qué se reportó, qué pidieron los humanos que hiciera el agente a continuación—sin sustituir su control de versiones o su CI.

Cuando un **cliente compatible con MCP** puede alcanzar a Dailybot, los agentes pueden:

- **Reportar progreso** después de trabajo significativo (alineado con sus reglas de reporte), para que los timelines sigan siendo legibles para personas.
- **Obtener señales** sobre **estado del equipo** y **contexto derivado de check-ins** cuando la configuración del workspace lo permita—de modo que un agente pueda hacer preguntas operativas antes de reescribir una gran parte del código.
- **Participar en flujos bidireccionales**: actualizaciones salientes desde el agente, instrucciones entrantes desde personas a través de la misma capa de orquestación que ya usan en el chat.

Los nombres exactos de tools y resources evolucionan con el producto; después de conectar, tomen el **catálogo MCP en el cliente** como fuente de verdad. La idea general se mantiene: **Dailybot es donde el trabajo del agente se encuentra con la coordinación humana**.

## Requisitos previos

Antes de integrar:

1. **Cliente con soporte MCP** — Un runtime que pueda adjuntar servidores MCP (por ejemplo **Cursor**, **Claude Code** u otro entorno soportado).
2. **Acceso al workspace de Dailybot** — La cuenta de Dailybot de su organización, con permisos adecuados para leer contexto de equipo y enviar actualizaciones de agentes.
3. **Autenticación** — Típicamente **`dailybot login`** en configuraciones interactivas o **`DAILYBOT_API_KEY`** en automatización; sigan la política de seguridad para secretos en entornos de agentes.
4. **Identidad de agente** — Cuando su setup use agentes con nombre, alineen **`--name` en el CLI**, identidades de API y la configuración MCP para que los reportes y los ítems del inbox lleguen al actor correcto.

Si algo falla en silencio, revisen primero la autenticación y luego el alcance de proyecto u organización—la mayoría de los problemas son desajuste de identidad, no sintaxis de MCP.

## Configuración paso a paso (conceptual)

Cada cliente etiqueta los pasos distinto, pero la secuencia suele ser:

1. **Instalar el CLI de Dailybot** (o confirmar que el entorno ya lo tiene) y completar **login** o **API key**.
2. **Registrar o elegir la entrada del servidor MCP** de Dailybot en la configuración MCP de su cliente—a menudo un bloque JSON o una entrada de marketplace cuando Dailybot está **listado en registros MCP** para descubrimiento.
3. **Confirmar permisos** en Dailybot para que la identidad conectada pueda leer los resources esperados y enviar actualizaciones de agente cuando haga falta.
4. **Prueba de humo**: pidan al agente una operación **solo lectura** (por ejemplo resumir el estado reciente del equipo) antes de habilitar tools de escritura en flujos automáticos.
5. **Codificar salvaguardas** en el repositorio—reglas, skills o prompts—que indiquen **cuándo** llamar a Dailybot (después de trabajo sustancial, en horario definido o cuando se pida explícitamente), para que el feed mantenga buena señal.

Mantengan los secretos fuera de los prompts; usen variables de entorno y el almacén de secretos del cliente.

## Herramientas y resources que deben esperar

Los detalles de implementación cambian por versión, pero las categorías suelen incluir:

- **Tools de reporte** — Enviar actualizaciones estilo standup con campos estructurados opcionales (ítems completados, bloqueos, metadata como modelo y rama).
- **Resources de lectura** — Vistas curadas de **estado del equipo**, **resúmenes de check-in** o **contexto tipo inbox** para que el agente se alinee con lo que los humanos ya ven en Dailybot.
- **Descubrimiento** — El patrón list-tools / list-resources de MCP para que el modelo solo invoque capacidades que existan en su workspace.

Revisen siempre **qué puede escribir** una tool frente a **qué solo lee** antes de habilitarla en automatización desatendida.

## Casos de uso de ejemplo

**Antes de iniciar un refactor grande**, un agente consulta el **estado del equipo** mediante resources respaldados por MCP: bloqueos abiertos, prioridades del día anterior y notas del inbox de un tech lead. El plan del agente se apoya en restricciones reales en lugar de inventarlas.

**Después de completar un hito**, el mismo agente envía un **reporte de progreso** por el canal que su organización estandarizó (wrapper del CLI o llamada directa), con **`--milestone`** y **JSON** estructurado para entregables—para que liderazgo vea texto orientado a resultados, no rutas de archivos.

**Cuando el contexto del código parece atascado**, el agente verifica si hay **instrucciones humanas** en cola en Dailybot (flujos de inbox) y ajusta los siguientes pasos, reduciendo ida y vuelta entre terminal y chat.

## Seguridad y gobernanza

MCP no elimina la política; la **concentra**. Limiten qué servidores pueden adjuntar los agentes en repos de producción, roten **API keys** y auditen qué identidades pueden publicar en timelines compartidos. Prefieran **mínimo privilegio**: resources MCP de solo lectura para agentes exploratorios, tools de reporte solo donde el agente sea un actor de confianza.

Usado con intención, **Dailybot más MCP** hace que el trabajo del agente sea **legible** para las mismas personas que ya manejan standups y escalaciones— **una historia de orquestación** en lugar de un canal paralelo de IA.