MCP, o cómo la IA se conecta a tu empresa

El estándar detrás de los agentes que consultan datos y ejecutan acciones

Abstract black and white graphic featuring a multimodal model pattern with various shapes.

El Model Context Protocol, o MCP, es un estándar abierto que define cómo una aplicación de inteligencia artificial (o agente) puede comunicarse con datos, herramientas y sistemas externos.

En términos simples, funciona como un puente entre un modelo de lenguaje y la infraestructura de una organización: bases de datos, APIs, documentos, aplicaciones internas, gestores de expedientes o plataformas empresariales.

Una inteligencia artificial, por sí sola, no sabe qué está ocurriendo dentro de una empresa o de un organismo. Puede explicar cómo debería analizarse un contrato, pero no conoce los contratos firmados por la organización. Puede redactar un informe sobre las ventas, pero no sabe cuál es el stock real. Puede sugerir que se actualice un registro, pero no tiene acceso al sistema donde debe hacerlo.

Para superar esa limitación necesita conexiones.

El MCP proporciona una manera común de construirlas.

El protocolo fue presentado públicamente por Anthropic en noviembre de 2024 (Anthropic) como un estándar abierto para conectar asistentes de inteligencia artificial con los sistemas donde viven los datos, como repositorios de contenido, herramientas empresariales y entornos de desarrollo. Su objetivo inicial fue reducir la fragmentación provocada por las integraciones construidas individualmente para cada nueva fuente de información.

El problema no es solamente el modelo

Durante los últimos años, la conversación sobre inteligencia artificial estuvo dominada por las capacidades de los modelos.

Cuál razona mejor.

Cuál escribe mejor.

Cuál procesa más documentos.

Cuál responde más rápido.

Pero, dentro de una organización, la calidad del modelo es solamente una parte del sistema.

Un modelo puede tener excelentes capacidades de razonamiento y, al mismo tiempo, ser incapaz de responder una pregunta básica como:

¿Cuáles son los motivos más frecuentes de inasistencias?

La respuesta no se encuentra dentro del modelo. Está en una base de datos, en un gestor documental o en alguna planilla interna.

Lo mismo ocurre cuando se le pide que actúe.

Un asistente puede redactar una respuesta para un cliente, pero necesita una conexión con el CRM para revisar su historial. Puede identificar que falta una inspección, pero necesita una herramienta para crear la orden correspondiente. Puede analizar un reporte comercial, pero debe acceder primero a los datos actualizados.

Por eso, una inteligencia artificial desconectada de la operación funciona como un asesor detrás de un vidrio: puede interpretar y recomendar, pero no puede observar directamente lo que sucede ni intervenir sobre los sistemas reales.

El MCP busca resolver esa distancia.

Cómo funciona el Model Context Protocol?

Imaginemos que un funcionario encargado de Obras Publicas escribe:

Mostrame las obras que tienen más de treinta días de atraso, indicá cuáles tienen inspecciones pendientes y prepará un informe para la Secretaría.

Para responder correctamente, la aplicación de inteligencia artificial necesita realizar varias tareas:

Consultar el sistema de obras.
Recuperar los expedientes relacionados.
Comparar el avance planificado con el avance registrado.
Verificar las inspecciones pendientes.
Obtener información presupuestaria.
Preparar el informe solicitado.

Sin una arquitectura de integración, cada una de esas conexiones debe programarse de forma particular dentro de la aplicación.

Con MCP, los sistemas de la organización pueden publicar qué información ofrecen, qué acciones permiten realizar y qué parámetros necesita cada operación.

El flujo básico puede representarse así:

Una persona realiza un pedido
              ↓
La aplicación de IA interpreta la solicitud
              ↓
Consulta las capacidades disponibles
              ↓
Selecciona los datos y herramientas necesarios
              ↓
Los servidores acceden a los sistemas correspondientes
              ↓
La aplicación devuelve el resultado
o solicita una aprobación

El layer, no decide qué debe hacer el modelo ni cómo debe responder. Su función se concentra en el intercambio de contexto y capacidades entre aplicaciones de inteligencia artificial y sistemas externos, un puente.

Las partes de una arquitectura MCP

MCP utiliza una arquitectura cliente-servidor formada por tres participantes principales: el host, los clientes MCP y los servidores MCP.

El host MCP

El host es la aplicación de inteligencia artificial con la que interactúa el usuario.

