Bridging LLM Agents and Data Spaces: An Architectural Mediation Approach using MCP

What it claims

An external MCP server can expose a Data Space connector (the Eunomia Agent, an open-source data space agent from UPM) to LLM agents as three typed tools, without changing the connector. Identity verification, contract negotiation and policy enforcement are meant to stay in Eunomia; the mediation layer only translates calls. The authors evaluated three alternatives and rejected each:

• Exposing the REST APIs directly as tools. Agents would misuse multi-step protocol semantics.
• Embedding AI extensions in Eunomia. This couples a standards-based component to fast-moving AI tooling.
• Auto-generating wrappers from API specs. This leaves the semantic gap between tool calls and protocol workflows unsolved.

How it works

The server speaks MCP over JSON-RPC on stdio and calls Eunomia only through its public HTTP APIs. Eunomia models datasets and services in DCAT-AP 3.0. The data service endpoint is resolved from that metadata through dcat:accessService. Configuration such as the provider base URL comes from environment variables.

list_datasets is paginated and filterable so that catalogs with thousands of entries do not fill the model's context. query_data_service maps tool inputs to query parameters and relays the response without transforming it. No tool performs contract negotiation.

flowchart LR
  C[MCP client / LLM] -- stdio JSON-RPC --> M[Mediation server]
  M -- list / metadata --> E[Eunomia catalog API]
  E -- DCAT-AP endpoint --> M
  M -- GET with params --> S[Data service endpoint]
  E -. negotiation, SSI, policy .- X[not called by mediation layer]

Evidence

The evaluation is functional only. It ran on a single machine with these components:

• one Eunomia provider instance;
• one dataset, "MCP Evaluation Dataset", linked to a mock HTTP service that returns synthetic JSON;
• a deterministic client with no LLM.

The client ran a fixed sequence:

1. Tool discovery.
2. list_datasets, taking the first result.
3. get_dataset_metadata, taking the first service.
4. query_data_service with fixed parameters.

The authors say the run tests correctness, protocol compliance and feasibility, not performance or semantic quality. They also claim integration with a production MCP client, but the fetched text does not name it or report any result from it. The fetched text ends at the methodology, so no outcomes, latencies or numbers are available.

How to use it

The source code for the Eunomia agent and the MCP server is said to be open source (refs [13] and [14]). The links and licences are not in the fetched text, so check them yourself. The design suits read-only, GET-based data services already registered with DCAT metadata.

Limits

• stdio is a development deployment model only. It assumes a trusted execution environment. The authors propose SSE or HTTPS MCP for production, with authentication and service identity, but did not implement or test it.
• Only catalog publication and metadata discovery were exercised. Self-Sovereign Identity, dataplane coordination and contract negotiation were outside the scope.
• Governance preservation is not demonstrated. query_data_service calls the service endpoint directly with agent-supplied parameters. Whether access control applies on that path depends on the service itself. If you rely on the governance claim, verify this path.
• No real LLM was used. Tool-selection behaviour, prompt misuse and errors in parameter construction are untested.
• Scope is small. There are only three tools, all GET, so there are no write or transfer flows.