DOMINICODE

Tag: MCP

  • Cómo optimizar Agentes y Skills en Claude Code para un mejor rendimiento

    Cómo optimizar Agentes y Skills en Claude Code para un mejor rendimiento

    entender Agentes vs Skills, en Claude code, trade-offs de los agentes, y los trade-offs de los modelos

    ¿Quieres que tu sistema con Claude deje de comportarse como un aprendiz despistado y empiece a trabajar como un equipo bien entrenado? entender Agentes vs Skills, en Claude code, trade-offs de los agentes, y los trade-offs de los modelos es el primer paso. No es filosofía; es diseño técnico que decide costes, latencia y confiabilidad.

    En una frase: una Skill es una herramienta; un Agente es quien decide cuándo y cómo usarla. En Claude Code (y en el Model Context Protocol) esa diferencia no es semántica: define el control flow, la observabilidad y la estrategia de modelo.

    Resumen rápido (lectores con prisa)

    Qué es: Skill = función stateless y determinista; Agente = sistema que orquesta Skills con loop de razonamiento.

    Cuándo usarlo: Skill para flujos deterministas; Agente para tareas multi-step y adaptativas.

    Por qué importa: determina latencia, coste, observabilidad y riesgo de loops.

    Cómo funciona (alto nivel): Agente observa, planifica, invoca Skills y verifica; Skills exponen APIs claras (MCP/HTTP).

    Tiempo estimado de lectura

    Tiempo estimado de lectura: 5 min

    Ideas clave

    • Skills son funciones deterministas y stateless; expónlas como APIs claras.
    • Agentes orquestan Skills y gestionan objetivo, memoria y reintentos.
    • Los agentes añaden latencia, coste e indeterminismo; requieren guardrails y observabilidad.
    • Elige modelo por trade-off: Haiku (rápido/barato), Sonnet (equilibrio), Opus (máxima calidad).
    • Patrón híbrido recomendado: router ligero → Skills directas → Agentes especializados → guardrails y tracing.

    Tabla de contenidos

    Introducción

    ¿Quieres que tu sistema con Claude deje de comportarse como un aprendiz despistado y empiece a trabajar como un equipo bien entrenado? entender Agentes vs Skills, en Claude code, trade-offs de los agentes, y los trade-offs de los modelos es el primer paso. No es filosofía; es diseño técnico que decide costes, latencia y confiabilidad.

    Agentes vs Skills: la distinción que evita catástrofes

    Skills = funciones puntuales, deterministas y stateless.

    Skills

    • readFile(path), runSQL(query), sendSlack(channel, text).
    • Implementadas como código tradicional (JS/Python) y expuestas al modelo con una firma clara (MCP/HTTP).
    • No razonan. Ejecutan.

    Agentes

    • Mantienen objetivo, memoria y loop de razonamiento (Observe → Plan → Act → Verify).
    • Un Agente puede invocar múltiples Skills, evaluar resultados, reintentar o escalar a humano.
    • En Claude Code, el Agente es la instancia del modelo que ejecuta el bucle y usa las Skills ofrecidas por el runtime.

    Técnicamente: Skills son APIs; Agentes son sistemas de control y decisión que consumen esas APIs.

    Por qué importa: trade-offs de los agentes

    Autonomía suena bien hasta que el Agente se vuelve caro o tóxico. Estos son los efectos prácticos que deberías medir.

    Latencia multiplicada

    Cada paso del bucle agrega llamadas al modelo y a Skills. Una tarea que toma 2s con una Skill directa puede tardar 15–30s con un Agente que valida y reintenta. Para workflows interactivos eso mata la UX.

    Riesgo de loops infinitos

    Si no limitas iteraciones o detectas patrones repetitivos, el Agente puede intentar la misma corrección 1000 veces. Resultado: facturas de API astronómicas y procesos bloqueados.

    Indeterminismo e idempotencia perdida

    Un Agente puede resolver la misma tarea de maneras distintas. Eso da flexibilidad ante casos abiertos, pero complica testing, CI/CD y auditoría. Necesitas validaciones basadas en propiedades (constraints) en lugar de resultados fijos.

    Observabilidad y debugging costosos

    Debuguear un flow agéntico exige trazas por cada llamada LLM ↔ Skill, snapshots de memoria y métricas de confianza. Sin esto, los fallos solo se detectan cuando el usuario se queja.

    Mitigaciones prácticas:

    • Limitar pasos y tiempo por tarea (timeouts cognitivos).
    • Implementar detección de retries repetidos y bloqueo.
    • Validación post-acción (tests automáticos, checksums, schema validation).
    • Escalada a humano cuando la confianza baja.

    Trade-offs de los modelos: elegir Sonnet, Haiku u Opus

    No todos los modelos sirven para todo. Aquí el criterio es coste versus capacidad de razonamiento.

    Claude 3.5 Sonnet — el equilibrio

    • Pros: razonamiento sólido, buen manejo de Tool Use y generación de código.
    • Contras: coste y latencia moderados.
    • Uso: cerebro del Agente para planificación y edición de código.

    Claude 3 Haiku — router / executor barato

    • Pros: rápido y barato.
    • Contras: menos capaz en razonamiento profundo; mayor riesgo de alucinación en tareas complejas.
    • Uso: clasificación, enrutamiento, pre-filtros, resumen rápido o conversión simple.

    Claude 3 Opus — máxima calidad (cuando el coste no importa)

    • Pros: razonamiento profundo y menor tasa de error en zero-shot.
    • Contras: latencia y coste altos.
    • Uso: análisis crítico donde la calidad es la prioridad absoluta.

    Arquitectura recomendada: híbrida. Usa Haiku como router inicial; Sonnet para agentes especializados; Opus solo en batches o tareas off-line costosas.

    Patrón de despliegue práctico (claude-code + MCP)

    1. Router (Haiku): decide si la petición necesita Skill directa o Agente Sonnet.

    2. Skill directa: ejecutar si el flujo es determinista (p. ej. ETL, queries, envíos).

    3. Agente Sonnet: para tareas multi-step (refactor, investigación, remediación).

    4. Guardrails: límites de iteración, chequeos de schema, registros de decisión.

    5. Observabilidad: tracing por etapa (LLM prompt/responses, llamadas Skill, costos).

    Para referencia del runtime y la integración con Skills revisa la documentación de Claude Code en el portal de Anthropic (y el repositorio de ejemplo).

    Criterio final para un Tech Lead

    Decide según tres preguntas:

    • ¿Es el flujo determinista? Usa una Skill.
    • ¿Requiere adaptación y varios pasos? Construye un Agente.
    • ¿Cuál es el SLA de latencia y el presupuesto de coste? Selecciona Haiku/Sonnet/Opus acorde al ROI.

    No es magia: es ingeniería de trade-offs. Un Agente bien diseñado reduce intervención humana y aumenta alcance, pero exige observabilidad, límites y selección cuidadosa de modelo. En Dominicode tratamos Agentes como infraestructura: medimos, protegemos y versionamos. Haz lo mismo y tu Claude Code dejará de improvisar y empezará a producir.

    Dominicode Labs

    Si trabajas con automatización, agentes o workflows, puedes encontrar recursos adicionales y experimentos en Dominicode Labs. Es un complemento práctico para aplicar patrones de despliegue, guardrails y observabilidad en proyectos reales.

    FAQ

    ¿Cuándo debería preferir una Skill sobre un Agente?

    Usa una Skill cuando el flujo sea determinista, idempotente y pueda representarse como una API con firma clara (por ejemplo ETL, consultas, envíos). Las Skills reducen latencia y coste y facilitan testing y CI/CD.

    ¿Cómo mitigo el riesgo de loops infinitos en un Agente?

    Implementa límites de iteración, timeouts cognitivos y detección de patrones de retry repetidos. Añade reglas que bloqueen acciones cuando se superan umbrales y escalamiento a humano cuando la confianza sea baja.

    ¿Qué observabilidad mínima necesito para un Agente en producción?

    Traza cada llamada LLM ↔ Skill, snapshots de memoria relevantes y métricas de confianza/decisión. Registra costos por etapa para analizar trade-offs de latencia y gasto.

    ¿Cómo selecciono entre Haiku, Sonnet y Opus?

    Elige según coste vs capacidad de razonamiento: Haiku para routing y tareas simples; Sonnet como cerebro del Agente para planificación y edición; Opus para análisis crítico donde la calidad justifica el coste.

    ¿Qué prácticas recomiendan para validar acciones de un Agente?

    Usa validación post-acción: tests automáticos, checksums y validación de esquema. Implementa constraints que verifiquen propiedades del resultado más que un valor exacto.

    ¿Debo versionar Skills y Agentes por separado?

    Sí. Trata Skills como infra y versiona sus APIs. Versiona Agentes por su política de decisión, prompts y memoria para poder reproducir y auditar comportamientos en producción.

  • Cómo crear un plugin para Anthropic Claude usando MCP

    Cómo crear un plugin para Anthropic Claude usando MCP

    Crear tu primer plugin para Anthropic Claude (Claude Code)

    Crear tu primer plugin para Anthropic Claude (Claude Code) no es magia. Es arquitectura. En vez de «pegar texto en el prompt», vas a exponer funciones ejecutables que Claude puede invocar como herramientas reales. Aquí tienes una guía práctica, técnica y directa para hacerlo funcionar en minutos.

    Tiempo estimado de lectura: 5 min

    • Convierte prompts en herramientas: expón funciones (tools) que Claude invoca mediante MCP en lugar de meter contexto en el prompt.
    • Implementa un servidor MCP: el servidor genera schemas automáticamente y maneja llamadas desde Claude (ej.: FastMCP en Python).
    • Seguridad y fiabilidad: docstrings claros, timeouts, manejo de errores y principio de menor privilegio son imprescindibles.
    • Observabilidad y versionado: registra llamadas, latencias y versiona schemas para evitar rupturas en producción.
    • Integración: estas tools pueden orquestarse en n8n u otros workflows como nodos reutilizables.

    Introducción

    Un “plugin” en Claude es, en realidad, Tool Use o Function Calling via Model Context Protocol (MCP). No le estás metiendo código al modelo: le das una API estructurada y el modelo decide cuándo llamarla. Tu servidor ejecuta la lógica real (Python/TS/Go) y el modelo actúa como cliente que conoce las herramientas disponibles mediante un schema.

    Resumen rápido (lectores con prisa)

    Qué es: Exponer funciones ejecutables (tools) que Claude puede invocar vía MCP.

    Cuándo usarlo: Cuando necesites que el asistente consulte sistemas externos, ejecute acciones o maneje datos sin inflar el prompt.

    Por qué importa: Permite acciones deterministas, auditables y seguras desde un asistente LLM.

    Cómo funciona: El modelo selecciona una tool, genera parámetros según el schema y llama al servidor MCP; el servidor responde con texto estructurado.

    ¿Qué es un “plugin” en Claude?

    Conceptualmente:

    • Claude = cliente que conoce las herramientas disponibles mediante un schema.
    • MCP = protocolo que negocia llamadas entre Claude y tu servicio (stdio, HTTP, WebSocket).
    • Tu servidor = el plugin: código real que ejecuta la lógica (Python/TS/Go).

    No le estás metiendo código al modelo. Le das una API estructurada y el modelo decide cuándo llamarla.

    ¿Qué necesitas y por qué importa?

    ¿Por qué hacerlo? Porque así conviertes un asistente en un agente capaz de:

    • consultar bases de datos internas,
    • ejecutar comprobaciones de infra,
    • automatizar workflows en n8n,

    sin inundar el prompt con contexto ni exponer credenciales en texto.

    Requisitos mínimos:

    Código mínimo: servidor MCP en Python

    Este ejemplo expone una tool que verifica el estado HTTP de una URL usando FastMCP. Copia, ajusta y ejecuta.

    from mcp.server.fastmcp import FastMCP