Pueden ser los estándares comerciales como Claude Desktop, Claude Code, Codex o un asistente desarrollado internamente pueden funcionar como hosts MCP.

El host coordina la experiencia del usuario, administra la interacción con el modelo y crea las conexiones necesarias con los servidores.

Una misma aplicación puede conectarse simultáneamente con distintos servidores: uno para documentos, otro para una base de datos y otro para un sistema administrativo.

El cliente MCP

El cliente es el componente que vive dentro del host y mantiene la conexión con un servidor determinado.

Cada cliente se conecta con un único servidor. Si una aplicación utiliza cinco servidores MCP, normalmente administra cinco clientes independientes.

Su función consiste en establecer la sesión, intercambiar mensajes, negociar las capacidades disponibles y entregar al host la información proporcionada por el servidor.

El servidor MCP

El servidor es el programa que “publica información” y funciones para las aplicaciones de inteligencia artificial.

Puede conectarse con:

una base de datos;
una API;
una carpeta de archivos;
un gestor documental;
un sistema de expedientes;
una plataforma comercial;
una aplicación desarrollada a medida.

El servidor abstrae las particularidades técnicas del sistema que se encuentra detrás y presenta sus capacidades mediante una interfaz estandarizada.

La arquitectura oficial establece que el host administra uno o varios clientes, que cada cliente mantiene una conexión dedicada y que los servidores pueden ejecutarse tanto localmente como de manera remota.

Usuario
   ↓
Host MCP
Aplicación de inteligencia artificial
   ↓
Cliente MCP
Conexión individual
   ↓
Servidor MCP
Datos y funciones disponibles
   ↓
Bases de datos, APIs, archivos
y sistemas internos

Qué puede publicar un servidor MCP

Los servidores pueden exponer tres capacidades fundamentales: recursos, herramientas y prompts.

Recursos: lo que la IA puede conocer

Los recursos representan información que una aplicación puede incorporar como contexto.

Pueden ser documentos, registros, respuestas de una API, esquemas de bases de datos, manuales, contratos, expedientes o información específica de una aplicación.

Por ejemplo, un servidor podría publicar:

el contenido de una normativa;
los antecedentes de un expediente;
los planos asociados a una obra;
el historial de un cliente;
el esquema de una base de datos;
un reporte presupuestario;
la documentación técnica de un sistema.

Los recursos permiten que la inteligencia artificial trabaje con información real y actualizada de la organización, en lugar de depender únicamente del conocimiento general incorporado durante el entrenamiento del modelo.

La especificación define los recursos como fuentes de datos contextualizadas, identificadas mediante una URI y administradas por la aplicación host según sus propias necesidades.

Herramientas: lo que la IA puede hacer

Las herramientas son funciones ejecutables que el servidor pone a disposición de la aplicación.

Por ejemplo:

buscar_obra
consultar_expediente
obtener_avance_fisico
generar_reporte
crear_orden_trabajo
preparar_notificacion

Cada herramienta declara:

su nombre;
una descripción;
los parámetros que necesita;
la estructura de los resultados;
las condiciones bajo las cuales puede utilizarse.

La aplicación puede descubrir las herramientas disponibles y presentárselas al modelo. Cuando el modelo determina que necesita una de ellas, solicita su ejecución.

Esta es la diferencia entre una inteligencia artificial que solamente responde preguntas y una inteligencia artificial que participa en una operación.

La documentación oficial define las herramientas como funciones ejecutables que permiten realizar acciones, como consultar bases de datos, invocar APIs o trabajar con archivos.

Prompts: cómo debe realizarse una tarea

Los prompts son plantillas reutilizables para estructurar interacciones frecuentes.

Una organización podría publicar prompts para:

analizar un expediente;
preparar un informe ejecutivo;
controlar documentación;
evaluar una contratación;
responder un reclamo;
redactar una comunicación institucional;
resumir la situación de un proyecto.

De esta manera, las instrucciones no quedan dispersas en conversaciones, documentos personales o prompts copiados entre empleados.

Pueden convertirse en activos administrados por la organización, con versiones, criterios comunes y procedimientos definidos.

Un MCP considera los prompts, los recursos y las herramientas como sus tres primitivas principales del lado del servidor. Los clientes pueden descubrirlas mediante operaciones de listado y, cuando corresponde, recuperarlas o ejecutarlas.

El descubrimiento de capacidades

Una de las características más importantes de MCP es que una aplicación puede consultar qué capacidades ofrece cada servidor.

