Tutorial sobre el Protocolo de Contexto de Modelo MCP

Si llevas un tiempo trasteando con agentes de IA, LLMs y asistentes tipo Copilot o Claude, seguro que has visto siglas como MCP por todas partes y quizá no te haya quedado del todo claro qué es. No eres la única persona: es un concepto relativamente nuevo, tiene mucha chicha técnica y la documentación oficial, aunque buena, puede resultar densa si solo quieres entender cómo encaja en tus proyectos.

En este artículo vamos a bajar todo eso a tierra. Verás qué es exactamente el Model Context Protocol, por qué se ha vuelto tan importante, cómo funciona por dentro y cómo puedes usarlo para conectar tus modelos de lenguaje con herramientas reales: desde un repositorio Git local hasta Google Drive, Google Calendar, sistemas internos en Azure o aplicaciones de escritorio como Claude Desktop. También repasaremos ventajas, limitaciones, seguridad, ejemplos prácticos y cómo construir tu propio servidor MCP.

Qué es el Model Context Protocol (MCP) y por qué se habla tanto de él

El Model Context Protocol (MCP) es un estándar abierto diseñado para que los modelos de IA puedan comunicarse de forma uniforme con herramientas, datos y servicios externos. La idea viene de Anthropic (la compañía detrás de Claude), pero el protocolo está pensado para ser agnóstico: no pertenece a un proveedor ni a un modelo concreto.

La comparación que más se repite, y que es bastante acertada, es que MCP es al software lo que el USB o el USB‑C es al hardware. Igual que no quieres un cable distinto para cada dispositivo, tampoco quieres una integración ad hoc para cada API, CRM, base de datos o servicio con el que tu agente de IA necesita hablar. MCP funciona como un “adaptador universal” para que los modelos puedan acceder a contexto del mundo real.

Antes de MCP, cada vez que querías que tu asistente de IA hablara con, por ejemplo, tu sistema de tickets, tu CRM o tu wiki, tenías que montar integraciones a medida, con mucho código pegamento y poca reutilización. Cada herramienta, su JSON, su autenticación, su forma de devolver los datos. MCP intenta romper este caos ofreciendo una forma estandarizada de describir herramientas, recursos y flujos de mensajes.

Esto encaja de maravilla con la tendencia actual hacia las llamadas Agentic Apps o aplicaciones agénticas: sistemas donde uno o varios modelos de lenguaje no solo responden mensajes, sino que razonan, planifican, llaman a herramientas, consultan fuentes de datos y orquestan tareas de forma más o menos autónoma.

Arquitectura básica de MCP: hosts, clientes, servidores y capacidades

Para entender MCP de verdad merece la pena interiorizar sus piezas principales. El protocolo define una arquitectura con tres roles básicos y tres tipos de capacidades que se exponen desde los servidores.

En cuanto a los roles, MCP distingue:

• Hosts: cualquier aplicación que usa uno o varios LLMs y que quiere ampliar sus capacidades mediante MCP. Puede ser un IDE como VS Code, un editor de código como Zed o Replit, una app de escritorio, un servicio web o un agente corporativo en producción.
• Clients: componentes que se encargan de hablar con el servidor MCP en nombre del host. Gestionan la conexión, descubren qué herramientas hay disponibles, resuelven recursos y manejan el intercambio de mensajes.
• Servers: procesos que exponen capacidades MCP estandarizadas: tools, resources y prompts. Por debajo, se conectan a fuentes de datos locales (un sistema de archivos, un repositorio Git, un fichero markdown con un prompt o una base de datos instalada en la misma red) o remotas (APIs HTTP, servicios cloud, SaaS).

En la práctica, puedes imaginar el flujo así: el host ejecuta un cliente MCP, que se conecta a uno o varios servidores MCP; esos servidores, a su vez, “envuelven” APIs, bases de datos, servicios de terceros o datos internos de la empresa, transformando todo eso en capacidades normalizadas que la IA puede usar.

Dentro de esa arquitectura aparecen también dos conceptos importantes de origen de datos:

• Local Data Sources: fuentes locales al servidor, como el sistema de ficheros, un repositorio Git, un fichero markdown con un prompt o una base de datos instalada en la misma red.
• Remote Services: servicios remotos accesibles por red: APIs REST, servicios cloud como Google Drive, Zoom, Slack, CRM corporativos, historiales médicos electrónicos, etc.