import httpx

mcp = FastMCP("WebChecker")

@mcp.tool()
async def check_website_status(url: str) -> str:
    """
    Verifica el estado HTTP de una URL.
    Args:
      url: URL completa (ej: https://dominicode.com)
    Returns:
      Mensaje con código y razón, o error legible.
    """
    try:
        async with httpx.AsyncClient(timeout=5.0) as client:
            r = await client.get(url, follow_redirects=True)
            return f"Status: {r.status_code} - {r.reason_phrase}"
    except Exception as e:
        return f"Error: {str(e)}"

if __name__ == "__main__":
    mcp.run()

    FastMCP genera automáticamente el schema de la tool a partir de los type hints y docstrings. No escribes JSON a mano.

    Registrar el plugin en Claude Desktop / CLI

    Para que Claude vea tu servidor local, añade una entrada en la configuración de Claude Desktop:

    – macOS/Linux: ~/Library/Application Support/Claude/claude_desktop_config.json
    – Windows: %APPDATA%\Claude\claude_desktop_config.json

    Ejemplo:

    {
  "mcpServers": {
    "web-checker": {
      "command": "python",
      "args": ["/ruta/absoluta/a/server.py"]
    }
  }
}

    Reinicia Claude. Deberías ver el servidor activo (icono de enchufe).

    Flujo de ejecución (Thinking Loop)

    Cuando pides: “Claude, comprueba si dominicode.com responde”, sucede:

    1. Claude detecta necesidad de herramienta.
    2. Selecciona check_website_status.
    3. Genera parámetros (url).
    4. Llama al plugin vía MCP.
    5. El plugin responde con texto estructurado.
    6. Claude formatea la respuesta humana.

    Todo ordenado, trazable y auditable.

    Buenas prácticas imprescindibles

    Docstrings son contratos

    Escribe docstrings claros. El modelo usa esa información para construir la llamada. Ambigüedad = invocación errónea.

    Errores controlados

    Nunca dejes que tu plugin haga crash. Captura excepciones y devuelve mensajes legibles. Si tu proceso muere, Claude pierde acceso a todo ese servidor.

    Timeouts defensivos

    Usa timeouts explícitos (ej. httpx timeout=5s). No querrás procesos colgados.

    Principio de menor privilegio

    No implementes tools como exec_shell(cmd) a la ligera. Restringe rutas, usuarios y operaciones. Si necesitas ejecutar comandos, envuelve y valida cada input.

    Observabilidad

    Loguea prompts recibidos, respuestas, latencias y costes. Traza cada call LLM ↔ tool. Para infra, añade métricas que permitan alertas (ERRORES, RETRIES, LATENCIA).

    Gestión de versiones

    Versiona schemas y tools. Cambiar la firma de una función sin versionado rompe agentes y workflows en producción.

    Escalada humana

    Si el agente entra en loop o baja de confianza, define una regla clara: cortar, crear ticket y notificar a un responsable.

    Integración con workflows y n8n

    Estas tools son bloques reutilizables. Úsalas como nodos en n8n o como pasos en un orquestador de agentes. Por ejemplo:

    • Nodo n8n invoca tu API plugin para obtener estado.
    • Resultado condicional dispara un PR automático o un Slack alert.

    Recursos y lectura adicional

    Cierre operativo

    Crear un plugin para Claude Code es convertir una idea en una API que el modelo puede invocar de forma determinista. No es magia; es ingeniería de interfaces. Empieza con una tool pequeña, aplícala en un workflow y añade observabilidad. Si lo haces bien, tu Claude dejará de hablar y empezará a actuar.

    Esto no acaba aquí: construye la siguiente tool, versiona el schema y orquesta esas tools con un agente. Tu siguiente despliegue será la prueba.

    Dominicode Labs

    Si quieres prototipar y validar pipelines de agentes y automatizaciones, revisa Dominicode Labs. Es una continuación natural para integrar tools, pruebas y orquestación en entornos de trabajo técnico.

    FAQ

    ¿Qué diferencia hay entre un plugin y poner contexto en el prompt?

    Un plugin expone funciones ejecutables con schemas; el modelo invoca esas funciones. Poner contexto en el prompt implica enviar datos y lógica de forma textual, sin capacidad de ejecución externa ni trazabilidad.

    ¿Qué es MCP?

    MCP (Model Context Protocol) es el protocolo que negocia llamadas entre el modelo y tu servicio (stdio, HTTP, WebSocket), permitiendo que el modelo conozca y llame herramientas.

    ¿Por qué usar docstrings en lugar de JSON manual?

    Frameworks como FastMCP generan schemas automáticamente a partir de type hints y docstrings, reduciendo errores y manteniendo documentación y contratos sincronizados.

    ¿Cómo manejo errores para que Claude no pierda acceso?

    Captura excepciones, devuelve mensajes legibles y usa timeouts defensivos. No permitas que el proceso principal haga crash; implementa reinicios supervisados y health checks.

    ¿Qué precauciones de seguridad debo tomar?

    Aplica principio de menor privilegio, valida y sanitiza inputs, restringe rutas y comandos, y evita exponer credenciales en texto plano.

    ¿Puedo integrar estas tools en n8n?

    Sí. Usa las tools como nodos o llamadas API desde n8n; el resultado puede condicionar flujos, crear PRs o enviar alertas en Slack.

  • Implementa Amazon Ads MCP Server para optimizar integraciones publicitarias

    Implementa Amazon Ads MCP Server para optimizar integraciones publicitarias

    Pero, ¿qué es Amazon Ads MCP Server?

    Tiempo estimado de lectura: 4 min

    Ideas clave

    • Amazon Ads MCP Server actúa como middleware MCP para exponer la API de Amazon Advertising como herramientas consumibles por agentes IA.
    • Reduce integraciones punto a punto: traduce prompts/llamadas MCP a REST de Amazon con OAuth.
    • Ofrece lectura de estructura, reportes KPI, operaciones CRUD y gestión de pujas (según permisos).
    • Riesgos: latencia, rate limiting, seguridad y alucinaciones operativas del LLM.
    • Flujo recomendado: levantar en testing, comenzar con solo lectura y añadir guardrails para escrituras.
    Pero, ¿qué es Amazon Ads MCP Server? Es la pregunta que están haciendo hoy los equipos que quieren dejar de pelearse con APIs, scripts rotos y automatizaciones que fallan en producción. Aquí tienes una respuesta técnica, práctica y sin ruido.

    Amazon Ads MCP Server es una implementación de middleware que sigue el estándar Model Context Protocol (MCP). Su propósito: exponer la funcionalidad de la API de Amazon Advertising como “herramientas” que un agente de IA (un LLM) puede descubrir e invocar de forma segura y estructurada. En lugar de tener múltiples integraciones punto a punto, tienes una capa de traducción que convierte prompts en llamadas API consistentes.

    Resumen rápido (lectores con prisa)

    Qué es: Un middleware MCP que expone la API de Amazon Advertising como herramientas JSON-RPC para agentes IA.

    Cuándo usarlo: Cuando quieres que un LLM ejecute consultas y acciones sobre advertising-api.amazon.com sin integrar cada endpoint manualmente.

    Por qué importa: Reduce deuda técnica, centraliza permisos y disminuye alucinaciones operativas del LLM.

    Cómo funciona: Cliente MCP → JSON-RPC → MCP Server → REST Amazon (con OAuth) → respuesta JSON al LLM.

    Pero, ¿qué es Amazon Ads MCP Server? — definición técnica y flujo

    Técnicamente, es un servidor que ofrece primitivas MCP (tools, resources) vía JSON-RPC para que un cliente MCP —Claude Desktop, un agente custom o un orquestador tipo n8n con adaptador— hable con advertising-api.amazon.com.

    Flujo resumido

    • Usuario: “Analiza ROAS de las campañas de zapatillas, última semana.”
    • LLM: decide qué herramienta usar (ej. get_campaign_metrics).
    • Cliente MCP: envía la solicitud JSON-RPC al MCP Server.
    • MCP Server: traduce la llamada a la REST de Amazon, añade OAuth (Bearer token), ejecuta y devuelve JSON.
    • LLM: interpreta y genera respuesta o acción.

    Documentación oficial: Documentación oficial

    Anuncio de beta: Anuncio de beta

    Qué expone y para qué sirve (capabilities)

    Una implementación típica ofrece:

    • Lectura de estructura: cuentas, portafolios, campañas, ad groups.
    • Reportes KPI: impresiones, clics, costo, ventas, ROAS, ACOS con filtros temporales.
    • Operaciones CRUD: crear/actualizar campañas y grupos de anuncios.
    • Gestión de pujas y presupuestos (si se habilitan permisos de escritura).
    • Endpoints de facturación y perfil.

    Eso permite que un agente haga tareas de alto valor: detectar anomalías, reequilibrar presupuestos, ejecutar reglas de puja o generar reportes complejos con un único prompt.

    ¿Por qué te importa como equipo técnico?

    Porque cambia el coste de propiedad de una integración. En lugar de mantener docenas de scripts que se rompen cuando Amazon cambia un endpoint, mantienes una capa estable que define qué herramientas están disponibles y cómo usarlas. Ventajas prácticas:

    • Menor deuda técnica.
    • Integración agnóstica del LLM: funciona con Claude, ChatGPT u otros que implementen MCP.
    • Menos alucinaciones: el LLM opera sobre herramientas y metadatos claros.

    Requisitos y ejemplo mínimo de configuración

    Necesitas:

    • Cuenta de desarrollador Amazon Ads y una app registrada.
    • Credenciales OAuth: CLIENT_ID, CLIENT_SECRET, REFRESH_TOKEN, PROFILE_ID.
    • Entorno Node.js (v18+) o Python 3.10+ para ejecutar el servidor.

    Ejemplo mínimo (configuración cliente MCP)

    {
  "mcpServers": {
    "amazon-ads-service": {
      "command": "node",
      "args": ["./dist/index.js"],
      "env": {
        "AMAZON_CLIENT_ID": "amzn1.application-oa2-client...",
        "AMAZON_CLIENT_SECRET": "tu_secreto",
        "AMAZON_REFRESH_TOKEN": "tu_refresh_token",
        "AMAZON_PROFILE_ID": "1234567890"
      }
    }
  }
}

    (El JSON anterior es un trozo de config real que usan clientes como Claude Desktop para lanzar servidores MCP locales.)

    Limitaciones y riesgos que no puedes ignorar

    Esto no es magia. Considera:

    • Latencia: LLM → MCP → API añade retraso. No esperes microsegundos en operaciones complejas.
    • Rate limiting: Amazon impone límites estrictos. Un agente en bucle puede provocar throttling y bloqueos.
    • Seguridad: dar permiso de escritura es peligroso. Audita el código del MCP Server antes de poner credenciales en producción.
    • Alucinaciones operativas: el MCP reduce errores, pero el LLM todavía puede elegir parámetros inadecuados si la especificación de la herramienta es ambigua.
    • Ecosistema joven: muchas librerías y ejemplos están en alpha; prueba y versiona con cuidado.

    Cómo empezar hoy (práctico)

    1. Registra la app en Amazon Advertising y obtén tus credenciales OAuth.
    2. Levanta un MCP Server en un entorno de testing (local o staging).
    3. Conecta tu cliente MCP (Claude Desktop, agente propio o n8n con adaptador).
    4. Ejecuta prompts de solo lectura primero (reportes, métricas).
    5. Añade controles para escrituras: validaciones, límites de cambio y un modo “simulación” antes de aplicar pujas reales.

    Documentación recomendada: Documentación recomendada

    Anuncio y guía inicial: Anuncio y guía inicial

    Conclusión breve

    Amazon Ads MCP Server es la infraestructura que permite a los agentes de IA operar sobre tu stack publicitario con menos fricción y más contexto. No es la bala de plata, pero sí la base para construir agentes de supervisión que detecten anomalías, propongan optimizaciones y, cuando esté permitido, las ejecuten bajo reglas guardadas.

    Empieza en testing, audita todo, y deja que el agente haga lo repetitivo. Lo inteligente —lo que realmente crea ventaja— es diseñar las reglas y guardrails; el resto lo ejecuta la máquina. En el próximo artículo mostraremos un ejemplo práctico conectando MCP Server con n8n y Claude para automatizar una regla de puja segura.

    Puedes profundizar en experimentos y guías prácticas relacionadas con automatización y agentes en Dominicode Labs. Es una continuación lógica para equipos que quieran prototipar flujos MCP y automatizaciones seguras.

    FAQ

    Respuesta

    Amazon Ads MCP Server es un servidor middleware que implementa el estándar MCP para exponer la funcionalidad de la API de Amazon Advertising como herramientas consumibles vía JSON-RPC por clientes MCP y agentes IA.

    Respuesta

    Reduce la deuda técnica al centralizar traducciones y autenticación (OAuth). Evita mantener múltiples scripts frente a cambios de endpoint y define un conjunto claro de herramientas para el LLM.

    Respuesta

    Latencia adicional, riesgo de throttling por rate limits, seguridad de credenciales y posibles alucinaciones operativas del LLM si las herramientas no están bien especificadas.

    Respuesta

    Sí, se pueden habilitar escrituras, pero es de alto riesgo. Audita el código, añade validaciones y pruebas, y usa modos de simulación antes de permitir cambios reales.

    Respuesta

    Necesitas una cuenta de desarrollador Amazon Ads, una app registrada y credenciales OAuth (CLIENT_ID, CLIENT_SECRET, REFRESH_TOKEN, PROFILE_ID). Además, un entorno Node.js (v18+) o Python 3.10+ para ejecutar el servidor.

    Respuesta

    Implementa backoff y límites en el agente, monitoriza llamadas y prueba en staging. Evita bucles automáticos que multipliquen peticiones sin control.

    Respuesta

    Clientes como Claude Desktop, agentes custom y orquestadores tipo n8n con adaptador pueden comunicarse vía MCP con el servidor.

    Respuesta

    Consulta la Documentación oficial y el Anuncio de beta para guías y noticias.

  • A2A y MCP para sistemas de agentes

    A2A y MCP para sistemas de agentes

    Procesa todo el contenido proveniente de # A2A vs MCP: cómo elegir y cómo combinarlos en sistemas de agentes

    Tiempo estimado de lectura: 8 min

    • A2A (Agent-to-Agent) y MCP (Model Context Protocol) operan en capas distintas.
    • MCP es un protocolo abierto para exponer datos y herramientas a modelos de lenguaje.
    • A2A es un patrón arquitectónico donde varios agentes colaboran para resolver problemas.
    • Sistemas robustos usan MCP para capacidades y A2A para coordinación.
    • Dominicode Labs ofrece un entorno para prototipar agentes y sistemas.

    Tabla de contenidos

    A2A vs MCP — qué es cada cosa y por qué importa

    MCP (Model Context Protocol) es un protocolo abierto para exponer datos y herramientas a modelos de lenguaje de forma estandarizada. Piensa en MCP como el enchufe universal: un servidor MCP puede dar acceso a archivos, bases de datos o funciones accionables y cualquier cliente compatible puede usarlos sin reescribir integraciones. Ver especificación: https://github.com/anthropic/mcp

    A2A (Agent-to-Agent) es un patrón arquitectónico: varios agentes especializados se comunican, se delegan tareas y colaboran para resolver problemas complejos. No es un estándar único; es una topología. Un A2A sano define roles (planner, worker, auditor) y contratos de mensaje entre agentes.

    Resumen rápido:

    • MCP = plumbing (conectar modelos con recursos).
    • A2A = orchestration (cómo se organizan y comunican múltiples agentes).

    Por qué no es “uno u otro”

    El error común es pensar que hay que elegir. Los sistemas robustos usan MCP para exponer capacidades y A2A para coordinar quién hace qué. En un flujo real:

    1. Un agente de orquestación decide la estrategia.
    2. Un agente especialista solicita datos o ejecuta acciones mediante MCP.
    3. Otro agente valida resultados y reporta estado a la orquestación.

    Si usas MCP sin A2A, tus agentes serán clientes puntuales de recursos, pero la lógica de delegación seguirá centralizada y difícil de escalar. Si usas A2A sin MCP, cada agente mantiene su propio “pegamento” a APIs —duplicación y deuda técnica.

    Casos de uso y patrón de adopción

    Cuando debes priorizar MCP:

    • Necesitas reutilizar integraciones entre múltiples modelos o clientes.
    • Buscas limitar la superficie de exposición de datos con un contrato claro.
    • Quieres intercambiar el modelo subyacente sin rehacer conectores.

    Implementación: desarrolla servidores MCP para tu CRM, logs, y repositorios; usan el mismo protocolo para exponer endpoints que cualquier agente puede consumir. MCP docs: https://github.com/anthropic/mcp

    Cuando debes priorizar A2A:

    • La tarea se fragmenta en roles distintos (investigador, executor, revisor).
    • Requieres resiliencia y substitución dinámica de agentes.
    • Necesitas auditoría y checkpoints entre pasos.

    Implementación típica: usa un bus de mensajes (Kafka, NATS) o colas (RabbitMQ) y define contratos de mensaje JSON entre agentes. Complementa con monitoreo y circuit breakers para evitar bucles.

    Arquitectura recomendada: ejemplo práctico

    Caso: sistema de atención al cliente automatizado.

    • Capa MCP: servidores MCP para CRM (Postgres), logs y sistema de tickets (Jira). Estos exponen operaciones estándar (read, search, create_ticket).
    • URL de referencia MCP: https://github.com/anthropic/mcp
    • Capa A2A: agentes con roles:
      • Triaje (recibe la petición).
      • Diagnóstico (consulta logs vía MCP).
      • Remediación (lanza actions vía MCP o crea tickets).
      • Auditor (valida y marca completado).
    • Comunicación interna A2A: mensajes en un bus con eventos tipados (request_id, step, payload, status).
    • Observabilidad: trazabilidad por request_id y checkpoints.

    Resultado: cada agente reutiliza los mismos conectores MCP; la orquestación A2A permite reintentos, paralelismo y supervisión.

    Riesgos y trampas a evitar

    • No diseñes agentes monolíticos que llamen a todo: terminas con “llamadas spaghetti” y hardcoding de APIs.
    • No expongas datos sensibles sin control: MCP facilita estandarizar límites de contexto y scopes.
    • Evita ciclos A2A sin límite: siempre modela timeouts, retries y un agente “guardian” que cancele loops.

    Operacionalización y gobernanza

    Para escalar necesitas:

    • Contratos versionados (MCP schema + mensaje A2A).
    • Telemetría por request_id, latencias y tasas de error.
    • Políticas de seguridad en handshake MCP (auth tokens, scopes).
    • Simulaciones unitarias: tests de integración donde agentes reales llaman servidores MCP simulados.

    LangChain y otros frameworks ofrecen patrones de agentes y orquestación que pueden guiar el diseño A2A: https://python.langchain.com/en/latest/modules/agents/

    Dominicode Labs: dónde prototipar y validar decisiones

    Si estás evaluando el trade-off entre A2A y MCP en un caso real, hay que pasar del diagrama a la ejecución. Dominicode Labs es un entorno pensado para eso: prototipado de agentes, servidores MCP y pipelines con n8n o sistemas de colas. En el Lab validamos prompts, contratos MCP y patterns A2A con observabilidad y tests reproducibles.

    Qué puedes lograr en el Lab:

    • Implementar un servidor MCP que exponga tu CRM de forma segura.
    • Desplegar un conjunto de agentes A2A que ejecuten flujos (triaje → diagnóstico → remediación).
    • Medir latencia, tasas de error y costes por request.

    Conclusión práctica

    A2A vs MCP no es una pelea; es una colaboración. Usa MCP para estandarizar acceso a capacidades y evita replicar conectores. Usa A2A para distribuir responsabilidad, escalar trabajos complejos y añadir gobernanza. Diseña con ambos en mente y valida rápido: si no puedes ejecutar la orquestación con monitoreo y tests, la arquitectura será solo teoría.

    FAQ

    ¿Qué es A2A?

    A2A (Agent-to-Agent) es un patrón arquitectónico donde numerosos agentes colaboran, se delegan tareas y se comunican para resolver problemas complejos.

    ¿Qué es MCP?

    MCP (Model Context Protocol) es un protocolo abierto que permite la exposición estandarizada de datos y herramientas a modelos de lenguaje.

    ¿Por qué usar MCP?

    Usar MCP permite reutilizar integraciones entre modelos, limitar la exposición de datos y facilitar el intercambio de modelos subyacentes sin tener que rehacer conectores.

    ¿Por qué usar A2A?

    Usar A2A permite delegar responsabilidades entre roles distintos, asegurar resiliencia y realizar auditorías en los procesos.

    ¿Qué patrones existen en el uso de A2A y MCP?

    Existen patrones como el uso de servidores MCP en la capa de datos, combinados con A2A para la orquestación y la logística de los procesos.

  • ¿Qué es un MCP? (Model Context Protocol) explicado para developers

    ¿Qué es un MCP? (Model Context Protocol) explicado para developers

    ¿Qué es un MCP? (Model Context Protocol) explicado para developers

    Tiempo estimado de lectura: 7 min

    • Definición técnica y utilidad del MCP.
    • Arquitectura y componentes básicos del MCP.
    • Problemas reales que el MCP busca resolver.
    • Beneficios de la implementación de MCP en proyectos.
    • Riesgos y pautas de uso de MCP.

    Introducción

    Qué es un MCP? Si trabajas con IA aplicada, agentes o automatización, es probable que ya te hayas encontrado con el problema real: los modelos LLM “razonan” bien, pero no tienen acceso nativo y seguro a tus herramientas (bases de datos, CRMs, repos, APIs internas) ni un estándar consistente para hacerlo. MCP (Model Context Protocol) aparece precisamente para ordenar ese caos: define un protocolo para que una app (cliente) conecte modelos con herramientas y contexto externo de forma estructurada.

    En este artículo vas a entender qué es un MCP, cómo se compone (cliente/host/servidor), qué resuelve frente a integraciones ad-hoc, riesgos reales (seguridad, prompt injection) y un criterio práctico para decidir si te conviene.

    Fuentes (URLs) para ampliar y citar:

    Qué es un MCP? Definición técnica sin hype

    MCP (Model Context Protocol) es un protocolo estándar para conectar aplicaciones que ejecutan o orquestan LLMs (clientes/hosts) con servidores de contexto (MCP servers) que exponen:

    • Tools (acciones): llamadas a funciones / capacidades externas (por ejemplo, “crear issue en Jira”, “consultar clientes en HubSpot”, “leer un fichero del repo”, “ejecutar una query parametrizada”).
    • Resources (recursos): contexto recuperable (documentos, ficheros, páginas internas, resultados de búsqueda interna, catálogos, etc.).
    • Prompts (plantillas): prompts reutilizables y versionables para tareas frecuentes, con inputs definidos.

    La idea central: en vez de integrar cada herramienta “a mano” con prompts frágiles y wrappers propietarios, MCP propone un contrato para que un cliente pueda descubrir capacidades (“qué herramientas hay”, “qué inputs requieren”) y ejecutarlas con un flujo consistente.

    Si estás pensando “esto suena a function calling”, vas bien: MCP se relaciona, pero la diferencia clave es el nivel de estandarización e interoperabilidad entre herramientas y clientes, y el foco en “contexto + tools” como primera clase.

    El problema real que MCP intenta resolver

    En producción, integrar un LLM con sistemas reales suele fallar por razones muy poco glamourosas:

    1. Cada integración es un snowflake
      Un wrapper para GitHub, otro para Slack, otro para DBs, cada uno con su formato, auth y errores.
    2. El contexto es un patchwork
      Unas cosas se meten en el prompt, otras se recuperan con RAG, otras con function calls… y el modelo termina con información parcial o contradictoria.
    3. La superficie de seguridad crece sin control
      Tokens por todos lados, permisos excesivos, falta de auditoría, y riesgo de prompt injection al mezclar texto no confiable con instrucciones.
    4. Difícil de mantener y versionar
      Cuando una herramienta cambia (schema, endpoint, permisos), se rompe el agente; nadie sabe dónde.

    MCP intenta dar una respuesta “de ingeniería”: un protocolo para que el acceso a herramientas y contexto sea descubrible, tipado/estructurado, y más fácil de gobernar.

    Arquitectura MCP: host, client y server (y qué hace cada uno)

    La terminología exacta puede variar según la documentación, pero el modelo mental útil es:

    1) Host (aplicación “contenedora”)

    Es la aplicación donde vive la experiencia: un IDE, un chat interno, un agente de soporte, un copiloto para operaciones, etc. Ejemplos típicos en el ecosistema: apps tipo “Claude Desktop” o un IDE plugin (según integraciones del momento).

    2) MCP Client (el conector desde el host)

    El cliente MCP es quien:

    • Se conecta a uno o varios MCP servers.
    • Descubre “qué ofrecen” (tools/resources/prompts).
    • Presenta esas capacidades al modelo (o al runtime del agente).
    • Ejecuta llamadas a tools y gestiona respuestas.

    3) MCP Server (expositor de capacidades)

    Un MCP server es un proceso/servicio que expone un conjunto de herramientas y contexto, normalmente asociado a un sistema o dominio:

    • “mcp-github”: issues, PRs, commits
    • “mcp-slack”: canales, mensajes, posting
    • “mcp-postgres”: queries parametrizadas, introspección acotada
    • “mcp-filesystem”: lectura controlada de rutas

    El punto importante: no estás “dando Internet” al modelo. Estás dando herramientas específicas con inputs acotados y (idealmente) permisos mínimos.

    Qué expone MCP exactamente: Tools, Resources y Prompts

    Tools: acciones ejecutables (con contrato)

    Una tool es una función invocable por el cliente, con:

    • nombre estable
    • descripción
    • esquema de parámetros (típicamente JSON Schema o equivalente)
    • salida estructurada

    Esto reduce el típico “haz una request a X” en lenguaje natural y lo reemplaza por un contrato explícito.

    Ejemplo conceptual (simplificado):

    tool: create_jira_ticket
    input: { "projectKey": "OPS", "summary": "...", "description": "...", "priority": "P2" }
    output: { "issueKey": "OPS-1234", "url": "..." }

    Resources: contexto recuperable con identificadores

    Resources son “cosas que puedes leer” de forma controlada:

    • un doc interno
    • un fichero del repo
    • un runbook
    • una página de Confluence
    • un resultado de búsqueda interna

    Lo importante es que el recurso se referencia (ID/URI) y se recupera vía el server, no pegando texto arbitrario en el prompt sin trazabilidad.

    Prompts: plantillas versionables

    Para equipos, esto importa más de lo que parece:

    • Prompts con inputs definidos
    • Versionado
    • Reutilización por múltiples agentes/hosts
    • Menos dependencia del “prompt mágico” local

    Cómo encaja MCP con RAG, function calling y agentes

    MCP no “reemplaza” RAG ni el function calling; los organiza.

    RAG (Retrieval Augmented Generation): se centra en recuperar texto relevante desde un corpus (vector DB, búsqueda semántica). MCP puede exponer ese retrieval como resource o tool (“search_docs”, “get_doc_by_id”).

    Function calling: muchos modelos ya soportan llamadas a herramientas. MCP define cómo describir y ejecutar herramientas de forma estandarizada a través de servidores.

    Agentes: un agente es un loop (plan → act → observe) con memoria, herramientas y políticas. MCP es una forma de inyectar herramientas/contexto de manera mantenible.

    Criterio: si tu problema es “el modelo no tiene el contexto correcto”, RAG puede bastar. Si tu problema es “necesito acciones seguras y auditables en sistemas reales”, MCP se vuelve mucho más relevante.

    Beneficios reales (cuando compensa)

    1) Interoperabilidad y reutilización

    Un MCP server para un sistema (por ejemplo, GitHub) puede ser consumido por múltiples hosts/clientes sin reescribir integraciones.

    2) Contratos explícitos

    Al tener esquemas de entrada/salida:

    • baja la ambigüedad
    • mejora la validación
    • facilitas testing
    • reduces “prompt glue code”

    3) Gobernanza y permisos más claros

    Si lo implementas bien, puedes:

    • limitar qué tools existen
    • limitar qué acciones pueden ejecutar
    • auditar invocaciones
    • rotar credenciales por servidor/entorno

    4) Menos “caja negra” en producción

    MCP te fuerza (en el buen sentido) a diseñar capacidades como API internas, no como frases en un prompt.

    Riesgos y anti-patrones: lo que se rompe en producción

    Prompt injection sigue existiendo (solo cambia el campo de batalla)

    Si tu MCP server expone tools potentes y el modelo consume texto no confiable (emails, tickets, webs), es posible que el modelo sea inducido a llamar tools de forma peligrosa.

    Mitigaciones típicas:

    • allowlists de tools por workflow
    • scopes por identidad/entorno
    • human-in-the-loop para acciones críticas (pagos, borrados, cambios de permisos)
    • sanitización y separación estricta entre “instrucciones del sistema” y “datos externos”
    • políticas: “nunca ejecutes tool X sin confirmación explícita”

    Herramientas demasiado genéricas = superficie de ataque enorme

    Anti-patrón clásico: exponer una tool tipo run_sql(query: string) sin constraints. Mejor: tools específicas y parametrizadas:

    • get_customer_by_id(customerId)
    • list_invoices(customerId, fromDate, toDate)
    • create_refund(invoiceId, reasonCode) (con límites)

    Observabilidad insuficiente

    Si no logueas:

    • inputs/outputs (con redacción/PII handling)
    • tiempos
    • errores
    • decisión del agente (“por qué llamó a esta tool”)

    …vas a sufrir en debugging y en compliance.

    Coste de mantenimiento

    MCP no elimina trabajo: lo desplaza. Ahora mantienes servidores MCP con sus versiones, auth, despliegue y SLAs. Compensa cuando hay reutilización y valor real.

    Cuándo usar MCP (y cuándo NO): criterio senior

    Usa MCP si:

    • Estás construyendo agentes o copilotos internos que requieren acciones en herramientas reales.
    • Tienes varias integraciones y quieres estandarizar (evitar N wrappers por host).
    • Tu equipo necesita gobernanza (permisos, auditoría, versionado).
    • Quieres separar responsabilidades: el equipo de plataforma mantiene servers; los equipos de producto consumen capacidades.

    No uses MCP (todavía) si:

    • Solo necesitas responder preguntas con documentación: con RAG bien hecho suele bastar.
    • Tienes un caso único y pequeño: una integración directa puede ser más simple.
    • No puedes dedicar esfuerzo a seguridad/observabilidad: MCP sin disciplina puede ser peor que un sistema cerrado.

    Ejemplo práctico: “agente de soporte” con MCP (sin fantasía)

    Caso: soporte B2B técnico. Quieres que el agente:

    1. lea el ticket
    2. consulte estado del cliente en CRM
    3. revise errores recientes en logs
    4. proponga respuesta y, si procede, abra un issue

    Con MCP, lo razonable es:

    • MCP server “crm”: get_account(accountId), list_open_cases(accountId)
    • MCP server “logs”: search_errors(service, timeframe, query) (acotado)
    • MCP server “github/jira”: create_issue(...)

    El host (tu app) define políticas:

    • solo herramientas permitidas en modo “draft”
    • create_issue requiere confirmación humana
    • respuestas siempre citan resource IDs usados

    Resultado: menos “magia”, más sistema.

    MCP y automatización: cómo encaja con n8n y workflows

    Si ya automatizas con n8n, MCP encaja como una capa adicional cuando introduces LLMs y agentes:

    • n8n es excelente orquestando flujos deterministas (triggers, transformaciones, integraciones).
    • MCP estandariza cómo un modelo accede a herramientas/contexto.

    Un patrón realista:

    • n8n orquesta eventos (nuevo lead, ticket, alerta).
    • El LLM decide qué hacer y llama herramientas expuestas vía MCP.
    • n8n ejecuta tareas “de backoffice” y deja trazabilidad.

    En muchos equipos, el LLM no debería tener acceso directo a todo. n8n puede actuar como “capa de control” (rate limits, approvals, logs), mientras MCP estructura las capacidades.

    Si estás construyendo este tipo de sistemas (agentes que ejecutan trabajo real, no demos), tiene sentido apoyarte en un equipo que lo haya implementado en producción. En Dominicode Labs trabajamos precisamente en automatización e IA aplicada con criterio, incluyendo diseño de workflows con n8n, integración segura de herramientas, y construcción de agentes con gobernanza (permisos, observabilidad, despliegue).

    Checklist de implementación (pragmático) antes de adoptar MCP

    1. Define el catálogo de tools mínimo
      5–15 tools bien diseñadas ganan a 200 genéricas.
    2. Modela permisos y entornos
      dev/staging/prod separados; scopes por identidad (quién invoca qué)
    3. Diseña outputs estructurados
      evita respuestas “texto libre” cuando esperas datos.
    4. Añade observabilidad desde el día 1
      correlation IDs por ejecución, logs redactados, métricas de latencia y ratio de error por tool.
    5. Plan de seguridad
      confirmación humana para acciones irreversibles, allowlists por workflow, límites (rate limiting, timeouts).
    6. Estrategia de fallback
      qué ocurre si una tool falla, circuit breakers, respuestas parciales con trazabilidad.

    Conclusión: MCP como estándar útil, no como bala de plata

    Qué es un MCP? Es un protocolo para conectar modelos con contexto y herramientas de manera estandarizada, con mejores contratos y potencial de gobernanza. Su valor aparece cuando pasas de “chat con documentos” a sistemas que actúan: agentes, automatización, copilotos internos y flujos productivos.

    MCP no te regala seguridad, ni observabilidad, ni buen diseño de herramientas: te obliga a tomarte esas decisiones en serio. Y ahí es donde suele estar la diferencia entre un demo y un sistema que puedes mantener seis meses después.

    Referencias:

    FAQ

    ¿Qué es MCP?

    MCP (Model Context Protocol) es un protocolo estándar diseñado para conectar aplicaciones que utilizan modelos de lenguaje (LLMs) con herramientas y contexto externo, permitiendo una interacción más estructurada y segura. Este protocolo ayuda a evitar problemas comunes como la falta de gobernanza y la inseguridad en las integraciones.

    ¿Cómo funciona MCP?

    MCP funciona mediante la definición de un cliente que se conecta a uno o varios servidores MCP. El cliente puede descubrir qué herramientas y recursos están disponibles, y ejecutarlos mediante un conjunto de contratos que establecen las entradas y salidas de cada herramienta.

    ¿Cuáles son los beneficios de usar MCP?

    Los beneficios incluyen interoperabilidad y reutilización de servicios, contratos explícitos que reducen la ambigüedad, una mejor gobernanza y controles de seguridad, así como una mayor claridad operacional en la producción.

    ¿Qué riesgos implica implementar MCP?

    Implementar MCP puede conllevar riesgos como la posibilidad de inyecciones de prompt, exposición a herramientas demasiado genéricas y falta de observabilidad si no se controlan adecuadamente las integraciones. Es importante tener un plan de mitigación y asegurar buenas prácticas de seguridad.

    ¿Cuándo debería usar MCP?

    Deberías considerar el uso de MCP si estás desarrollando agentes internos que requieren acciones en herramientas reales, si deseas estandarizar múltiples integraciones o si necesitas un sistema de gobernanza claro para las herramientas que se utilizan.