Sigue una consulta de stock para entender MCP, conectores reutilizables, identidad, límites de datos y una primera conexión comprobable.
Autor
Anichur Rahaman
Parte 2 de 3
IA en la operación, 2026La dueña ve una demostración donde un asistente responde sobre inventario. Para el lunes quiere conectarlo también a pedidos y contabilidad. Su responsable de operaciones pregunta otra cosa: cuando consulte el gerente de una sucursal, ¿qué registros podrá ver realmente el asistente?
La empresa es ficticia, pero esa es una buena conversación antes de comprar. Un formato común puede reducir trabajo de integración. Por sí solo no decide permisos, no vuelve correctas todas las respuestas ni mantiene los datos en casa. MCP, Model Context Protocol, aporta ese lenguaje común; las personas siguen eligiendo los límites.
Esta es la segunda parte sobre IA en operaciones. La primera elige tareas adecuadas para agentes; la tercera aborda aprobación y evidencia de auditoría. No hace falta código para seguir esta conexión.
MCP describe cómo una aplicación de IA descubre y utiliza capacidades de otro programa. Piensa en una forma de enchufe conocida: ayuda a la compatibilidad, pero no determina quién puede usar el dispositivo ni qué información debe exponer.
El host es la aplicación de asistente que usa la persona. Su componente cliente se comunica con un servidor MCP. Este traduce peticiones permitidas a operaciones existentes del sistema de negocio. Es un rol de software, no necesariamente otra máquina física. Un host puede conectarse a varios servidores.
El servidor puede ofrecer recursos —contexto identificado por URI—, herramientas —funciones invocables— y prompts —plantillas reutilizables—. Consultar stock puede ser una herramienta de solo lectura; «herramienta» no significa escritura y «recurso» no significa dato no sensible. Una plantilla no es política de acceso. Comprueba qué funciones soportan ambos extremos sin asumir que ofrecen las tres.
Imagina tres aplicaciones de asistente y tres sistemas. Un diseño a medida ingenuo podría mantener nueve integraciones específicas por pareja. MCP permite sustituir trabajo de protocolo repetido por soporte host/cliente e interfaces de servidor reutilizables: conceptualmente tres más tres componentes.
Si cada asistente usa cada sistema, siguen existiendo tres × tres = nueve rutas lógicas de acceso que configurar y autorizar. «Seis componentes reutilizables» no significa «seis conexiones activas». Puede compartirse infraestructura o agruparse sistemas, y no todos los adaptadores cuestan lo mismo. Es una ilustración de diseño, no ahorro garantizado.
Todavía hay que resolver mapeos, unidades, identificadores, validaciones y API subyacentes. Conserva las reglas autorizadas en el sistema dueño de la operación y reutilízalas en pantallas, API y MCP. Hosts y proveedores de modelos también tienen responsabilidades de seguridad; el protocolo no concentra mágicamente todas las reglas en una puerta única.
En nuestro ejemplo, el gerente puede leer stock de la Tienda 2, pero no márgenes de otras tiendas ni nómina. Pregunta cuántas botellas puede vender ahora en su ubicación. El host usa una consulta permitida; el servidor comprueba identidad, alcance, tienda y campos antes de devolver datos.
En la instantánea indicada hay 50 unidades físicas, incluidas 5 retenidas por calidad. De las 45 aprobadas, 20 ya están reservadas. El stock aprobado libre actual es 50 − 5 − 20 = 25. Las categorías no se solapan en este ejemplo. No vuelvas a restar retenciones o reservas si la cifra «disponible» ya las excluye.
La respuesta incluye ubicación, unidades, base de estado y fecha de evidencia. No añade direcciones de clientes o costo del proveedor porque existan en la base. Veinticinco unidades libres son una instantánea, no promesa de entrega ni pronóstico; el siguiente pedido puede cambiarla.
Si pide cifras restringidas de otra tienda, se deniega antes de recuperar los datos. Filtrar solo la frase final llega tarde si los registros ya entraron en contexto, caché o log. Un posterior borrador de compra requiere otro permiso y flujo; responder stock no concede derecho a comprar.
Para conexiones HTTP remotas protegidas, revisa con el proveedor la especificación de autorización MCP. Describe un marco basado en OAuth. La autorización es opcional en el protocolo: eso no permite publicar anónimamente datos privados del ERP. En procesos stdio locales no se prescribe ese flujo HTTP OAuth; controla credenciales y acceso al sistema operativo por separado.
Iniciar sesión identifica; el consentimiento autoriza acceso de un cliente; los scopes limitan un token; las reglas del negocio deciden si esa persona puede leer ese registro o aprobar esa acción. OAuth no reproduce automáticamente roles, filtros ni aprobaciones del ERP. En cada llamada, el acceso efectivo debe respetar derechos del usuario, alcance delegado y política vigente.
Pregunta por validación de audiencia/recurso del token, PKCE cuando corresponda, almacenamiento seguro, vencimiento, revocación y bloqueo de usuarios desactivados. Nada es escudo universal frente a credenciales robadas o un host comprometido. No pases el token de un servicio a otro ajeno como atajo. El trabajo desatendido necesita identidad de servicio limitada, responsable y revisión, sin suplantar silenciosamente a un gerente.
Un servidor MCP local es software ejecutable. Elige editor confiable y versión controlada; entiende qué archivos, credenciales y destinos de red puede usar. «Corre en mi portátil» no es certificación de seguridad.
El servidor puede estar junto al ERP mientras host o modelo están fuera. El host decide qué contexto devuelto llega al modelo u otro servicio; no tiene por qué reenviar automáticamente cada byte. Inspecciona prompts, resultados, cachés, logs, soporte, subencargados, retención y condiciones de entrenamiento.
Usa campos mínimos, registros permitidos y destino del modelo aprobado. Texto de clientes, notas internas y archivos pueden incluir instrucciones hostiles; estar dentro de la empresa no los convierte en autoridad. Las descripciones y pistas de solo lectura tampoco prueban una implementación segura. Los controles deben funcionar aunque el modelo pida algo indebido.
Pide demostrar los límites de la tabla. La evidencia ayuda a investigar; un log no evita un incidente solo por existir. Protégelo y oculta información sensible, sin guardar todos los argumentos y resultados completos indefinidamente.
| Límite | Prueba práctica que pedir |
|---|---|
| Identidad y registros | No puede recuperar el registro restringido de otra tienda, ni por ID |
| Datos mínimos | La respuesta omite costos privados, direcciones y campos ajenos |
| Control de acciones | El borrador no reserva ni envía en secreto; ejecutar exige aprobación adecuada |
| Recuperación | Se concilia resultado registrado incierto; reintentar no duplica |
| Evidencia y revocación | Auditoría restringida y depurada; bloqueo según política declarada |
Esta revisión comprobó la especificación oficial 2026-07-28, cuyo núcleo usa peticiones autocontenidas. Revisiones anteriores usaban sesiones ligadas a conexión. Pregunta qué versión, transporte y funciones opcionales implementa cada extremo, cómo prueban compatibilidad y quién mantiene las actualizaciones.
Que el protocolo sea stateless no vuelve sin estado un flujo de compra ni elimina datos de negocio compartidos. Autenticación, capacidad, consistencia, referencias de operación y tareas largas siguen necesitando diseño. Una versión de protocolo no demuestra que añadir balanceadores escale el ERP de forma segura.
Elige un gerente, una ubicación y una consulta útil. Registra campos permitidos, vigencia de evidencia, destino del proveedor y responsable. Compara con el sistema origen, incluidos casos vacíos, antiguos y ambiguos. Prueba pedir directamente un registro prohibido; no basta esconder su menú.
Prueba instrucciones en documentos, acceso vencido/revocado, cambios de definición de herramienta y caída del proveedor. Antes de introducir escrituras, comprueba aprobación de versión exacta, borrador realmente inerte y timeout después del commit. Concilia la operación existente antes de reintentar con backoff limitado; evita duplicar compromisos y asigna responsable a lo incierto. No repitas peticiones denegadas o inválidas.
Amplía solo cuando pruebas y valor lo justifiquen, no porque hayan pasado cuatro semanas. La demo de StoreConsole muestra flujos para discutir, no demuestra qué host MCP, versión o permisos están habilitados en tu instalación.
El resultado útil del lunes es sencillo: el gerente comprueba 25 botellas libres aprobadas en su tienda con fecha, sin extraer datos de todos. MCP hizo comprensible la petición entre programas; una política probada hizo apropiada esa respuesta.
Revisado el 5 de noviembre de 2026. Anichur Rahaman es el creador de StoreConsole. Empresa, cantidades y recuentos de conexiones son ejemplos didácticos.
Series
IA en la operación, 2026Sobre el autor
Anichur Rahaman
Seguir Leyendo
