Guide: Using the ITB MCP server for AI-powered test development

Track	Test Bed setup

This guide walks you through the process of setting up and using the Interoperability Test Bed’s (ITB) Model Context Protocol (MCP) server to enhance your test development and configuration workflows using AI agents.

Pairing an AI agent with the ITB MCP server gives it direct access to authoritative ITB documentation, covering all aspects of test development and configuration. Rather than switching context to search for reference material, you can use natural language to ask your AI agent to carry out tasks or answer questions directly within your development environment, significantly streamlining how you work with the ITB.

What you will achieve

At the end of this guide you will have set up your AI agent to use the ITB MCP server and will have carried out your first AI-assisted ITB tasks. As part of this guide you will:

1. Understand how AI agents and MCP servers work together.

2. Understand what the ITB MCP server provides.

3. Configure your AI agent to connect to and use the ITB MCP server.

4. Use your AI agent to carry out practical ITB-related tasks using natural language.

What you will need

• About 15 to 30 minutes, depending on your familiarity with configuring AI agents.

• An AI agent installed and configured on your workstation. Examples include Claude Desktop, Claude Code, Cursor, or VS Code with an MCP-compatible extension such as Cline or Continue.

• An active subscription or connection to a Large Language Model (LLM) that supports the use of MCP servers.

• A continuous internet connection to access the ITB MCP server during your sessions.

Note

Using the MCP server as background infrastructure: Although this guide focuses on configuring the ITB MCP server on a developer’s workstation, MCP servers can equally be used as part of shared or automated infrastructure, for example within a CI/CD pipeline or a team-shared agent environment. The configuration process in such cases is very similar to what is described here, differing mainly in where configuration files are placed and managed.

How to complete this guide

This guide is structured as a sequence of steps that build on one another. The first step provides background context on AI agents and MCP servers and can be skimmed or skipped if you are already familiar with these concepts. From Step 2 onwards the guide is hands-on, walking you through the configuration of the ITB MCP server and demonstrating how to use it with practical examples you can reuse or adapt for your own work.

Steps

Carry out the following steps to complete this guide.

Step 1: Understand how AI agents can help test development

Note

This is an optional step providing background context. If you are already familiar with AI agents and MCP servers you can skip directly to Step 2: Configure the ITB MCP server.

An AI agent is a software system that combines a Large Language Model (LLM) with the ability to take actions on your behalf. Unlike a simple chatbot that only produces text responses, an AI agent can use tools - such as executing commands, reading files, calling APIs, or browsing documentation - to complete tasks autonomously. When you describe what you want to achieve, the agent reasons about the steps required, calls its available tools as needed, and reports back the outcome.

The Model Context Protocol (MCP) is an open standard that allows AI agents to connect to external services and use them as tools. An MCP server exposes a set of capabilities - typically domain-specific data retrieval or actions - that the agent can invoke during its reasoning. This makes it straightforward to extend an AI agent with authoritative, up-to-date knowledge from any domain, without needing to embed that knowledge in the model itself.

The ITB MCP server provides AI agents with direct access to the ITB’s official documentation, covering all aspects of working with the Test Bed. By connecting your agent to this server, it can look up accurate, current information on any ITB topic before carrying out a task. This results in more reliable and better-informed assistance, particularly for tasks that require precise configuration or adherence to ITB-specific conventions.

The topics covered by the ITB MCP server span the full breadth of ITB work, including:

• Test development and configuration - authoring GITB TDL test suites and test cases for conformance testing, defining actors, using built-in handlers, and working with XPath expressions.

• Validator setup and configuration - creating and deploying standalone validators for XML, JSON, RDF and CSV content, including their REST and SOAP API usage.

• ITB instance management - deploying and operating a self-hosted ITB instance, configuring communities, managing test suites, and using the ITB REST API for automation.

• General information - background on the ITB’s purpose, typical use cases, and answers to commonly asked questions to help you decide whether and how to adopt the ITB in your project.