Puede preguntar:

¿Qué herramientas están disponibles?

¿Qué recursos puedo consultar?

¿Qué parámetros necesita esta función?

¿Qué prompts ofrece el servidor?

El servidor responde con descripciones estructuradas.

Esto se conoce como descubrimiento de capacidades.

No significa que una aplicación pueda explorar libremente todos los sistemas de una organización. Solamente descubre aquello que los servidores conectados y autorizados decidieron publicar.

La diferencia es fundamental:

Descubrimiento no significa acceso irrestricto.

El cliente puede utilizar operaciones como tools/list para conocer las herramientas disponibles y tools/call para solicitar la ejecución de una herramienta determinada. La lista puede modificarse dinámicamente, permitiendo incorporar nuevas capacidades sin tener que programarlas manualmente dentro de cada aplicación consumidora.

Cómo se comunican los componentes

MCP utiliza mensajes estructurados basados en JSON-RPC 2.0.

Esos mensajes pueden viajar mediante dos mecanismos estándar.

Stdio

El transporte stdio se utiliza principalmente cuando el servidor se ejecuta localmente en la misma computadora.

El cliente inicia el servidor como un proceso y ambos se comunican mediante la entrada y la salida estándar del sistema.

Es una opción directa, sin comunicación por red, utilizada con frecuencia para servidores locales que acceden a archivos, herramientas de desarrollo o recursos de la computadora.

Streamable HTTP

Streamable HTTP está diseñado para servidores remotos o compartidos.

Utiliza solicitudes HTTP y puede incorporar Server-Sent Events, o SSE, para transmitir múltiples mensajes, avances o notificaciones desde el servidor hacia el cliente.

Este mecanismo reemplazó al transporte anterior conocido como HTTP con SSE. La especificación actual reconoce como transportes estándar a stdio y Streamable HTTP, aunque también permite desarrollar transportes personalizados.

La separación entre la capa de datos y la capa de transporte permite utilizar los mismos mensajes y capacidades independientemente de que el servidor se ejecute localmente o a través de una infraestructura remota.

Un ejemplo concreto: una Secretaría de Obras Públicas

Imaginemos una Secretaría de Obras Públicas que administra simultáneamente proyectos, inspecciones, contratistas, órdenes de trabajo, certificados de avance, documentación técnica, reclamos ciudadanos e informes para las autoridades.

La información necesaria para conocer el estado real de una obra rara vez se encuentra en un único sistema.

Una parte puede estar en el gestor de expedientes.

Otra, en planillas de seguimiento.

Los planos pueden almacenarse en carpetas compartidas.

Las inspecciones pueden llegar mediante formularios o informes en PDF.

Los contratos permanecen en un repositorio documental y el estado presupuestario depende de otro sistema administrativo.

Cuando un funcionario necesita saber qué está ocurriendo, debe reconstruir manualmente la situación consultando cada una de esas fuentes.

Con MCP, el organismo podría construir una capa controlada sobre sus sistemas existentes.

Recursos

El servidor podría permitir consultar:

expedientes administrativos;
contratos y pliegos;
planos y documentación técnica;
órdenes de trabajo;
informes de inspección;
certificados de avance;
normativa aplicable;
registros presupuestarios;
reclamos ciudadanos relacionados con cada obra.

Herramientas

También podría publicar funciones específicas:

buscar_obra
consultar_expediente
obtener_avance_fisico
consultar_ejecucion_presupuestaria
listar_inspecciones_pendientes
registrar_informe_inspeccion
crear_orden_trabajo
generar_reporte_autoridad
preparar_notificacion_contratista

Prompts

Finalmente, podría incorporar plantillas institucionales para:

analizar integralmente el estado de una obra;
controlar un certificado;
preparar una inspección;
identificar documentación faltante;
generar un resumen ejecutivo;
redactar una comunicación al contratista;
responder un reclamo ciudadano.

Un funcionario podría solicitar:

Mostrame las obras de pavimentación que tienen atrasos superiores a treinta días, indicá cuáles tienen inspecciones pendientes y prepará un informe para la Secretaría.

La aplicación podría consultar el sistema de obras, recuperar los expedientes relacionados, comparar el avance planificado con el registrado, identificar inspecciones pendientes y generar un informe consolidado.

Pero no debería modificar automáticamente el estado de una obra ni emitir una intimación.

