MCP en 5 minutos para devs LatAm: 1 protocolo, 12 integraciones

Si tu agente todavía consume APIs por wrappers escritos a mano, cada API nueva significa un archivo Python más, un try/except más, un formato de respuesta más para memorizar. El Model Context Protocol (MCP) resuelve exactamente eso: un solo protocolo que reemplaza N integraciones custom. En este post te dejo el mapa mínimo para arrancar, con los datos del registro oficial actualizado a agosto de 2026.

Este post apunta a devs que ya escribieron al menos un wrapper de API para un agente y sospechan que hay una forma mejor. Si después quieres ampliar, tengo dos posts más específicos: Claude Code Skills vs MCP Servers: guía LatAm 2026 para elegir entre las dos abstracciones, y MCP no soporta archivos, y 7 servidores lo demuestran para las limitaciones reales.

El problema en un párrafo

Cada API que tu agente necesita (Slack, GitHub, Jira, tu base de datos, tu ERP interno) requiere: una función Python, un manejo de autenticación, un formato de respuesta parseado, una descripción para que el LLM entienda cuándo llamarla. Con 12 APIs, tienes 12 wrappers, 12 formatos, 12 rutinas de renovación de token. Cuando cambia una API, cambia también tu wrapper.

MCP corta ese problema al medio. El servidor MCP encapsula la conexión con el sistema externo y expone tres cosas al agente: recursos, herramientas y prompts. El agente solo habla MCP. Tú cambias una API, cambias el servidor MCP correspondiente, el agente no se entera.

Los 3 elementos que expone un servidor MCP

En vez de repetir la especificación entera, quédate con esta separación:

Elemento	Qué es	Ejemplo concreto
Resources	Fuentes de datos que el agente puede leer	file:///workspace/docs/*, db://customers/table
Tools	Operaciones que el agente puede ejecutar	send_email(), create_ticket(), query_database()
Prompts	Plantillas reutilizables de prompt	code_review_template, bug_report_summary

La regla mental que uso: si el agente lo lee, es Resource. Si el agente lo ejecuta, es Tool. Si quieres estandarizar cómo pregunta, es Prompt.

Un servidor puede exponer los tres, o solo uno. La mayoría de los servidores del registro oficial exponen Tools + Resources y dejan Prompts vacío. No es un error, es un patrón.

El registro oficial: los números de 2026

El registro oficial de MCP lanzó en preview en septiembre de 2025 y a agosto de 2026 tiene más de 108 mil servidores contando los agregadores (Glama, Smithery, mcp.so, PulseMCP). El repositorio de referencia oficial en github.com/modelcontextprotocol/servers mantiene una lista mucho más chica (7 servidores activos más un archivo con implementaciones antiguas) que el equipo de MCP publica como implementaciones de referencia.

La distinción importa. Cuando alguien te dice “conecta MCP de Slack”, puede referirse a: (1) el servidor oficial mantenido por el steering group, (2) el servidor de Slack que subió un tercero al registro, o (3) uno que él mismo escribió y no está publicado. Los tres funcionan; los tres tienen dueños distintos y ciclos de mantenimiento distintos.

Antes de conectar cualquier servidor MCP en producción, revisa quién lo mantiene y cuándo fue el último commit. Un servidor abandonado con permisos de escritura sobre tu base de datos es una superficie de ataque disfrazada de integración.

Ejemplos LatAm que vale mirar

Buscando en el GitHub topic mcp-server con filtro por región, hay implementaciones interesantes hechas por devs LatAm que sirven como referencia para leer código real:

• Servidores MCP para Open Finance Brasil (por ejemplo thunderjr/openfinance-mcp-server o douglac/banco-mcp): un patrón común es exponer las cuentas del usuario como Resources y las transferencias como Tools con confirmación explícita. Buen ejemplo de cómo separar lectura y escritura en el mismo servidor.
• Servidores MCP para APIs públicas nacionales (por ejemplo alanpcf/brasil-data-mcp sobre BrasilAPI para CNPJ/CEP): el patrón interesante es que exponen la consulta como Tool (no Resource), porque cada llamada a la API oficial tiene costo y latencia. Modelarla como Resource haría que el agente la leyera “por las dudas”.
• Servidores MCP para datos abiertos (por ejemplo SidneyBissoli/ibge-br-mcp sobre APIs del IBGE): expuestos como Resources con URIs jerárquicas del estilo dataset://poblacion/municipio/.... Esto permite al agente navegar sin cargar todo el dataset al contexto.

