AI agents (MCP)
An AI agent such as Claude works with OMDS LD through the Model Context Protocol (MCP). It gets the operations of the OpenAPI file as tools and works through a process by following the next steps of the answers. It needs no state model of its own for that.
Status of implementation: the MCP server is a reference implementation. The example server runs one per example insurer.
One server per insurer, the same software
Every insurer has its own MCP server, just as it has its own interface. All of them are the same software: the MCP server of the norm in front of the interface of the insurer concerned. It contains nothing that applies to one insurer only.
| What | From where |
|---|---|
tools, their names, descriptions and inputs |
from the OpenAPI file of the norm, the same for all insurers |
whether the tools of the draft are offered |
from the process knowledge of the insurer ( |
products, components, attributes, premiums |
from the answers of the insurer |
address of the interface, display name |
from the configuration of the instance |
Another insurer needs only another instance with the address of its interface. The insurer can run it itself, next to its interface over HTTP. A broker or its software house can equally run it locally in front of the interface of an insurer.
With several servers registered, the agent calls the same tools at several insurers, for instance for a comparison. The client tells them apart by the name of the server.
Tools
-
One tool per operation. The name is the
operationId, the same one the answers name in their next steps (bc:operation). The description comes from the OpenAPI file. -
Inputs.
-
the path and query parameters of the operation, such as
caseId,product,date; -
body: the request schema of the operation in the canonical form. The server adds@contextand@typeif they are missing, and checks the body against the schema before the call. -
idempotencyKey(optional) for operations withIdempotency-Key: a second call with the same key gets the answer of the first and changes nothing. -
full(optional): the complete JSON-LD answer of the insurer as well.
-
-
Draft at the server. The server offers the creation, the edits and the inquiries on the business object only if the insurer holds the draft at the server. Otherwise the agent calculates through the tariff inquiry (
inquireTariff) with a complete instance. -
Condensed answers. Instead of the complete graph, the model gets:
-
the business case;
-
the draft as a tree with the IRIs of its nodes and the components that can be included;
-
the attributes with value and admissible range;
-
the risk objects and the validation report;
-
the premium;
-
the next steps as "tool ·
bc:target· expected shapes"; -
the fields of the shapes a next step expects, such as those of a vehicle.
-
-
Errors are tool errors with the problem type of the norm, the explanation and the operations still admissible. A rejected request changes nothing.
Setup
On the example server every example insurer has its MCP server at
https://kapdion.com/omds-ld/insurers/<name>/mcp, over Streamable HTTP. In Claude Code:
claude mcp add --transport http disrupto https://kapdion.com/omds-ld/insurers/disrupto/mcp
claude mcp add --transport http angloamerican https://kapdion.com/omds-ld/insurers/angloamerican/mcp
claude mcp add --transport http pfefferminzia https://kapdion.com/omds-ld/insurers/pfefferminzia/mcp
Without a client of your own: the chatbot at https://chatbot.kapdion.com has the MCP servers of the three example insurers connected.
Locally in front of an interface, the server starts as a process over stdio:
claude mcp add pfefferminzia -- node reference/mcp-server/dist/index.js --stdio --api http://localhost:9092/omds-ld/api --name Pfefferminzia
In Claude Desktop the same call goes into the configuration file under mcpServers, with command (node) and
args.
Example
Task for the agent: "Calculate the motor insurance at Pfefferminzia for a Skoda, built 2021, 110 kW, list price 32,000 euros, number plate W-12345A."
-
listProducts– the product Kraftfahrt 2025. -
createCalculationwithp:hasRootProduct– the business case with the default instance as draft. Among the next steps iscreateRiskObjectwith the shapes of the vehicle. -
createRiskObjectwith the vehicle – the risk object is created and assigned to the instance. -
calculatePremium– the draft is complete, the answer states the premium.
The agent knew no process in advance. Every step was in the answer before it.
With an insurer without a draft at the server, such as Disrupto, the next steps lead through the tariff inquiry:
-
listProducts– the product Kraftfahrt 2022 with the next stepreadDefaultInstance. -
readDefaultInstance– the default instance as a ready body of the tariff inquiry. The next stepinquireTariffnames the shapes of the vehicle. -
inquireTariffwith this body and the vehicle as another node – the answer states the premium.
Checking with scenarios
A scenario checks whether an agent completes a process with the tools and the next steps alone. It consists of a task in natural language, the MCP server of an insurer and fixed criteria. A run gives a protocol of all tool calls with their results, tokens and costs.
A run passes if
-
an answer contains a premium with a conforming validation report,
-
the agent called only edits that a previous answer offered as next step,
-
every IRI of its inputs appeared before in the task, a tool description or an answer,
-
the final answer names every assumption the agent made without the task stating it, such as the registration district,
-
the final answer states the premium correctly
-
and the run stays within a fixed budget.
The grading needs no model; it reads the protocol. Because a model does not answer word for word the same in every run, the share of passed runs over several runs counts. The agent gets only a short instruction without knowledge of process, products or vocabulary. A scenario thus checks the norm, not the instruction.