Podría preparar el borrador de la comunicación, mostrar los antecedentes utilizados y solicitar la aprobación del funcionario responsable antes de registrarla en el expediente o enviarla al contratista.

La misma infraestructura podría responder una pregunta ciudadana:

¿Cuál es el estado de la obra de desagüe de mi barrio?

En ese caso, el sistema consultaría solamente la información autorizada para difusión pública, sin exponer documentos administrativos, datos sensibles o informes internos.

Una misma arquitectura podría ofrecer capacidades diferentes según la identidad y el rol de quien la utiliza.

Un inspector podría registrar avances.

Un director podría consultar indicadores consolidados.

El área administrativa podría revisar contratos y certificados.

Un ciudadano podría acceder únicamente a información pública.

El valor no está solamente en que el modelo pueda resumir un expediente.

El valor está en que el organismo transforma sistemas fragmentados, documentos y procedimientos administrativos en capacidades operativas gobernadas, reutilizables y auditables.

El problema de las integraciones individuales

Las organizaciones llevan décadas conectando sistemas mediante APIs, servicios web, integraciones personalizadas y procesos de intercambio de datos.

Estas tecnologías continúan siendo indispensables.

El problema aparece cuando cada nueva aplicación de inteligencia artificial necesita reconstruir todas las conexiones desde cero.

Supongamos que una empresa quiere conectar un asistente con:

el CRM;
el sistema contable;
la documentación interna;
una base de datos;
el correo electrónico;
el sistema de tareas.

Cada integración puede tener una autenticación diferente, una estructura de datos propia, mecanismos específicos de error y costos permanentes de mantenimiento.

Después, la empresa decide utilizar otro modelo o construir un segundo agente para una nueva área.

Cuando las conexiones están acopladas directamente a la primera aplicación, una parte importante del trabajo debe repetirse.

El estudio empresarial aportado para este artículo señala que este esquema genera fragmentación, complejidad y costos de mantenimiento crecientes. Cada nuevo sistema exige desarrollo específico, mecanismos de autenticación particulares y tratamiento individual de errores.

MCP propone separar las capacidades de la organización de la aplicación que las utiliza.

Aplicaciones y agentes de IA
               ↓
              MCP
               ↓
Capacidades de la organización
               ↓
APIs, bases de datos, documentos
y sistemas existentes

La organización deja de desarrollar una integración completamente nueva para cada combinación de aplicación, modelo y sistema.

Comienza a construir una infraestructura reutilizable.

El MCP no reemplaza las APIs

El protocolo no viene a sustituir REST, GraphQL, SQL ni los sistemas de integración existentes.

En muchos casos, un servidor MCP utiliza esas mismas tecnologías por debajo.

Aplicación de IA
       ↓
Servidor MCP
       ↓
API del sistema
       ↓
Software existente

La API continúa ejecutando la operación técnica.

MCP agrega una capa diseñada para que las aplicaciones de inteligencia artificial puedan descubrir esa operación, comprender sus parámetros y utilizarla dentro de un contexto.

Las APIs conectan aplicaciones mediante contratos técnicos.

MCP presenta datos y capacidades de una manera especialmente diseñada para aplicaciones y agentes de inteligencia artificial.

Los dos enfoques pueden convivir.

Las integraciones directas siguen siendo apropiadas para procesos altamente determinísticos, operaciones sensibles a la latencia o sistemas que exigen un control técnico rígido y predecible. El material empresarial adjunto también reconoce que las APIs tradicionales pueden ser preferibles en escenarios de máximo rendimiento y comportamiento estrictamente controlado.

La pregunta no es si una organización debe elegir entre MCP o APIs.

La pregunta es:

¿Qué capacidades de nuestros sistemas deberían estar disponibles para la inteligencia artificial, para qué usuarios y bajo qué controles?

De sistemas aislados a capacidades reutilizables

Una organización suele pensar su infraestructura en términos de aplicaciones:

el CRM;
el ERP;
la base de datos;
el gestor documental;
el sistema de expedientes;
el software contable;
las planillas.

Una arquitectura preparada para inteligencia artificial debe comenzar a pensar también en términos de capacidades:

consultar un cliente;
analizar un expediente;
verificar una deuda;
calcular un indicador;
registrar una inspección;
crear una orden;
generar un informe;
solicitar una aprobación;
preparar una notificación.

Un sistema es una aplicación.

Una capacidad es algo que la organización sabe hacer.

MCP permite representar esas capacidades para que distintas aplicaciones de inteligencia artificial puedan descubrirlas y utilizarlas de forma consistente.