Los tres comparten un patrón: usar el URI del Resource como filtro de scope antes de leer los datos. Esto es la diferencia entre un agente que carga 200MB de dataset al contexto y uno que pide exactamente la fila que necesita.

Primer servidor MCP: la ruta más corta

Si nunca corriste un servidor MCP, la ruta más corta es el servidor de filesystem oficial. Instala Python, pip install fastmcp, tres líneas de configuración y ya tienes un agente que puede leer archivos de un directorio específico.

from fastmcp import FastMCP

mcp = FastMCP("mi-primer-servidor")

@mcp.tool()
def contar_lineas(path: str) -> int:
    """Cuenta las líneas de un archivo de texto."""
    with open(path) as f:
        return sum(1 for _ in f)

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

Eso es todo. La descripción del docstring ("""Cuenta las líneas...""") es lo que el LLM lee para decidir cuándo llamar la herramienta. La calidad de esa descripción define si el agente la usa correctamente o la ignora — el 80% del trabajo de escribir un buen servidor MCP es escribir buenas descripciones de tools.

Con esto conectado a tu cliente (Claude Desktop, Cursor, Zed, etc.), el agente ya puede razonar sobre archivos locales sin que escribas tú la lógica de acceso.

El error clásico: exponer demasiado

Cuando alguien empieza con MCP, la tentación es exponer todas las funciones de una API como Tools. No lo hagas. Cada Tool que expones consume tokens del contexto del agente (la descripción se carga siempre), y las que no usa terminan siendo ruido que empeora las decisiones del modelo.

La regla práctica que aprendí después de romper mi propio agente varias veces: si un usuario típico de tu servidor no va a usar una Tool en el 20% de sus sesiones, no la expongas por defecto. Ponla detrás de una flag opcional o en un servidor MCP separado.

Este es probablemente el mayor error que veo en implementaciones nuevas. Un servidor MCP con 47 Tools no es más útil que uno con 8 — es más lento, más caro en tokens y con peores decisiones del agente.

Cuándo NO usar MCP

MCP no es siempre la respuesta.

• Una sola llamada de API en toda tu app: escribir un wrapper directo es más simple. MCP tiene sentido cuando hay varias APIs y varios agentes.
• Latencia crítica (<50ms): el overhead del protocolo MCP suma unos 10-30ms por llamada. Para casos de trading algorítmico o control de hardware con timing estricto, MCP puede sobrar.
• Datos ultra sensibles sin auditoría de flujo: si necesitas rastrear cada byte que sale de tu sistema, el modelo cliente-servidor de MCP agrega una capa que a veces complica más que ayuda. Vale la pena, pero requiere configurar logging propio.

Para el resto de los casos (agentes internos, automatización de tareas, RAG con múltiples fuentes), MCP es la opción por defecto en 2026.

Resumen para tener a mano

• MCP reemplaza N wrappers a mano por un protocolo estándar
• Los 3 elementos: Resources (lo que se lee), Tools (lo que se ejecuta), Prompts (lo que se estandariza)
• Registro oficial: registry.modelcontextprotocol.io — más de 108 mil servidores agregados
• Repo de referencia: github.com/modelcontextprotocol/servers (7 activos + archivo)
• Regla de oro: no expongas Tools que no se usan seguido. El costo de tokens es real.
• Primer paso: pip install fastmcp y un servidor de filesystem local

Si quieres bajar de golpe a los detalles arquitectónicos (cliente-host-servidor, seguridad, patrones de nivel enterprise), esos temas están en la sección de MCP del libro de Context Engineering que preparé, pero para arrancar con MCP en tu propio código lo de arriba alcanza.

---

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev