MCP despues del hype: como usarlo bien en una empresa real
MCP se ha convertido en un estandar clave para conectar agentes de IA con herramientas y datos. Pero usarlo bien exige permisos, catalogo de herramientas, logs, servidores internos y criterios claros de seguridad.
El Model Context Protocol, o MCP, paso en poco tiempo de ser una novedad tecnica a convertirse en una pieza central del ecosistema de agentes. Anthropic lo presento en noviembre de 2024 como un estandar abierto para conectar asistentes de IA con datos, herramientas y entornos de trabajo. En diciembre de 2025, Anthropic dono MCP a la Agentic AI Foundation bajo la Linux Foundation, con apoyo de empresas como OpenAI, Google, Microsoft, AWS, Cloudflare y Bloomberg.
El salto es importante: MCP ya no es solo "una forma de conectar Claude a tus datos". Es una infraestructura comun para que agentes de distintas plataformas puedan acceder a sistemas externos.
Pero precisamente por eso hay que usarlo con cuidado. Un mal servidor MCP puede convertir un agente util en un riesgo operativo.
Que resuelve MCP
Antes de MCP, cada integracion entre un modelo y una herramienta exigia codigo especifico. Si querias conectar un asistente a Google Drive, Notion, GitHub, Slack, un CRM y una base de datos, acababas construyendo conectores distintos para cada caso.
MCP propone un patron comun:
- El agente habla un protocolo estandar
- Cada herramienta expone un servidor MCP
- El agente descubre que herramientas existen
- El agente pide datos o ejecuta acciones mediante ese servidor
Anthropic lo describio como una especie de conector universal para IA. La analogia es util, pero incompleta: en una empresa real no basta con enchufar. Hay que gobernar.
El error: tratar MCP como una lista infinita de herramientas
Una tentacion habitual es conectar todo:
- CRM
- ERP
- Drive
- Notion
- Calendario
- Facturacion
- Base de datos
- Tickets
- Slack o Teams
El problema es que mas herramientas no siempre significan mejor agente. Significan mas superficie de error.
Un agente con demasiadas herramientas puede:
- Elegir la herramienta equivocada
- Confundir fuentes
- Ejecutar acciones fuera de contexto
- Mezclar datos sensibles
- Generar logs dificiles de auditar
- Ser vulnerable a prompt injection desde documentos o mensajes
La regla practica: cada agente debe tener el minimo conjunto de herramientas necesario para su tarea.
Catalogo de herramientas
En una empresa, MCP deberia gestionarse como un catalogo. No como una coleccion de scripts sueltos.
Cada herramienta MCP deberia documentar:
- Nombre y finalidad
- Sistemas a los que accede
- Tipo de datos que lee
- Acciones que puede ejecutar
- Permisos requeridos
- Riesgos
- Responsable interno
- Logs disponibles
- Entornos permitidos: desarrollo, pruebas, produccion
Esto permite saber que capacidades tiene cada agente y evita que una herramienta peligrosa acabe disponible en un asistente general.
Permisos por agente, no por servidor
Un servidor MCP puede exponer muchas operaciones. Eso no significa que todos los agentes deban poder usarlas.
Por ejemplo, un servidor MCP para CRM podria permitir:
- Buscar cliente
- Ver historial comercial
- Crear nota
- Cambiar estado de oportunidad
- Crear presupuesto
- Aplicar descuento
- Eliminar registro
Un agente de soporte quizas solo necesita buscar cliente y crear nota. Un agente comercial puede crear oportunidad. Un agente administrativo puede preparar presupuesto, pero no aprobarlo.
Los permisos deben definirse por rol, caso de uso y nivel de riesgo.
Logs y trazabilidad
MCP hace que el agente pueda actuar. Por tanto, cada accion debe dejar rastro.
Un log util deberia responder:
- Que agente llamo a la herramienta
- Que usuario inicio la conversacion
- Que operacion se ejecuto
- Con que parametros
- Que devolvio el sistema
- Si hubo aprobacion humana
- Que respuesta final vio el usuario
Sin logs, MCP se convierte en una caja negra conectada a tus sistemas. Eso no es aceptable en produccion.
Servidores internos frente a servidores publicos
La comunidad tiene miles de servidores MCP publicos. Son utiles para prototipos y desarrollo, pero en empresa conviene distinguir:
| Tipo de servidor | Uso razonable |
|---|---|
| Publico y comunitario | Pruebas, herramientas de bajo riesgo |
| Proveedor oficial | Integraciones comunes con soporte |
| Interno | Sistemas criticos, datos sensibles, reglas propias |
| Gateway corporativo | Punto central para permisos, logs y auditoria |
Para datos de clientes, documentos internos, ERP o facturacion, lo normal es construir o controlar tus propios servidores MCP.
MCP y bases de conocimiento
MCP no sustituye a una base de conocimiento. La complementa.
Una base como Polp permite centralizar documentos, indexarlos y responder con fuentes. MCP puede servir para que un agente consulte esa informacion y, si corresponde, ejecute una accion en otro sistema.
Ejemplo:
- El usuario pregunta por una politica interna.
- El agente consulta Polp y obtiene la respuesta con fuente.
- Si la politica exige crear una solicitud, el agente llama al MCP del sistema de tickets.
- El ticket queda creado y auditado.
Ese flujo es mucho mas robusto que un agente conectado directamente a diez carpetas y tres sistemas sin criterio.
Riesgos especificos de MCP
Los riesgos principales no son teoricos:
- Prompt injection en documentos o datos externos
- Herramientas demasiado poderosas
- Falta de autenticacion empresarial
- Acciones no auditadas
- Dependencia de servidores de terceros
- Despliegues sin revision de seguridad
- Mezcla de entornos de prueba y produccion
Por eso MCP debe tratarse como infraestructura, no como plugin.
Como empezar bien
Orden recomendable:
- Crear un caso de uso concreto.
- Definir que datos necesita el agente.
- Exponer solo esas herramientas.
- Activar logs desde el inicio.
- Separar lectura y escritura.
- Usar aprobacion humana para acciones sensibles.
- Evaluar calidad con conversaciones reales.
- Ampliar herramientas solo si aportan valor medible.
Como podemos ayudarte
En Navel Digital implementamos MCP con enfoque empresarial: servidores internos, permisos por agente, auditoria, integracion con CRM/ERP, bases de conocimiento como Polp y fallback humano.
MCP no es magia. Es una buena capa de conexion. La diferencia esta en si la conectas con gobierno o con improvisacion.