Esta transformación tiene varias consecuencias.

La primera es la reutilización. Una capacidad publicada puede ser utilizada por distintos asistentes, agentes o interfaces.

La segunda es la portabilidad. La organización puede cambiar de modelo o utilizar diferentes proveedores sin reconstruir completamente su infraestructura de integración.

La tercera es la gobernanza. En lugar de otorgar acceso directo a una base de datos completa, puede publicarse una herramienta específica con parámetros, límites y permisos definidos.

La cuarta es la escalabilidad. Incorporar una nueva capacidad al servidor puede volverla disponible para varias aplicaciones conectadas, sin tener que programarla individualmente en cada una.

El análisis empresarial adjunto destaca aplicaciones concretas en gestión del conocimiento, automatización de procesos, desarrollo de software, análisis de datos y atención al cliente.

Cómo debería comenzar una implementación

Implementar MCP no consiste en instalar un servidor y conectarlo indiscriminadamente con todos los sistemas.

El trabajo comienza comprendiendo la operación.

Identificar los objetos del negocio

Primero hay que determinar qué entidades existen dentro del proceso:

clientes;
expedientes;
obras;
contratos;
pagos;
inspecciones;
reclamos;
órdenes.

Identificar las acciones

Después se definen las acciones que pueden realizarse sobre esos objetos:

consultar;
crear;
actualizar;
aprobar;
rechazar;
calcular;
notificar;
archivar.

Identificar las reglas

También deben establecerse las condiciones:

quién puede ejecutar cada acción;
qué información puede consultar cada rol;
qué operaciones requieren aprobación;
qué acciones pueden revertirse;
qué debe quedar registrado;
qué datos no deben salir de la organización.

Este trabajo se parece más al diseño de una ontología operativa que a la instalación de un chatbot.

La organización debe describir qué sabe, qué hace y bajo qué reglas puede hacerlo.

Empezar por un proceso concreto

La adopción no debería comenzar intentando conectar toda la empresa.

Un buen caso inicial suele tener tres características:

se repite con frecuencia;
utiliza información fragmentada;
produce un resultado que puede medirse.

Las primeras capacidades pueden limitarse a la lectura:

consultar documentos;
recuperar expedientes;
localizar antecedentes;
obtener indicadores;
resumir estados de procesos.

Después pueden incorporarse acciones de bajo riesgo:

crear un borrador;
preparar una comunicación;
generar una tarea;
completar un formulario;
proponer una actualización.

Finalmente, pueden habilitarse operaciones que modifican sistemas, comprometen recursos o producen efectos jurídicos y económicos.

Estas últimas deben incorporar validaciones, permisos y aprobaciones humanas.

El estudio empresarial adjunto recomienda una adopción gradual: comenzar con un piloto limitado, validar su utilidad, ampliar las integraciones y recién después avanzar hacia un despliegue productivo con controles de seguridad, monitoreo y gobernanza.

La seguridad no viene resuelta por el protocolo

MCP estandariza la comunicación, pero no garantiza por sí solo que una implementación sea segura.

La especificación proporciona un marco de autorización para transportes HTTP basado en estándares OAuth. Sin embargo, la autorización continúa siendo opcional para las implementaciones, por lo que utilizar MCP no equivale automáticamente a tener resueltos la identidad, los permisos o el cumplimiento normativo.

Una implementación empresarial debe definir deliberadamente:

Identidad

El sistema debe saber quién realiza cada solicitud.

No es suficiente registrar que una herramienta fue utilizada. Debe conocerse el usuario, la aplicación y el contexto desde el cual se produjo la operación.

Menor privilegio

Cada usuario, agente y herramienta debe acceder solamente a la información estrictamente necesaria.

Un servidor destinado a consultar el avance de obras no debería recibir acceso administrativo completo a la base de datos.

Separación entre lectura y escritura

Consultar un expediente no debe otorgar automáticamente permiso para modificarlo.

Las herramientas de lectura y las herramientas de escritura deben diseñarse y autorizarse por separado.

Aprobación humana

Las acciones sensibles deben mostrar qué se ejecutará, qué información se utilizará y qué sistema será modificado antes de solicitar una confirmación.

Validación

Los parámetros recibidos, los documentos recuperados y los resultados generados deben verificarse.

La salida de una herramienta no debería considerarse automáticamente confiable solo porque proviene de un servidor autorizado.