Step 2: Configure the ITB MCP server

The ITB MCP server is a publicly accessible, stateless HTTP MCP server available at https://www.itb.ec.europa.eu/mcp. It requires no authentication - there are no API tokens or custom headers to configure.

The exact configuration steps depend on the AI agent you are using. In general you will need to register the ITB MCP server as a remote HTTP MCP server in your agent’s configuration, providing the server’s URL. The following sub-sections illustrate how this is done for common agents.

Configuring Claude Code

Claude Code is a command-line AI agent that can be configured to use MCP servers by running a single command from your terminal:

claude mcp add --transport http itb-mcp https://www.itb.ec.europa.eu/mcp

This registers the ITB MCP server in Claude Code’s configuration under the name itb-mcp. To verify that it has been added correctly, run:

claude mcp list

The server should appear in the output with its URL. Once listed, the ITB MCP server will be available in all subsequent Claude Code sessions without further configuration.

Configuring Claude Desktop

Claude Desktop can be configured to use MCP servers by editing its configuration file. Locate the file at one of the following paths depending on your operating system:

• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

• Windows: %APPDATA%\Claude\claude_desktop_config.json

Claude Desktop connects to remote HTTP MCP servers via the mcp-remote package, which acts as a local bridge. This requires Node.js (which provides the npx command) to be installed on your workstation.

Add the ITB MCP server to the file’s mcpServers section, creating the section if it does not exist:

{
    "mcpServers": {
        "itb-mcp": {
            "command": "npx",
            "args": ["mcp-remote", "https://www.itb.ec.europa.eu/mcp"]
        }
    }
}

Save the file and restart Claude Desktop. To verify the server has loaded correctly, open a new conversation and check for the MCP tools indicator in the interface, or ask Claude directly whether it has access to the ITB MCP server.

Configuring Cursor

Cursor uses a JSON configuration file to register MCP servers. Create or edit the file mcp.json in the ~/.cursor/ folder for a global configuration, or in a .cursor/ folder at the root of your project for a project-scoped one:

{
    "mcpServers": {
        "itb-mcp": {
            "url": "https://www.itb.ec.europa.eu/mcp"
        }
    }
}

Configuring GitHub Copilot

GitHub Copilot supports MCP servers through its agent mode in VS Code. To register the ITB MCP server, create or edit the file .vscode/mcp.json at the root of your project:

{
    "servers": {
        "itb-mcp": {
            "type": "http",
            "url": "https://www.itb.ec.europa.eu/mcp"
        }
    }
}

Alternatively, the server can be added to your VS Code user settings under the mcp.servers key. Once configured, the ITB MCP server will be available to GitHub Copilot in agent mode.

For other MCP-compatible clients, refer to their respective documentation for how to register a remote HTTP MCP server. The key information to provide in all cases is the server URL: https://www.itb.ec.europa.eu/mcp.

Available tools and topics

The ITB MCP server exposes the following two tools to the connected AI agent:

Tool	Description
list_topics	Returns all available ITB documentation topics with their identifiers, names, and descriptions. The agent calls this first to discover which topics are available before requesting detailed documentation.
get_documentation	Returns authoritative documentation, code examples, normative schemas, and configuration references for a specific ITB topic. The agent passes a topic identifier obtained from list_topics to retrieve the relevant content.

The documentation available through these tools covers the following areas:

Topic	Description
General information	High-level background and overview of the ITB, including its value proposition, typical use cases, and a curated FAQ.
ITB deployment	Deploying and configuring a self-hosted ITB instance, including Docker and Docker Compose setup, reverse proxy configuration, and upgrade procedures.
ITB REST API	Programmatic interaction with a running ITB instance, covering test execution, result retrieval, domain and community management, and common automation workflows.
ITB user guide	Guidance for ITB and community administrators on managing domains, specifications, test suites, organisations, and system-wide configuration.
Standalone validators	Setting up, configuring, and using standalone validators for XML, JSON, RDF, and CSV content, including their REST and SOAP API usage.
TDL test authoring	Authoring GITB TDL test suites and test cases for conformance testing, covering all step types, built-in handlers, variable scoping, and deployment.

