MCP (Model Context Protocol) es un estándar abierto que permite a una aplicación de IA comunicarse con servicios externos mediante una interfaz común. Para una pyme, la idea puede facilitar conectar software, pero no significa que cualquier conector sea seguro, compatible o conveniente: antes de adoptarlo hay que revisar qué expone, qué puede hacer y quién lo mantiene.
MCP conecta; no certifica el conector
Hecho: la especificación del Model Context Protocol describe una relación entre una aplicación anfitriona (host), un cliente que opera dentro de ella y un servidor que ofrece capacidades. Entre ellas distingue recursos, que exponen datos; prompts, que ofrecen instrucciones o plantillas; y herramientas (tools), que el modelo puede ejecutar. (Model Context Protocol, especificación versión 2026-07-28: https://modelcontextprotocol.io/specification/2026-07-28).
Interpretación práctica: piensa en MCP como una forma compartida de hablar entre programas, no como una evaluación de calidad del servicio que se conecta. Un conector podría limitarse a mostrar información, mientras otro podría habilitar cambios o acciones. El protocolo por sí solo no te dice si el servidor refleja los permisos de tu empresa, si sus respuestas están actualizadas ni si la aplicación de IA procesa los datos como necesitas.
Antes de probar uno, pide una ficha concreta: quién publica y opera el servidor, qué sistema contacta, qué datos lee o escribe, qué operaciones expone y qué versión mantiene. Confirma además que la aplicación de IA y ese servidor soportan las capacidades que realmente necesitas; que ambos usen MCP no prueba que todos sus comandos funcionen juntos. Si las respuestas son vagas, aún no tienes información suficiente para autorizar el acceso.
Define permisos por tarea, no por comodidad
Hecho: la especificación oficial señala que MCP permite acceso a datos y vías de ejecución de código; pide consentimiento y control del usuario, pero aclara que el protocolo no puede imponer por sí mismo esos principios en cada implementación. Recomienda que las aplicaciones incorporen flujos claros de consentimiento y controles de acceso. (Model Context Protocol, especificación versión 2026-07-28: https://modelcontextprotocol.io/specification/2026-07-28).
Interpretación práctica: solicita el acceso mínimo necesario para una tarea concreta. Si el primer objetivo es consultar disponibilidad de salas, empieza con lectura, no con permiso para borrar eventos, cambiar calendarios o enviar invitaciones. Separa las cuentas personales y de trabajo cuando corresponda, limita quién puede invocar cada acción y acuerda cómo retirar el acceso si cambia el responsable o termina la prueba.
La guía oficial de seguridad de MCP advierte que un servidor intermediario mal configurado puede crear problemas de consentimiento y que aceptar y reenviar tokens sin validar que fueron emitidos para el destino correcto abre riesgos de acceso indebido. (Model Context Protocol, guía Security Best Practices, versión 2026-07-28: https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices). Esto no significa que todo conector tenga ese defecto; sí justifica preguntar cómo se autentica, qué permisos solicita y cómo protege credenciales y sesiones.
En un ejemplo hipotético, una academia pequeña en Santo Domingo evalúa un conector para consultar la agenda de sus aulas y proponer una reserva tentativa. El equipo podría empezar con lectura del calendario y una solicitud pendiente de aprobación, no con permiso para confirmar, cancelar o invitar automáticamente. La dueña de la academia define quién aprueba y qué ocurre si hay un choque de horario. Este ejemplo ilustra una forma de limitar el alcance; no afirma que exista una integración disponible para esa academia.
Prueba límites, errores y datos que no deben salir
La guía oficial de seguridad de MCP recomienda tratar con cuidado las herramientas y sus descripciones, y detalla riesgos como el uso de tokens para un destinatario distinto y los problemas de confianza en servidores intermediarios. (Model Context Protocol, guía Security Best Practices, versión 2026-07-28: https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices).
Interpretación práctica: antes de conectar datos reales, prueba en un entorno limitado qué devuelve cada operación, qué pasa si faltan datos, si una acción falla o si el servicio queda fuera de línea. Revisa si una herramienta intenta hacer más de lo prometido y si el sistema muestra con claridad cuándo consulta datos o prepara una acción. Ensaya también cómo detener una ejecución y a quién avisar. Evita cargar información sensible hasta entender dónde se procesa, quién puede verla y cuánto tiempo se conserva; estas preguntas deben tener respuesta del proveedor, no una suposición del equipo.
Clasifica las operaciones por impacto. Consultar un horario o preparar una solicitud no tiene el mismo efecto que confirmar una reserva, borrar registros o enviar una invitación. Para los pasos que comprometen a la empresa o a otra persona, exige revisión explícita antes de ejecutar. Ese criterio conecta con la guía de Jarvis sobre aprobación humana: https://www.jarvisrd.com.do/blog/aprobacion-humana-ia-no-decide-sola. La aprobación no corrige un permiso excesivo ni sustituye el control técnico; es una capa adicional dentro de un flujo bien acotado.
Aclara quién lo mantiene y cuándo parar
MCP es una especificación, no un servicio con un único responsable. Anthropic anunció el estándar abierto el 25 de noviembre de 2024 para conectar asistentes de IA con sistemas externos, y describió servidores que exponen datos y clientes que se conectan a ellos. (Anthropic, “Introducing the Model Context Protocol”, 25 de noviembre de 2024: https://www.anthropic.com/news/model-context-protocol). La publicación explica el origen del protocolo; no certifica conectores de terceros ni garantiza soporte futuro.
Interpretación práctica: acuerda quién actualiza el conector, cómo avisa cambios, qué dependencias mantiene, dónde se reportan incidentes y cuánto tarda en responder el soporte. Conserva un responsable interno que pueda revisar registros, revocar credenciales y volver al proceso manual. Si el proveedor no puede explicar cómo se actualiza o cómo se desactiva el acceso, no amplíes el piloto.
Una pyme puede comenzar con una sola tarea de bajo impacto, datos de prueba y permisos de solo lectura. Anota el resultado esperado, los casos en que debe detenerse, quién revisa los registros y cómo se desconecta. Después de probar errores y retirar el acceso, decide si la utilidad justifica una segunda etapa. Para empezar, redacta una hoja de una página con el nombre del servidor, propietario, datos, permisos, acciones, soporte y responsable de aprobación; si alguna casilla queda sin respuesta, aclárala antes de conectar la cuenta real.