La gracia de MCP es que, para el modelo de IA y para el host, da igual si la información viene de un fichero local, de GitHub o de una API corporativa: siempre llega encapsulada con el mismo tipo de mensajes y la misma estructura.

Capacidades MCP: tools, resources y prompts

La unidad básica de funcionalidad en MCP es lo que el protocolo llama capacities o capacidades. Hay tres tipos y cada uno cubre un aspecto distinto de la interacción entre el modelo y el entorno.

Tools son, en esencia, funciones que el modelo puede invocar. El servidor las expone de forma estructurada (nombre, descripción, parámetros), y el LLM decide si quiere o no llamar a esa herramienta y con qué argumentos. Por ejemplo: “listar commits recientes”, “crear un evento en el calendario”, “buscar documentos en Drive”, “consultar un CRM” o “ejecutar una consulta SQL”.

Resources representan información contextual que la aplicación considera útil y que suele inyectarse en los prompts sin que el modelo la pida explícitamente. Por ejemplo, un resumen del estado de un repositorio, las últimas métricas de ventas, el historial de un paciente o la descripción de un proyecto. Los recursos pueden ser estáticos o generarse dinámicamente a partir de una URI o plantilla.

Prompts son plantillas de instrucciones reutilizables que el servidor pone a disposición del host o del usuario. Pueden definir, por ejemplo, el rol que debe adoptar el modelo (“actúa como experto en Git”), la estructura de las respuestas o un formato específico para trabajar con cierto dominio. Permiten estandarizar la forma en que se guía al modelo sin tener que reescribir los mismos textos una y otra vez.

Esta división tiene un efecto práctico muy potente: diferencia claramente lo que el modelo decide por sí mismo (llamar a tools), de lo que la aplicación le proporciona de antemano (resources y prompts). Esa separación ayuda tanto a nivel de diseño de agentes como de seguridad y auditoría.

Un ejemplo práctico: servidor MCP para explorar un repositorio Git

Una buena forma de aterrizar MCP es ver un ejemplo concreto. Imagina que quieres crear una pequeña aplicación de línea de comandos donde chateas con un LLM y este, cuando lo necesite, pueda inspeccionar un repositorio Git local para responder mejor: ver el estado, revisar commits recientes, entender la estructura del proyecto, etc.

Siguiendo el enfoque descrito en algunos tutoriales de referencia, podrías montar algo así con un servidor MCP implementado en Python utilizando la SDK oficial. Ese servidor expondría:

• Una tool para obtener el estado actual del repositorio (archivos modificados, añadidos, eliminados).
• Otra tool para listar los últimos N commits (por ejemplo 50) con autor, fecha y mensaje.
• Un resource que devuelva un resumen textual de alto nivel del repositorio (carpetas principales, tecnologías usadas, tamaño aproximado…), generado a partir del sistema de archivos y de la información de Git.
• Un prompt guardado en un fichero markdown que describe cómo debe comportarse el modelo como “explorador de repositorios Git” y cómo debe usar las herramientas disponibles.

Para interactuar con Git, el servidor podría apoyarse en la librería GitPython, que facilita recorrer commits, ramas y estado sin tener que llamar al binario de Git directamente. Los comentarios de los métodos pueden aprovecharse para generar de forma implícita la metainformación de cada tool: qué hace, qué parámetros acepta, etc.

En este escenario, el servidor hablaría con el host a través de un transporte sencillo, por ejemplo stdio (entrada/salida estándar). Es una opción muy cómoda para pruebas y flujos de trabajo locales o para integrarlo con aplicaciones de escritorio, porque solo hay que lanzar el proceso y comunicarte con él como si fuera cualquier programa de consola.

Cliente MCP, cliente de modelo y aplicación “agéntica”

En el otro extremo de ese ejemplo tenemos la parte que se ejecuta en tu máquina como usuario: una Agentic App que orquesta todo. Esta aplicación suele componerse de tres piezas bien diferenciadas.

Por un lado, hace falta un cliente de modelo (ModelClient), que encapsula cómo hablas con el LLM concreto que uses (OpenAI, Claude, otro proveedor o incluso un modelo self‑hosted). Este cliente gestiona llamadas de chat completion, manejo de herramientas en formato del proveedor, tokens, etc. Conviene definir una interfaz común para que, en el futuro, cambiar de modelo sea tan simple como cambiar la implementación.

