El problema: Integración propietaria
Cada framework de agentes define sus propias herramientas de forma propietaria. LangChain tiene sus Tools. CrewAI tiene sus propias abstracciones. Google ADK tiene su implementación. Si cambias de framework, reescribes todas las integraciones. Si quieres compartir una herramienta entre dos agentes distintos, duplicas código.
Model Context Protocol (MCP) estandariza esta conexión. Es un protocolo abierto cliente-servidor donde cualquier LLM puede descubrir, conectarse y usar herramientas externas sin código de integración personalizado.
Pero conviene ser precisos sobre qué es y qué no es. MCP no es arquitectura de agentes. No es un framework de reasoning. No es un sistema inteligente. Es una capa de interoperabilidad para tool-use en sistemas LLM, similar a lo que REST o gRPC son para APIs web. Estandariza el acceso a herramientas, no el cerebro del agente.
Arquitectura cliente-servidor
MCP usa una arquitectura simple: el cliente (la aplicación que hostea al LLM) se conecta a servidores que exponen capacidades. El servidor no sabe qué LLM lo usa. El cliente no sabe qué herramientas existen hasta que las consulta.
El flujo es directo:
- Discovery. El cliente consulta el servidor para aprender qué herramientas, recursos y prompts están disponibles.
- Request formulation. El LLM decide qué herramienta usar y formula los parámetros.
- Client communication. El cliente MCP envía una llamada estandarizada al servidor.
- Server execution. El servidor autentica, valida y ejecuta la acción.
- Response. El resultado vuelve al LLM, actualizando su contexto.
Tres tipos de recursos: Tools (funciones ejecutables como enviar email o consultar una base de datos), Resources (datos estáticos para lectura como archivos PDF o registros de base de datos), y Prompts (plantillas interactivas que guían la interacción del LLM).
Los mecanismos de transporte son STDIO para comunicación inter-proceso local, y HTTP con Server-Sent Events para conexiones remotas persistentes.
Descubrimiento semi-dinámico, no plug-and-play
El descubrimiento dinámico es la promesa de MCP: el cliente consulta qué herramientas existen en tiempo de ejecución. En teoría, eso elimina la necesidad de hardcodear herramientas en el código del agente.
En la práctica, el descubrimiento es semi-dinámico. Muchos sistemas MCP siguen requiriendo configuración estática del cliente: permisos predefinidos, políticas de acceso, schemas validados, validación fuerte de inputs y outputs. El agente descubre qué herramientas existen, pero no puede usar cualquier herramienta sin autorización previa.
La distinción importa. MCP reduce el coste de añadir herramientas nuevas sin volver a desplegar el agente, pero no elimina la configuración de infraestructura. Los permisos, las políticas y los schemas siguen siendo responsabilidad del diseñador del sistema.
Qué es realmente MCP: traducción arquitectónica
MCP no es un sistema de agentes. Es una capa de interoperabilidad para tool invocation en sistemas LLM. La traducción arquitectónica es directa:
- Tool = función de API
- Server = microservicio
- Client = runtime del LLM
- Discovery = registry dinámico
- MCP = HTTP + schema + tool registry para LLMs
La consecuencia es clara: MCP no cambia cómo razona el modelo, cómo planifica, ni cómo coordina agentes. Solo cambia cómo accede a herramientas externas. Es infraestructura de tooling, no capa cognitiva.
Interoperabilidad parcial, no completa
MCP estandariza el acceso a herramientas. No estandariza el resto del agente.
Los frameworks siguen teniendo formas distintas de tool routing, sistemas de memoria diferentes, agent loops distintos, y estrategias de error handling propias. MCP conecta el agente a las herramientas; no conecta el agente al agente.
El resultado es interoperabilidad parcial: las herramientas son compartibles entre frameworks, pero la lógica del agente, su memoria y su flujo de control siguen siendo propietarios. Eso es suficiente para resolver el problema de integración de herramientas, pero no convierte MCP en un estándar universal para agentes.
MCP vs Tool Use directo
Tool Use directo es un enlace propietario uno-a-uno entre un LLM y una función específica definida en tu aplicación. MCP es un protocolo abierto con descubrimiento semi-dinámico: el cliente consulta qué capacidades existen y decide en tiempo de ejecución cuáles usar.
La diferencia importa cuando el conjunto de herramientas cambia. Con Tool Use directo, añadir una herramienta requiere modificar el código del agente y redeployar. Con MCP, el servidor expone la nueva herramienta y el cliente la descubre sin cambios en el código del agente.
Pero MCP no es gratuito. Añade una capa de abstracción, latencia de descubrimiento, y complejidad operativa. Para aplicaciones con tres o cuatro funciones fijas, Tool Use directo es más eficiente. MCP brilla cuando la complejidad de integración supera el overhead del protocolo.
Y hay un contexto que conviene mencionar: MCP está en fase de estandarización emergente. Compite conceptualmente con tool calling nativo de OpenAI, Anthropic y Google, además de las integraciones propietarias de cada framework. Su éxito depende de adopción, no solo de diseño. El riesgo real es que MCP se convierta en otro estándar más, no en el estándar.
FastMCP: servidores en minutos
FastMCP es un framework Python de alto nivel para construir servidores MCP rápidamente. Usa decoradores para definir herramientas, genera schemas automáticamente desde type hints y docstrings, y soporta composición de servidores.
La ventaja es la velocidad de desarrollo. Una función Python con type hints y docstring se convierte en una herramienta MCP accesible por cualquier cliente compatible sin boilerplate adicional.
MCP en código
MCP es un patrón de arquitectura. FastMCP, Google ADK MCPToolset, o los servidores de referencia son implementaciones del patrón, no el patrón en sí.
Servidor MCP con FastMCP
from fastmcp import FastMCP
mcp_server = FastMCP()
@mcp_server.tool
def search_knowledge_base(query: str, limit: int = 5) -> list:
"""Busca en la base de conocimiento y devuelve resultados relevantes."""
results = [] # Lógica de búsqueda aquí
return results[:limit]
@mcp_server.tool
def get_user_preferences(user_id: str) -> dict:
"""Obtiene las preferencias almacenadas de un usuario."""
return {} # Lógica de retrieval aquí
if __name__ == "__main__":
mcp_server.run(transport="http", host="127.0.0.1", port=8000)Dos decoradores, dos herramientas MCP. Los type hints y docstrings generan automáticamente los schemas que el cliente necesita para descubrir y usar las herramientas.
Agente conectado a servidor MCP
from google.adk.agents import LlmAgent
from google.adk.tools.mcp_tool.mcp_toolset import (
MCPToolset, HttpServerParameters
)
root_agent = LlmAgent(
model='gemini-2.0-flash',
name='knowledge_agent',
instruction='Usa las herramientas disponibles para responder preguntas.',
tools=[
MCPToolset(
connection_params=HttpServerParameters(
url="http://localhost:8000"
),
tool_filter=['search_knowledge_base'] # Subset de seguridad
)
],
)El agente se conecta al servidor MCP, descubre las herramientas disponibles, y usa tool_filter para restringir el acceso a un subconjunto específico.
Conexión local vía STDIO
from google.adk.tools.mcp_tool.mcp_toolset import (
MCPToolset, StdioServerParameters
)
import os
TARGET_FOLDER = os.path.join(os.path.dirname(__file__), "files")
os.makedirs(TARGET_FOLDER, exist_ok=True)
filesystem_agent = LlmAgent(
model='gemini-2.0-flash',
name='filesystem_agent',
instruction=f'Gestionas archivos en: {TARGET_FOLDER}',
tools=[
MCPToolset(
connection_params=StdioServerParameters(
command='npx',
args=["-y", "@modelcontextprotocol/server-filesystem",
TARGET_FOLDER],
),
tool_filter=['list_directory', 'read_file']
)
],
)Conexión local vía STDIO a un servidor de filesystem pre-construido. El agente solo puede listar directorios y leer archivos dentro de una carpeta específica.
Seguridad: tool_filter es solo una capa
El tool_filter de MCP restringe qué herramientas ve un agente. Es útil, pero no es una solución de seguridad completa.
El tool_filter no sustituye permisos RBAC reales, sandboxing fuerte, validación de inputs y outputs, o aislamiento de ejecución. En sistemas reales, MCP es superficie de ataque adicional si no se diseña bien, no una mejora automática de seguridad.
MCP en sí no incluye autenticación ni autorización. La seguridad depende de la implementación del servidor. Exponer herramientas y datos vía MCP sin controles de acceso es un riesgo. La autenticación, la validación de inputs, el sandboxing y el aislamiento de ejecución son responsabilidad del diseñador del sistema, no del protocolo.
La primera vez que implementamos MCP, lo hicimos exponiendo todas las herramientas del servidor a todos los agentes. Parecía razonable: cada agente decide qué usar. Funcionó mal. Un agente de soporte técnico tenía acceso a herramientas de administración de base de datos. No las usaba mal, pero la superficie de ataque era innecesariamente amplia. Implementamos tool_filter por rol, autenticación por token, y sandboxing para herramientas que ejecutaban comandos. La superficie de ataque se redujo significativamente, pero el tool_filter solo fue la primera capa de una defensa en profundidad.
Observabilidad
Métricas operativas: tool discovery latency (tiempo de descubrimiento de herramientas), tool call success rate (porcentaje de llamadas exitosas), tool call latency (tiempo de ejecución por herramienta).
Métricas de seguridad: unauthorized access attempts (intentos de acceso no autorizado), tool_filter violations (intentos de usar herramientas filtradas), server authentication failures (fallos de autenticación del servidor).
Formato de log: {tool_name, client_id, action, status, duration_ms, auth_result}.
MCP combinado con otros patrones
Con Tool Use, MCP es la capa de estandarización sobre la que Tool Use opera. El agente usa herramientas; MCP define cómo se descubren y conectan.
Con Multi-Agent, diferentes agentes pueden conectar al mismo servidor MCP y compartir acceso a herramientas. El servidor es un recurso compartido; cada agente usa tool_filter para acceder solo a lo que necesita.
Con Memory, los recursos MCP pueden servir como fuente de memoria a largo plazo. Un servidor MCP que expone una base de conocimiento actúa como memoria semántica externa.
Con Planning, el plan puede incluir llamadas a herramientas MCP. El planificador decide qué herramientas son necesarias y en qué orden invocarlas.
Cuándo NO usar MCP
Aplicaciones con tres o cuatro funciones fijas donde Tool Use directo es más eficiente. Entornos donde la latencia de descubrimiento y la capa adicional de abstracción son inaceptables. Sistemas donde las herramientas no cambian y la interoperabilidad entre frameworks no es un requisito.
El coste de MCP supera el beneficio si el sistema es pequeño o controlado. La prueba práctica es directa: si puedes definir todas las herramientas en un archivo y no cambian frecuentemente, MCP añade complejidad sin beneficio.
Anti-patrones
- Envolver APIs legacy sin adaptación: una API que devuelve un registro a la vez sin filtrado produce agentes lentos e ineficientes. Diseña APIs con operaciones por batch y filtrado.
- Formatos incompatibles: exponer PDFs crudos o binarios cuando el agente necesita texto. Convierte a Markdown o texto plano en el servidor.
- Tool_filter como única capa de seguridad: el tool_filter restringe herramientas visibles, pero no sustituye RBAC, sandboxing, validación de inputs o aislamiento de ejecución.
- Sin autenticación: exponer herramientas MCP sin controles de acceso es un riesgo de seguridad. Implementa auth y authz en el servidor.
- Ignorar manejo de errores: las llamadas MCP fallan por problemas de red, requests inválidos o servicios indisponibles. Define cómo los errores vuelven al LLM para que pueda reintentar o adaptarse.
¿Cuándo debo usar MCP?
Cuando hay múltiples clientes, múltiples herramientas dinámicas, y necesidad de estandarización organizacional. Para aplicaciones simples con funciones fijas, Tool Use directo es más eficiente.
¿Cuál es la diferencia entre MCP y Tool Use?
Tool Use es el concepto general de que un LLM invoque funciones externas. MCP es un protocolo específico que estandariza cómo se descubren y conectan esas herramientas. MCP no mejora la inteligencia del agente; reduce el coste de conectar herramientas.
¿MCP es seguro?
MCP en sí no incluye autenticación ni autorización. El tool_filter es solo una capa de seguridad. Implementa controles de acceso, valida inputs, usa sandboxing, y aísla la ejecución. MCP añade superficie de ataque si no se diseña bien.
¿Qué es FastMCP?
Un framework Python para construir servidores MCP rápidamente. Usa decoradores para definir herramientas, genera schemas desde type hints y docstrings, y soporta composición de servidores.
¿Puedo usar MCP con modelos locales?
Sí. MCP es independiente del modelo LLM. Los mecanismos de transporte son STDIO para conexiones locales y HTTP+SSE para conexiones remotas.
¿MCP reemplaza a LangChain Tools o CrewAI Tools?
No reemplaza, complementa. MCP estandariza la conexión entre cliente y servidor. LangChain y CrewAI pueden consumir herramientas MCP a través de integraciones específicas. MCP es el protocolo; los frameworks son los clientes.
Conclusión
MCP resuelve un problema de integración que cada framework de agentes intentaba solucionar por su cuenta. Antes de MCP, cada agente tenía sus propias herramientas propietarias. Después de MCP, las herramientas son recursos compartidos que cualquier agente puede descubrir y usar.
Pero la promesa de interoperabilidad total es optimista. MCP estandariza el acceso a herramientas, no el resto del agente. El descubrimiento es semi-dinámico, no plug-and-play. La seguridad requiere defensa en profundidad, no solo tool_filter. Y el protocolo está en fase de estandarización emergente, compitiendo con tool calling nativo de los principales proveedores.
MCP no mejora la inteligencia del agente. Solo reduce el coste de conectar herramientas. Es infraestructura de tooling, no capa cognitiva. Eso es suficiente para resolver un problema real, pero no convierte a MCP en un estándar universal.
La decisión real es directa: pocos tools estables, Tool Use directo. Muchos tools cambiantes, MCP. Ecosistema multi-framework, MCP tiene sentido estratégico. La pregunta que define si vale la pena es simple: ¿vas a reescribir estas integraciones tres veces? Si la respuesta es sí, MCP es la inversión correcta. Si es no, Tool Use directo es más eficiente.