Guía de MCP para líderes de producto
Cuando Anthropic presentó Model Context Protocol en noviembre de 2024, propuso una forma común de conectar aplicaciones de IA con herramientas y datos externos. La comparación más conocida fue “un USB-C para la IA”: un solo protocolo en lugar de una integración personalizada para cada modelo, producto y servicio.
La idea importa porque un producto de IA útil necesita más que un modelo. Necesita documentación vigente, datos del negocio y formas claramente delimitadas de actuar. MCP ofrece una capa estándar entre una aplicación de IA y esos sistemas.
Este artículo se publicó originalmente el 8 de abril de 2025. Lo recuperamos el 14 de julio de 2026 y actualizamos la terminología, los ejemplos y los enlaces sin cambiar su argumento original.
El problema que resuelve MCP
Incluso los modelos de lenguaje más capaces operan detrás de barreras de información. Sin una integración, un asistente de soporte no puede leer la documentación más reciente, un asistente de programación no puede consultar una API privada y un asistente de análisis no puede trabajar con datos actuales.
La solución tradicional ha sido construir cada conexión por separado. Ese enfoque funciona con una o dos integraciones, pero resulta costoso de mantener cuando cada modelo y aplicación necesita su propia autenticación, esquemas, manejo de errores y permisos.
MCP reduce esa fragmentación con un protocolo común. Un sistema puede exponer una vez un conjunto específico de datos y acciones, y poner esas capacidades a disposición de aplicaciones compatibles según los permisos que autoricen el host y el usuario.
Cómo funciona MCP
MCP sigue una arquitectura de cliente, host y servidor. El host es la aplicación de IA. Crea un cliente MCP para cada conexión, mientras que un servidor MCP expone una capacidad específica, como una base de datos, un repositorio, un servicio de comunicación o una API interna. La descripción oficial de la arquitectura explica con más detalle las capas de datos y transporte.
La capa de datos usa mensajes JSON-RPC para la inicialización, la negociación de capacidades, las solicitudes, las respuestas y las notificaciones. La capa de transporte lleva esos mensajes de forma local o por una red. Esta separación permite que cada servidor se concentre en su dominio sin depender de un modelo específico.
Tres primitivas del servidor definen la mayoría de las interacciones de producto:
- Recursos: ofrecen datos de contexto, como archivos, registros de una base de datos o respuestas de una API. La aplicación host decide cómo incorporar ese contexto.
- Herramientas: son funciones que un modelo puede invocar, como consultar una base de datos, enviar un mensaje o crear una tarea. Cada herramienta publica un nombre, una descripción y un esquema de entrada.
- Prompts: son plantillas reutilizables que ayudan a emplear las herramientas y los recursos de un servidor de manera consistente.
Las primeras versiones de MCP también describían las roots como límites del sistema de archivos. Las roots están obsoletas en la especificación actual. Las implementaciones nuevas deberían pasar archivos y directorios mediante parámetros de herramientas o URI de recursos.
El resultado es una arquitectura modular. Un equipo puede añadir o reemplazar un servidor sin cambiar el modelo, y un cliente compatible puede descubrir las capacidades declaradas por ese servidor.
MCP frente a otros enfoques
MCP coincide en algunos aspectos con enfoques que los equipos de producto ya conocen, pero resuelve una capa diferente del problema.
La llamada de funciones de OpenAI permite ofrecer funciones estructuradas a un modelo dentro de una aplicación. Es útil cuando la aplicación controla toda la integración, mientras que MCP define un protocolo portátil entre clientes y servidores que distintas aplicaciones pueden compartir.
LangChain ofrece bibliotecas y abstracciones para crear flujos de IA. Puede funcionar junto con MCP, pero un framework no hace que las herramientas de una aplicación sean visibles automáticamente para otra.
Los agentes inspirados en AutoGPT demostraron que un modelo podía elegir y encadenar acciones. Esos primeros proyectos se concentraban en el comportamiento del agente; MCP se concentra en la interfaz, la negociación de capacidades y los límites entre el agente y los sistemas externos.
Para los equipos de producto, MCP se diferencia por características concretas:
- Es un protocolo abierto, no una API exclusiva de un modelo.
- Los servidores exponen capacidades específicas mediante esquemas explícitos.
- Los clientes y servidores negocian las funciones que admiten.
- Los servicios locales y remotos pueden usar el mismo protocolo central.
Lo que MCP significa para líderes de producto
El principal cambio de producto consiste en pasar de una IA que solo genera una respuesta a una IA que puede recopilar contexto y completar una tarea delimitada. Esto influye en el diseño de funcionalidades, las revisiones de seguridad, la selección de proveedores y la hoja de ruta del producto.
La inteligencia incorporada puede usar datos actuales
Una funcionalidad de IA puede obtener información vigente sin pedirle a la persona que cargue un archivo o copie datos entre pestañas. Un asistente de soporte, por ejemplo, podría consultar un registro de facturación autorizado, explicar un cobro y preparar el historial de transacciones.
La experiencia deja de ser una conversación genérica y se convierte en una tarea basada en los sistemas donde ya ocurre el trabajo. La pregunta de producto pasa a ser qué contexto hace falta y qué acciones deben estar disponibles.
Los flujos con varias herramientas se pueden combinar
MCP facilita combinar capacidades sin programar cada secuencia de forma rígida. Una solicitud para analizar datos de ventas, preparar un resumen y compartirlo con el equipo podría involucrar servidores distintos para el CRM, los documentos y el chat.
El producto sigue necesitando un comportamiento claro ante fallas parciales, reintentos y aprobaciones. El protocolo estandariza las conexiones, pero no reemplaza el diseño del flujo.
La seguridad permanece explícita
Un servidor MCP debería exponer únicamente los datos y las acciones necesarios para su función. Esto sigue el principio de privilegio mínimo y ofrece a quienes revisan la seguridad una superficie más pequeña que un acceso general al sistema.
Las herramientas sensibles o destructivas deberían exigir confirmación, y cada llamada debe ejecutarse bajo la autorización del usuario. Las descripciones y los esquemas ayudan a limitar las entradas, pero el servidor todavía debe autenticar solicitudes, validar datos, aplicar permisos y registrar los eventos de auditoría pertinentes.
La capa de conectores reduce la dependencia del modelo
Como la integración se encuentra detrás de un protocolo común, los equipos pueden evaluar modelos y hosts sin reconstruir cada conector. La compatibilidad no hace que todos los modelos sean equivalentes, pero evita que la capa de conexión dependa de un único proveedor de inferencia.
El ecosistema acorta el trabajo de integración
Antes de escribir otra capa sobre una API, los equipos pueden evaluar servidores existentes. Para una cobertura amplia, Zapier MCP documenta conexiones con miles de aplicaciones y acciones. Para sistemas privados, los SDK de TypeScript y Python incluyen los elementos necesarios para crear un servidor específico.
Primeros pasos con servidores MCP
Una primera implementación útil debe ser acotada, medible y fácil de revertir. Conviene empezar con un solo problema en el que el contexto actualizado o una acción eliminen trabajo manual evidente.
Identifica los puntos de integración
Enumera los sistemas que contienen el contexto o las acciones necesarias para resolver ese problema:
- Bases de conocimiento y documentación interna
- Datos de clientes o cuentas
- Correo electrónico y chat del equipo
- Sistemas de gestión de proyectos
- Repositorios de código y entornos de desarrollo
Da prioridad al conjunto mínimo que permita completar la tarea. Cada sistema adicional trae más trabajo de permisos, confiabilidad y soporte.
Evalúa los servidores existentes
Revisa la documentación oficial del proveedor y el repositorio de servidores MCP antes de crear un conector. Comprueba la autenticación, la actividad de mantenimiento, el tratamiento de datos, los esquemas de herramientas y los requisitos de despliegue. Un listado público es un punto de partida, no una revisión de seguridad.
Crea un servidor personalizado y específico
Para un sistema interno, define los recursos y las herramientas que expondrá el servidor, implementa autorización y validación, y elige un transporte local o remoto. La guía actual del SDK de TypeScript usa un esquema de Zod para publicar y validar las entradas de una herramienta.
import { McpServer } from '@modelcontextprotocol/server';
import * as z from 'zod/v4';
const server = new McpServer({
name: 'my-product-connector',
version: '1.0.0',
});
server.registerTool(
'get_user_profile',
{
description: "Fetch a user's profile information",
inputSchema: z.object({
userId: z.string().describe('ID of the user to fetch'),
}),
},
async ({ userId }) => {
// Authenticate the caller and enforce access before reading data.
const profile = await databaseClient.fetchUser(userId);
return {
content: [{ type: 'text', text: JSON.stringify(profile) }],
};
},
);El ejemplo muestra el límite de la herramienta, no un servidor completo para producción. Una implementación real también necesita configurar el transporte, autenticar y autorizar, manejar errores de forma segura, limitar solicitudes, registrar actividad y tener pruebas.
Diseña la experiencia de las herramientas
Define cómo explicará y controlará el producto el uso de herramientas:
- Qué herramientas pueden ejecutarse de forma automática y cuáles exigen aprobación
- Qué intención del usuario debe activar una herramienta
- Cómo se muestran el progreso y los efectos de la acción
- Qué ocurre cuando un servicio no está disponible o devuelve datos incompletos
Las personas deben saber cuándo la IA lee datos y cuándo está a punto de modificar algo. Las vistas previas y las confirmaciones claras son funcionalidades del producto, no detalles de implementación.
Adopta MCP por fases
Una adopción por fases mantiene el riesgo en proporción con lo que el sistema puede hacer:
- Comienza con acceso de solo lectura a recursos no sensibles.
- Añade herramientas de escritura con aprobación explícita.
- Permite una ejecución más automática solo en flujos con autorización, observabilidad y recuperación adecuadas.
MCP en acción y en la estrategia de producto
El ecosistema se ha ampliado desde la primera publicación de este artículo. Los clientes de escritorio y programación pueden conectarse con servidores locales y remotos, Replit publica un servidor MCP para crear y administrar aplicaciones, y Block fue nombrada como una de las primeras adoptantes en el anuncio de lanzamiento del protocolo. Estos ejemplos muestran el mismo patrón: el host de IA puede concentrarse en la experiencia, mientras cada servidor se encarga de su integración.
Los registros y directorios de proveedores también facilitan el descubrimiento de servidores. Esto ayuda a la adopción, pero cada equipo debe evaluar quién opera el servidor, qué permisos solicita, cómo conserva los datos y qué hace antes de habilitarlo.
Las implicaciones estratégicas son directas:
- Diseña para tareas, no solo para respuestas. Empieza con un resultado que necesite contexto o una acción.
- Mantén las capacidades modulares. Separa la experiencia del host de cada integración.
- Aplica privilegio mínimo desde el principio. Expón la menor superficie útil de datos y acciones.
- Planifica para más de un modelo. Mantén las decisiones sobre conectores separadas de la evaluación de modelos cuando sea posible.
- Mide resultados completos. Comprueba si el flujo resolvió el problema, no solo si una herramienta respondió.
MCP cambió la pregunta de integración de “¿cómo conectamos este modelo con cada servicio?” a “¿qué capacidades debería exponer este producto y bajo qué controles?”. Los líderes de producto que respondan bien la segunda pregunta podrán crear funcionalidades de IA que hagan trabajo útil sin renunciar a los límites que necesitan las personas y las organizaciones.