Por otro lado, se necesita un cliente MCP que hable con el servidor Git que acabamos de describir. Este componente se encarga de:

• Conectarse al servidor usando el transporte elegido (por ejemplo stdio).
• Descubrir las capabilities disponibles: tools, resources y prompts.
• Cachear esa información para no estar preguntando al servidor todo el rato por cosas que no cambian.
• Resolver recursos dinámicos, por ejemplo generando URIs a partir de plantillas (resource templates) para, digamos, obtener el resumen de un repositorio concreto.

Por último, la pieza que lo une todo es el agente o Agent, una clase que gestiona el bucle principal de la aplicación: leer la petición del usuario, construir el contexto, enviar la consulta al modelo, ejecutar herramientas cuando el LLM lo pida y devolver una respuesta final.

Un ciclo típico podría ser:

1. Leer la consulta del usuario desde la terminal.
2. Construir el prompt del sistema combinando la plantilla MCP y el resource con el resumen del repo.
3. Construir el mensaje de usuario con la pregunta introducida.
4. Adjuntar al mensaje la lista de tools proporcionadas por el cliente MCP.
5. Enviar todo al LLM mediante el cliente de modelo.
6. Analizar la respuesta: si el modelo solicita ejecutar una tool, llamar al servidor MCP, obtener el resultado y reenviarlo al modelo para que refine su respuesta.
7. Imprimir la respuesta final al usuario y volver a pedir la siguiente pregunta.

Este diseño deja claro por qué MCP encaja tan bien con las Agentic Apps: separa la lógica de orquestación (el agente) de la integración con el modelo y de la integración con las herramientas. Cada pieza tiene su rol, y MCP actúa como contrato estable para todas las herramientas y fuentes de datos que quieras añadir.

Cómo funciona MCP internamente: flujo de solicitud y respuesta

Aunque no hace falta saberse la especificación de memoria para usar MCP, viene bien tener claro el flujo clásico de request/response que sigue el protocolo entre un host y un servidor.

Imagina una situación típica: un asistente de IA que quiere revisar tus eventos de hoy en el calendario. El flujo sería algo así:

• El modelo detecta que le has pedido algo que requiere datos externos y genera una solicitud MCP para la herramienta apropiada (por ejemplo, “obtener eventos de hoy”).
• El cliente MCP empaqueta esa solicitud según las reglas del protocolo y la envía al servidor asociado.
• El servidor MCP traduce la petición a la API subyacente (por ejemplo, Google Calendar, Exchange u otro sistema), la ejecuta y obtiene los datos.
• El servidor devuelve la respuesta al cliente MCP en formato estándar MCP, con los datos organizados y listos para que el modelo los entienda.
• El host entrega esa respuesta al LLM, que la integra en su razonamiento y genera la contestación final al usuario.

La misma dinámica se aplica a casos más complejos: resumen de una reunión de Zoom, recuperación de documentos desde Google Drive, análisis de datos médicos combinando imagen y registros del paciente, etc. Lo importante es que el modelo no tiene que saber nada de cada API: siempre habla el “idioma MCP”.

Esta abstracción se vuelve crucial cuando quieres que un agente llame a múltiples herramientas en cascada: por ejemplo, recuperar un historial de cliente desde un CRM, usar esos datos para generar una propuesta comercial, almacenarla en Drive y luego programar una reunión en el calendario para revisarla. Con MCP, todo eso se hace a través de un mismo esquema de mensajes y herramientas, sin reinventar la rueda en cada integración.

Seguridad, autenticación y cumplimiento normativo en MCP

Uno de los puntos críticos cuando permites que un modelo de IA acceda a sistemas reales es la seguridad: qué datos puede ver, qué puede hacer con ellos y cómo se autentica. MCP ha sido diseñado con estos temas en mente y normalmente se apoya en mecanismos de autenticación estándar.

Entre los más frecuentes están:

• OAuth 2.0: muy usado para servicios como Google, Microsoft o Slack. MCP delega en OAuth, que actúa como “portero digital”: el usuario concede permisos específicos (lectura de calendario, acceso a ciertos archivos, etc.) y el servidor MCP usa esos tokens para actuar en nombre del usuario.
• Tokens de API: típicos de muchos servicios SaaS o APIs internas. El servidor MCP puede requerir un token concreto para acceder a un determinado backend y el host lo proporciona de forma segura.
• Acceso basado en roles: además de autenticar, interesa autorizar. MCP puede integrarse con sistemas de roles para que no todas las herramientas estén disponibles para todos los usuarios, o para limitar qué partes de una API son accesibles desde los agentes.

En ámbitos regulados (sanidad, finanzas, sector público) también entra en juego el cumplimiento de normativas como GDPR, SOC 2 o certificaciones ISO. Aunque MCP no “cumple” per se con nada (es solo un protocolo), su diseño facilita encapsular los accesos siguiendo estas normas: puedes auditar las llamadas, controlar qué datos salen del entorno, cifrar el tráfico y establecer políticas claras de acceso.

Por ejemplo, una empresa puede exponer historias clínicas electrónicas a través de un servidor MCP interno, pero limitar estrictamente qué herramientas están disponibles, qué campos de cada registro se devuelven y quién puede invocar esas tools. El agente de IA sigue viendo un conjunto homogéneo de herramientas, pero por debajo hay mucha gobernanza y control.

Aplicaciones reales de MCP: desde desarrollo hasta visión artificial

Lejos de ser una teoría bonita, MCP ya se está utilizando en un buen abanico de escenarios del mundo real. Estos son algunos de los más interesantes.

En desarrollo de software, editores como Zed o plataformas como Replit comienzan a usar MCP para que sus asistentes de código puedan leer archivos del proyecto, seguir cambios en tiempo real, inspeccionar logs o interactuar con sistemas de control de versiones. Para el editor, el asistente deja de estar “a ciegas” y pasa a entender qué hay realmente en tu repositorio.

En entornos empresariales, muchas compañías conectan sus wikis internos, sistemas de help desk, CRMs o bases de conocimiento a asistentes de IA mediante MCP. Así, un agente puede responder a preguntas de soporte, generar informes, sugerir acciones comerciales o procesar tickets consultando siempre datos actualizados y específicos de la organización.

Otro ámbito en expansión son los asistentes de escritorio que trabajan con datos locales. La aplicación de escritorio de Claude, por ejemplo, utiliza MCP para acceder de forma segura a ficheros en tu máquina sin tener que subirlos a la nube. Esto permite cosas tan útiles como resumir documentos, buscar fragmentos relevantes o ayudarte con código que tienes en local.

Y, aunque todavía está en una fase temprana, hay bastante movimiento en aplicar MCP a proyectos de visión artificial con fuerte componente de contexto. Por ejemplo, en diagnóstico médico: un asistente puede coordinar modelos de visión para analizar imágenes (radiografías, retinas, etc.) mientras consulta historiales clínicos, resultados de laboratorio y ensayos clínicos en paralelo, todo ello a través de herramientas expuestas por servidores MCP.

MCP en el ecosistema Google: Drive, Calendar y reuniones

Otro bloque donde MCP encaja como anillo al dedo es el ecosistema Google Workspace. La idea básica es desplegar un servidor MCP que actúe como puente con las APIs de Google Drive y Google Calendar para que la IA pueda buscar documentos, resumirlos, clasificarlos, crear eventos, gestionar recordatorios, etc.

En el caso de Google Drive, un servidor MCP bien diseñado puede permitir a un modelo de IA:

• Realizar búsquedas de documentos usando lenguaje natural (“tráeme el informe de ventas del último trimestre”).
• Leer el contenido de esos documentos y generar resúmenes, bullets de acción o comparativas entre versiones.
• Etiquetar y organizar automáticamente archivos en carpetas según su contenido (contratos, currículums, notas de reuniones…).
• Gestionar permisos de acceso, siempre que existan reglas claras y bien configuradas de seguridad.

La configuración típica pasa por habilitar la API de Google Drive en Google Cloud Console, crear credenciales, indicar al servidor MCP cómo autenticarse (normalmente vía OAuth) y definir qué operaciones están permitidas (solo lectura, lectura y escritura, etc.). Una vez montado, cualquier host compatible con MCP puede aprovechar ese servidor sin tener que saber nada de los detalles de Google.

Con Google Calendar la lógica es parecida. Un servidor MCP especializado puede:

• Leer eventos del calendario de uno o varios usuarios.
• Encontrar huecos compatibles entre agendas y proponer automáticamente horarios para reuniones.
• Crear, mover o cancelar eventos en función de las decisiones del agente.
• Generar recordatorios de seguimiento basados en lo que se haya hablado en una reunión anterior.

A nivel de experiencia de usuario, esto se traduce en que puedes decirle a tu asistente algo tipo: “Busca media hora la semana que viene para hablar con Marta sobre el proyecto X” y, gracias a MCP, el agente comprueba agendas, propone una franja horaria y crea la invitación con el enlace de videollamada correspondiente.

Un paso más allá es cuando combinas Calendar, Drive y plataformas de videoconferencia: la IA puede recuperar el contexto previo (documentos, correos, notas), ayudarte durante la reunión y generar resúmenes y tareas al terminar, todo ello utilizando el mismo protocolo y distintas herramientas MCP por debajo.

Reuniones inteligentes: videollamadas conectadas con MCP

Las reuniones son uno de los campos donde más rápidamente se ve el valor de MCP, porque hay mucho trabajo manual repetitivo: tomar notas, extraer acciones, compartir resúmenes, actualizar el CRM, etc. Integrar plataformas como Zoom, Google Meet o Microsoft Teams vía MCP abre la puerta a automatizar casi todo ese ciclo.

Un agente de reuniones potenciado por MCP puede:

• Transcribir automáticamente las conversaciones en tiempo real.
• Detectar decisiones clave, elementos de acción, acuerdos y dudas pendientes.
• Enviar resúmenes a Slack, email, Notion o al gestor de tareas de tu empresa.
• Actualizar registros de clientes en el CRM y generar correos de seguimiento.

La lógica es similar a la que veíamos antes: hay un servidor MCP que habla con la API de la plataforma de videoconferencia (para obtener grabaciones, transcripciones u otros metadatos) y otro servidor que integra herramientas como Drive, Slack, CRM, etc. El host (por ejemplo, una app tipo “copiloto de reuniones”) orquesta todas esas llamadas.

En la práctica, para la mayoría de usuarios finales todo esto se esconde detrás de interfaces amigables creadas por terceros. Hay herramientas que “conducen por la autopista MCP” por ti: tú solo conectas tus cuentas (calendario, Zoom, CRM) y marcas cuatro opciones, mientras que por debajo se están haciendo varias llamadas MCP a distintos servidores.

El resultado es un ecosistema donde la IA ya no se limita a generar texto, sino que acciona directamente sobre tu entorno digital: programa, documenta, ordena, recuerda y coordina. MCP es la capa que permite que todas esas integraciones mantengan cierto orden en lugar de convertirse en un monstruo de integraciones difíciles de mantener.

Servidores MCP remotos en Azure y Foundry: integrando sistemas internos

En entornos corporativos, muchas veces el problema no es conectar con Google o Zoom, sino con sistemas internos que no exponen MCP de serie: APIs privadas, servicios legacy, microservicios de negocio. Para estos casos, una estrategia habitual es montar servidores MCP remotos sobre infraestructura cloud.

Un patrón muy interesante consiste en usar Azure Functions para alojar un servidor MCP. Azure Functions ofrece un modelo serverless con escalado a cero, escalado bajo demanda y fácil integración con identidades gestionadas y redes privadas. La idea es:

1. Inicializar un proyecto desde una plantilla de servidor MCP (por ejemplo con la CLI de Azure Developer, usando algo tipo azd init –template remote-mcp-functions-python).
2. Definir en el código de la Function las distintas tools MCP que exponen tus APIs internas: por ejemplo, “consultar pedidos pendientes”, “crear incidencias”, “lanzar un flujo de facturación”.
3. Configurar autenticación adecuada: claves de función, OAuth, identidad administrada, etc.
4. Desplegar el servidor MCP con azd up y anotar el endpoint MCP y las claves necesarias.

Opcionalmente, puedes registrar ese servidor MCP en Azure API Center para crear un catálogo de herramientas privado a nivel de organización. Esto facilita compartirlo entre equipos, añadir gobernanza (quién puede usar qué), adjuntar documentación y configurar políticas de autenticación centralizadas.