Once your agent is configured, you can verify that the ITB MCP server is correctly connected by issuing the following prompt:

List all available ITB documentation topics.

If the server is working correctly, the agent will invoke the MCP server and return a list of the six available topics shown in the table above.

Step 3: Use the ITB MCP server

With the ITB MCP server configured, your AI agent is ready to assist with any ITB-related task. Depending on the agent you use, it may automatically identify the ITB MCP server as relevant based on the content of your prompt. If it does not, you can instruct it explicitly by referencing the server at the start of your session:

Use the ITB MCP server to help me with the following task: ...

In general, using the ITB MCP server is entirely natural language driven - you describe what you want to achieve and the agent handles the rest, consulting the server’s documentation as needed. To get the best results, it helps to be specific in your prompts. Mentioning ITB-specific terms such as “GITB TDL test suite”, “standalone JSON validator”, or “ITB REST API” makes it easier for the agent to identify the relevant topic and retrieve the most appropriate documentation.

The following examples illustrate the kinds of tasks you can carry out. Informational prompts such as Example 6 can be used as shown; prompts that create files or interact with a running ITB instance should be adapted to include your local context, such as file paths, the ITB URL, and API credentials.

Example 1: Create a standalone validator with sample content

Prompt:

Create a standalone ITB JSON validator based on the JSON Schema files in 'myProject/schemas'. Configure
one validation type per schema file and generate a sample valid and invalid file for each type.

Outcome:

The agent creates the validator’s folder structure and all necessary configuration files tailored to your project, along with sample content files for each configured validation type ready for immediate testing.

Example 2: Create a GITB TDL test suite

Prompt:

Create a TDL test suite with actors Producer (the SUT) and Receiver (the ITB) with an initial test case
whereby the SUT is expected to send via HTTP POST a valid JSON purchase order. Upon receiving this the
Receiver validates it against the JSON schema at 'schemas/PurchaseOrder.json' and succeeds if validation
passes.

Outcome:

The agent produces the test suite folder and a deployable archive, complete with the correct actor definitions, test case structure, messaging step, and validation call, along with any additional setup instructions needed to deploy and run it.

Example 3: Start a local ITB instance and deploy test suites

Prompt:

My ITB instance runs via the Docker Compose file in the current folder and is available at
http://localhost:9000. The REST API key is stored in the environment variable ITB_API_KEY. Start the
instance if it is not already running, then deploy all latest test suite versions from folder 'testSuites'
and report any validation errors or warnings.

Outcome:

The agent uses Docker to start the ITB, waits for it to become available, uses the ITB REST API to deploy all test suite versions, and verifies that no validation errors or warnings were reported during deployment.

Example 4: Execute tests and check for failures

Prompt:

Using my ITB instance at http://localhost:9000 and the API key in environment variable ITB_API_KEY,
execute all tests for system 'My System' defined in its conformance statement to specification
'My Specification' and tell me if any tests fail. Prompt me for any required API keys in REST API calls.

Outcome:

The agent uses the ITB REST API to trigger all test sessions, monitors their completion, and reports any failures or issues found in the execution logs. Whenever API keys are required that the agent cannot retrieve itself it requests them from the user providing instructions on where to retrieve them from.

Example 5: Install a development ITB instance

Prompt:

Install a local development ITB instance for me using Docker Compose in the current directory.

Outcome:

The agent installs a local ITB instance with default configuration and provides a summary of how it can be used, along with the recommended next setup steps.

Example 6: Get guidance on the ITB’s fit for your project

Prompt:

Explain to me when the ITB would be a good fit in my project.

Outcome:

The agent consults the ITB’s general information documentation and produces a summary of the ITB’s added value, typical use cases, and relevant DOs and DON’Ts to help you evaluate its suitability.

