Funcional

MCP - Model Context Protocol

Esta página recoge la documentación funcional del MCP (Model Context Protocol) de Anjana Data Platform. Describe qué es, cómo se integra con la plataforma y qué operaciones de gobierno del dato y de la IA pueden realizarse conversacionalmente a través de un asistente de IA, así como los perfiles de usuario a los que da servicio.

Visión general

El MCP es el servidor que expone las capacidades de gobierno de Anjana Data Platform a asistentes de IA mediante el estándar abierto Model Context Protocol. Actúa como puente entre un cliente de IA compatible y el núcleo de gobierno de la plataforma (Kerno) junto con el de auditoría (minerva), de modo que las tareas habituales del Portal de Datos —descubrir activos, consultar su detalle y linaje, catalogar y enriquecer metadatos, enviar a validación, solicitar acceso a datoso consultar la audotiría — pueden ejecutarse en lenguaje natural desde el propio asistente.

El MCP no sustituye al Portal de Datos ni introduce un canal de gobierno paralelo: opera a través de las mismas API, reglas y flujos de trabajo que la interfaz gráfica. Toda operación realizada mediante el MCP respeta el modelo de permisos del usuario, el ciclo de aprobación de la plataforma y el registro de auditoría, garantizando que el gobierno conversacional sea tan trazable y controlado como el manual.

El MCP dentro del modelo de gobierno

El MCP hereda íntegramente el modelo de gobierno de Anjana Data Platform. Comprender estos tres principios es imprescindible antes de operar con él:

  • Ciclo de vida controlado, todo activo creado o modificado a través del MCP nace en estado DRAFT y debe enviarse a validación (submit). La aprobación final la realiza siempre una persona con el rol adecuado en la plataforma; el MCP no aprueba activos.

  • Control de acceso por roles (RBAC), cada operación se ejecuta con la identidad y los permisos del usuario autenticado. Las acciones para las que el usuario no está autorizado se rechazan, y cierta información solo se devuelve si el usuario dispone del permiso correspondiente.

  • Trazabilidad completa, toda acción queda registrada en el log de auditoría con autor, fecha, tipo de acción y activo afectado, del mismo modo que si se hubiera realizado desde el Portal de Datos.

Requisitos y acceso

El uso del MCP requiere las siguientes condiciones:

  • Cliente de IA compatible con MCP, configurado para conectarse al servidor MCP de Anjana Data Platform.

  • Usuario autenticado en la plataforma, con las credenciales gestionadas a través de Zeus. El asistente opera siempre en nombre de ese usuario.

  • Permisos y roles adecuados, según la operación que se desee realizar. Las capacidades de consulta requieren acceso al Catálogo; las de catalogación, enriquecimiento o envío a validación requieren los roles de gobierno correspondientes (por ejemplo steward, architect o data owner).

image-20260724-135508.png
Autenticación vía MCP
image-20260724-135652.png
Autenticación para uso del MCP
JSON
{
    "mcpServers": {
      "anjana-data": {
        "type": "http",
        "url": "https://<url_entorno>/mcp"
      }
    }
  }

 Accesibilidad de red y responsabilidades