Una vez registrado, servicios como Microsoft Foundry Agent Service pueden descubrir ese servidor MCP desde el catálogo o mediante configuración manual (herramienta MCP personalizada). A partir de ahí, los agentes de Foundry pueden llamar a las tools expuestas para interactuar con sistemas empresariales internos a través de una interfaz MCP estandarizada.

Si algo falla en la conexión (errores de autenticación, endpoints incorrectos, tools no encontradas), el diagnóstico suele pasar por revisar los logs de Azure Functions, validar claves y confirmar que el servidor MCP expone correctamente el esquema y las herramientas que el agente espera.

Construir tu propio servidor MCP: lenguajes, SDKs y requisitos

Si después de todo esto te pica el gusanillo y quieres montar un servidor MCP personalizado, la buena noticia es que ya existen SDKs oficiales y de la comunidad para varios lenguajes. Entre los más destacados están:

• TypeScript / JavaScript
• Python
• Java
• Kotlin
• C#
• Y proyectos comunitarios en Go, entre otros

Independientemente del lenguaje que elijas, los ingredientes básicos que vas a necesitar son:

• Ciertos conocimientos de programación y APIs para modelar las tools y resources de forma clara.
• Acceso a las APIs o fuentes de datos que quieras exponer (APIs web, bases de datos, sistemas internos, ficheros…).
• Un mecanismo de autenticación y autorización robusto (OAuth, tokens, claves internas…) adaptado a tu entorno.
• Un entorno de ejecución estable (puede ser serverless como Azure Functions, un contenedor en Kubernetes, una VM, etc.).

El flujo de trabajo suele ser: definir qué problema quieres resolver (por ejemplo, centralizar acceso a datos de clientes), diseñar las tools MCP que representarán las operaciones clave, codificar el servidor, probarlo en local con un cliente MCP de ejemplo y, finalmente, exponerlo para que hosts reales (como asistentes de escritorio, agentes corporativos o IDEs) puedan conectarse.

Con el tiempo, es muy probable que veamos más herramientas low‑code/no‑code sobre MCP que permitan a perfiles menos técnicos montar servidores sencillos arrastrando y soltando bloques: conectar una API, definir una tool, adjuntar un prompt y listo. Pero, de momento, el camino pasa casi siempre por algo de código.

Ventajas, limitaciones y futuro de MCP

Después de ver tantos detalles, merece la pena recapitular qué aporta MCP y qué peajes tiene. Entre las ventajas más claras están:

• Una forma coherente y estandarizada de conectar modelos de IA con herramientas y datos, que reduce la deuda técnica de las integraciones ad hoc.
• Mayor modularidad: puedes cambiar el backend de una tool (por ejemplo, pasar de un CRM a otro) sin que el host ni el modelo tengan que cambiar su lógica.
• Facilita que los agentes de IA sean realmente autónomos y multi‑herramienta, llamando a distintas tools según su razonamiento, sin flujos rígidos programados a mano.
• Alinea muy bien con arquitecturas modernas donde los LLM se convierten en orquestadores de acciones sobre sistemas empresariales.

En el lado de las limitaciones y retos, hay que tener presentes varios puntos:

• La configuración inicial de servidores y hosts MCP sobre sistemas existentes puede ser laboriosa. Muchas arquitecturas habrá que repensarlas para aprovechar bien el protocolo.
• Introducir una capa de protocolo implica algo de sobrehead y latencia, sobre todo si los servidores MCP se reparten por varias redes o clouds.
• Existe una curva de aprendizaje tanto para equipos de backend como para quienes diseñan agentes: hay que entender cómo se modelan las tools, cómo se gestionan los recursos y cómo se orquesta el flujo.

A pesar de ello, todo apunta a que MCP va a consolidarse como pieza clave en la forma en que diseñamos y desplegamos asistentes de IA. Grandes laboratorios como Anthropic, OpenAI y Google DeepMind están alineando sus productos para soportar el protocolo, y proveedores como Microsoft ya lo integran en sus plataformas corporativas.

A medida que madure el ecosistema de servidores MCP (tanto oficiales como de la comunidad), veremos un catálogo cada vez mayor de “plugins” listos para conectar agentes con casi cualquier cosa: desde repositorios educativos como el del MIT de deep learning, hasta sistemas de ventas, salud, retail o administración pública. Y, con ello, la IA pasará cada vez más de responder en abstracto a actuar de forma informada sobre el contexto real de cada usuario y de cada organización.