Full example: Create an XML validator

As a complete example on how to use the ITB MCP server, we will use it in Claude Code to create an XML validator for our project’s specifications. As in other tutorials, we will consider a fictional purchase order specification for the definition of XML-based purchase orders.

As first step, create a folder to be your workspace, for example /workspace. Within this we will add a resources subfolder to contain our current validation artefacts, notably an XML schema (PurchaseOrder.xsd) and Schematron rule file (LargePurchaseOrder.sch). Download these files and place them in /workspace/resources to result in the following file structure:

workspace/
└── resources/
    ├── LargePurchaseOrder.sch
    └── PurchaseOrder.xsd

Once you have configured Claude Code to use the MCP server, open a new session in /workspace and issue the following prompt:

I want you to create a validator for XML data based on the ITB's XML validator. Here are the guidelines to consider:
- This is a validator for Purchase Orders.
- The validator should define two profiles for validation (basic and large).
- My schemas are located in folder 'resources'. The basic profile uses the XSD, and the large profile uses the XSD and SCH.
- Add a banner to the validator summarising the options and linking to the project Wiki (available at https://wiki.po.europa.eu).
- Create for each profile a valid and invalid sample.
- Start the validator, test it to see it works as expected, and tell me how to access it.

Once issued you will see Claude beginning to work towards completing its task.

While proceeding with its work, and depending on its configured permissions, the agent will proceed to query the MCP server and ask you for permission to do certain tasks when needed. In the end the agent will complete its task with a summary of the results.

The exact files generated, file names, and locations may vary given that the prompt we used was not that specific. In general though the resulting files will match more or less the following - a fully complete and correct validator setup as prompted:

workspace/
├── docker-compose.yml
└── resources/
    ├── PurchaseOrder.xsd
    ├── LargePurchaseOrder.sch
    └── order/
        ├── config.properties
        ├── xsd/
        │   └── PurchaseOrder.xsd
        ├── sch/
        │   └── LargePurchaseOrder.sch
        └── examples/
            ├── basic-valid.xml
            ├── basic-invalid.xml
            ├── large-valid.xml
            └── large-invalid.xml

In addition, as you instructed the agent to start and test the validator, you will find in the end the service up and running for you to try out yourself and extend as needed.

Summary

Congratulations! You have set up the ITB MCP server on your AI agent and carried out your first AI-assisted ITB tasks. In doing so you:

• Understood how AI agents and MCP servers work together, and what the ITB MCP server makes available to a connected agent.

• Configured the ITB MCP server in your AI agent, enabling it to access authoritative ITB documentation across all areas of ITB-related work.

• Explored practical examples of prompts for tasks covering test suite authoring, validator setup, ITB instance management, and general guidance.

Your AI agent can now assist you across the full breadth of ITB-related work, using accurate and up-to-date documentation as its reference. As you grow familiar with the topics covered, you will be able to compose increasingly specific prompts to get the most out of each session.

See also

To make the most of your AI agent’s ITB capabilities, the following guides and references provide hands-on detail on the areas covered by the ITB MCP server.

If your focus is conformance testing, start with the developer onboarding guide. You can then follow the step-by-step tutorials on:

• Creating a first simple test suite.

• Developing tests to check simple message exchanges.

• Developing tests to cover complex messaging needs.

• Setting up your test configuration on the Test Bed.

• Executing tests.

For test development work make sure to also keep handy the reference documentation for:

• The GITB Test Description Language for authoring test cases.

• The GITB test services for creating custom test extensions.

If you are interested in using the Test Bed’s reusable components to define standalone validators you are invited to check:

• The XML validation guide using XML Schema and Schematron.

• The RDF validation guide using SHACL shapes.

• The JSON validation guide using JSON Schema.

• The CSV validation guide using Table Schema.

Finally, for further general information, news and resources, the best source is the Interoperability Test Bed page on the Interoperable Europe Portal.