Configurar el cliente de IA con el bloque anterior es cuanto debe hacer el usuario. Ahora bien, el MCP solo será operativo si la organización garantiza que el endpoint del servidor MCP (https://<url_entorno>/mcp) es accesible desde el cliente de IA, del mismo modo que el acceso general a Anjana Data Platform requiere que lo sea https://<url_entorno>/login.

Anjana Data SL provee únicamente la capacidad MCP. Su habilitación, exposición y securización recaen en el cliente: la publicación del servicio, los controles de red (cortafuegos, segmentación) y las políticas de acceso son responsabilidad de la organización. En particular, los entornos que exijan cero exposición a internet deberán adoptar una alternativa acorde a sus políticas —por ejemplo, un cliente o agente de IA local que opere en la red interna de la empresa—.


Capacidades del MCP

Las capacidades del MCP se agrupan en seis áreas funcionales. En todos los casos el usuario formula la petición en lenguaje natural y el asistente invoca la operación correspondiente sobre la plataforma.

  • Búsqueda de activos, localización de datasets, DSAs, procesos, soluciones, instancias y tipos de entidad personalizados mediante texto libre, con filtros por tipo y estado y paginación de resultados.

  • Consulta de detalle, obtención de todos los atributos de un activo, sus metadatos (autor, fechas, versión, estado), propietarios y usuarios adheridos.

  • Consulta del formulario de un activo, revisión de los atributos editables, sus tipos y reglas de validación antes de proponer cambios.

image-20260724-140124.png
Descubrimiento de activos del Catálogo mediante lenguaje natural

Linaje y relaciones

  • Consulta de linaje, visualización de las conexiones upstream y downstream de un activo dentro del grafo de gobierno.

  • Consulta de relaciones, obtención de las relaciones de un activo agrupadas por tipo: directas, de composición (jerarquía padre-hijo) e indirectas (derivadas de la composición).

image-20260724-140217.png
Consulta de linaje de un activo: activos de origen y destino relacionados

Catalogación y enriquecimiento de metadatos

  • Alta de activos, creación de datasets, campos de dataset, procesos, soluciones, instancias, DSAs o cualquier otro, que se generan en estado DRAFT.

  • Enriquecimiento de metadatos, actualización de los atributos de un activo (descripción, dominio, sensibilidad del dato, fechas y demás campos definidos en el metamodelo).

  • Envío a validación, remisión de un activo en borrador al flujo de aprobación de la plataforma, indicando el rol con el que se realiza la solicitud.

image-20260727-071813.png
Alta y enriquecimiento de un dataset y sus fields desde el asistente y posterior envío a validación
image-20260727-072836.png
Desde la Actividad del usuario se verifica la creación y envío a validar de los datasets creados por el MCP


Gestión de relaciones

  • Creación de relaciones, establecimiento de vínculos entre activos aprobados (por ejemplo, la asociación de términos de negocio a un dataset), que se crean en estado DRAFT y se envían a validación.

  • Enriquecimiento de relaciones, actualización de los atributos de una relación existente.

image-20260727-073957.png
Alta y enriquecimiento de relaciones desde el asistente y posterior envío a validación
image-20260727-074115.png
Desde la Actividad del usuario se verifica la creación y envío a validar de las relaciones creadas por el MCP


Tramitación de accesos a datos (Marketplace / DSA)

  • Solicitud de acceso, adherencia del usuario a un DSA (Data Sharing Agreement) indicando el rol de adherencia, equivalente a tramitar el acceso desde el Marketplace.

  • Baja de adherencia, retirada de la adherencia propia a un DSA; la retirada de la adherencia de otro usuario requiere permisos de administración.

  • Consulta de contrato y adherentes, obtención de la información contractual del DSA (vigencia, descripciones…) y del listado de usuarios adheridos y solicitudes pendientes.

  • Consulta de roles disponibles, obtención de los roles que el usuario puede emplear al solicitar acceso.

image-20260727-085714.png
Solicitud de acceso a datos mediante la adherencia a un DSA

Auditoría y trazabilidad

  • Consulta del log de auditoría, búsqueda de eventos filtrando por usuario, activo, tipo de acción y rango temporal, con indicación de quién hizo qué, cuándo y sobre qué activo.

  • Comparación de versiones, identificación de los atributos de negocio que cambiaron entre las dos últimas versiones aprobadas de un activo, útil cuando el log de auditoría no detalla el cambio concreto.

  • Consulta de roles del usuario, verificación de los roles asignados al usuario en la plataforma.

image-20260727-095755.png
Auditoría de un Dataset

Flujos de trabajo por perfil

El MCP da servicio a perfiles de usuario con necesidades distintas. La siguiente tabla resume los flujos más habituales de cada uno:

Perfil

Objetivo principal

Capacidades del MCP que utiliza

Responsable de gobierno del dato o de la IA

Catalogar activos, enriquecer metadatos, gestionar relaciones y linaje, y enviar a validación de forma ágil.

Alta y enriquecimiento de activos, gestión de relaciones y términos, envío a validación, consulta de linaje y auditoría de cambios.

Usuario final (consumidor de datos)

Descubrir activos en el Catálogo, conocer su detalle y solicitar acceso a datos.

Búsqueda y consulta de detalle, consulta de linaje y relaciones, y tramitación de accesos a DSAs.

Auditor / responsable de control de riesgos

Verificar la trazabilidad de las acciones, revisar cambios y comprobar quién accede a qué datos.

Consulta del log de auditoría, comparación de versiones, consulta de adherentes de DSAs y de linaje.

Tipos de entidad y estados

El MCP opera sobre los tipos de entidad y relación definidos en el metamodelo de la plataforma. Ver Comprender y trabajar con los activos gobernados

Cada activo transita por los estados del flujo de gobierno (DRAFT - borrador, PENDING - pendiente de aprobación, APPROVED - aprobado, DEPRECATED - descontinuado, REJECTED - rechazado, ..). El MCP puede crear y modificar activos en borrador y enviarlos a validación, pero la transición a APPROVED o REJECTED corresponde siempre a una persona autorizada mediante un workflow de aprobación que se ejecuta en la interfaz de usuario de la plataforma.

Buenas prácticas y consideraciones de seguridad

  • Revisión antes de enviar a validación, se recomienda comprobar los metadatos generados o modificados por el asistente antes de remitirlos al flujo de aprobación.

  • Principio de mínimo privilegio, el asistente solo puede realizar las operaciones autorizadas para el usuario; las capacidades disponibles dependen de sus roles y permisos.

  • Aprobación humana en el punto de control, la validación de activos y relaciones permanece siempre bajo responsabilidad de una persona, preservando la separación de funciones.

Limitaciones y consideraciones

  • El MCP no aprueba activos ni relaciones; únicamente permite crearlos, enriquecerlos y enviarlos a validación.

  • La creación de relaciones e instancias exige que los activos implicados estén en estado APPROVED.

  • La comparación de versiones requiere que el activo tenga al menos dos versiones aprobadas; no refleja cambios entre guardados dentro de un mismo borrador.

  • La visibilidad de determinada información (por ejemplo, adherencias pendientes de un DSA) depende de los permisos del usuario.

Esta sección está dirigida a responsables de gobierno del dato y de la IA, a usuarios finales que descubren y solicitan acceso a activos del Catálogo, y a auditores y responsables de control de riesgos que necesitan trazabilidad sobre las acciones realizadas en la plataforma.