Aislamiento

Los servidores deben operar con acceso limitado a archivos, redes, procesos y credenciales.

Auditoría

Cada invocación debe registrar, cuando corresponda:

la identidad del usuario;
la herramienta utilizada;
los parámetros;
el resultado;
el sistema afectado;
la autorización concedida;
la fecha y hora.

Inventario

La organización debe conocer qué servidores existen, qué herramientas publican, qué versiones se encuentran desplegadas y quién es responsable de mantenerlas.

El informe de seguridad aportado advierte que los sistemas MCP introducen riesgos vinculados con invocaciones dinámicas, relaciones de confianza implícitas, filtraciones de contexto y ausencia de controles de acceso suficientemente granulares.

También identifica ataques mediante manipulación de herramientas, instrucciones ocultas y propagación de contenido malicioso entre componentes. En flujos con varios agentes, el resultado de una herramienta puede convertirse en la entrada de otra, permitiendo que una instrucción maliciosa se propague a través de toda la cadena.

Por eso, el mismo informe recomienda tratar cada salida como una entrada potencialmente no confiable, registrar todas las invocaciones e integrar esa telemetría con los sistemas de monitoreo y respuesta de la organización.

Cuando una IA solamente genera texto, una equivocación puede producir una respuesta incorrecta.

Cuando puede modificar bases de datos, crear órdenes o enviar comunicaciones, una equivocación puede convertirse en un incidente operativo.

No se trata de conectar la IA con todo

La promesa de MCP no consiste en otorgar a un agente acceso irrestricto a cada sistema de la organización.

Consiste en construir una capa donde cada capacidad sea publicada deliberadamente.

Una herramienta bien diseñada no debería ser:

ejecutar_sql

Debería ser algo como:

consultar_obras_atrasadas
obtener_estado_expediente
generar_resumen_presupuestario
crear_borrador_notificacion

Cuanto más específica es una herramienta, más sencillo resulta:

definir sus permisos;
validar sus parámetros;
anticipar sus efectos;
controlar su utilización;
registrar lo ocurrido.

El objetivo no es que la inteligencia artificial pueda hacer cualquier cosa.

El objetivo es que pueda realizar determinadas acciones, dentro de límites claros y verificables.

La infraestructura alrededor del modelo

Las organizaciones ya poseen gran parte de los activos necesarios para utilizar inteligencia artificial.

Tienen datos.

Tienen sistemas.

Tienen documentos.

Tienen procedimientos.

Tienen personas con experiencia.

El problema es que ese conocimiento se encuentra fragmentado.

Una parte vive en una base de datos.

Otra, en archivos.

Otra, en planillas.

Otra, en aplicaciones antiguas.

Otra, en la memoria de los empleados.

MCP puede funcionar como una capa común para presentar ese conocimiento y esas operaciones a las aplicaciones de inteligencia artificial.

Pero el protocolo es solamente una pieza.

Para obtener valor real también se necesita:

arquitectura de datos;
interoperabilidad;
modelado de procesos;
identidad y permisos;
observabilidad;
gobierno de herramientas;
diseño de aprobaciones;
seguridad operativa.

No se trata de instalar otro chatbot.

Se trata de construir infraestructura.

MCP como infraestructura organizacional

En Atlas Analytica no pensamos MCP como un conector aislado ni como una tecnología vinculada a un único modelo.

Lo pensamos como una pieza dentro de una arquitectura mayor.

Una arquitectura donde los sistemas dejan de funcionar como islas y comienzan a publicar capacidades utilizables por personas, aplicaciones y agentes de inteligencia artificial.

El trabajo no comienza preguntando qué chatbot debe instalarse.

Comienza preguntando:

¿Qué sabe la organización?

¿Qué acciones puede realizar?

¿Dónde se encuentra la información?

¿Qué reglas deben respetarse?

¿Quién puede ejecutar cada operación?

¿Qué debe quedar bajo control humano?

A partir de esas respuestas es posible construir servidores MCP, recursos contextualizados, herramientas específicas, prompts institucionales, sistemas de permisos y registros de auditoría.

No se trata de reemplazar el software existente.

Se trata de hacerlo interoperable con una nueva generación de aplicaciones inteligentes.

Porque la próxima ventaja competitiva no estará únicamente en acceder al modelo más avanzado.

Estará en haber construido la infraestructura que le permita comprender cómo funciona la organización y actuar sobre ella de manera segura.