Quarkus MCP Testing for Java Developers: McpAssured + IBM Bob

Go beyond smoke tests and verify the real MCP contract: schemas, tool errors, prompts, resources, and stateful agent workflows.

In the first part of this series, we built a real Quarkus MCP server and connected it to IBM Bob. The server exposed tools, resources, resource templates, and prompts over Streamable HTTP. We also added one smoke test that posted raw JSON-RPC to /mcp and checked that tools/list returned our tool names.

That test proved something important, but only one thing. It proved the server starts, accepts MCP traffic, and survives the initialization handshake. That is useful. It is not enough.

Most developers test agent-facing servers the same way they test REST endpoints. They verify the endpoint is reachable, maybe they assert a status code, and then they move on. That mental model breaks fast with MCP. Your caller is not a deterministic frontend or a handwritten CLI. Your caller is an agent that reads your tool descriptions, reasons from your JSON Schema, calls tools in runtime-generated sequences, and then keeps building on whatever came back.

This changes the failure mode. A REST bug usually fails close to the request that caused it. An MCP bug often fails one or two steps later. saveNote accepts a blank key, Bob thinks the note was saved, then a later resources/read returns “not found,” and now you are debugging the wrong part of the workflow. The original bug is gone from the surface.

So this tutorial is about contract testing, not just protocol smoke testing. We replace the hand-rolled JSON-RPC test with McpAssured, the Quarkiverse testing library built for MCP servers. The Quarkus MCP Server docs describe McpAssured as the integration testing utility for MCP servers, with fluent assertions, transport support for SSE, Streamable HTTP, and WebSocket, batch testing, and raw message inspection. The same docs also show the dedicated quarkus-mcp-server-test dependency and the newConnectedStreamableClient() entry point we’ll use here.

Prerequisites

This tutorial builds directly on the Dev Toolkit MCP server from Part 1. You need the existing project because we are testing the tools, resources, resource templates, and prompts we already built there.

• Java 21

• Maven 3.9+ (Gradle users can run the same tests with the equivalent test tasks; this tutorial shows Maven commands.)

• The completed dev-toolkit-mcp project from Part 1. “Completed” means you have finished all Part 1 steps and have a running MCP server with the old smoke test in place. The complete Part 1 code is available at the GitHub repository; use the same Quarkus and quarkus-mcp-server versions as in that project so the test client and server protocols align.

• Basic Quarkus testing knowledge

Use the same Java package as your Part 1 MCP server (e.g. com.example.mcp) for the test classes below, or adjust the package in the snippets to match your project. If your Part 1 server exposes a different number of tools or prompts, update the counts and names in the tests (e.g. the assertEquals(5, page.size()) for tools and assertEquals(2, page.size()) for prompts).

Project Setup

We are not creating a new application here. Copy the dev-toolkit-mcp project from Part 1 to a new dev-toolkit-mcp-test. You can find the new repository with the changed tests on my Github.

Add the MCP test dependency to your pom.xml. Make sure it aligns with the quarkus-mcp-server version:

        <dependency>
            <groupId>io.quarkiverse.mcp</groupId>
            <artifactId>quarkus-mcp-server-test</artifactId>
            <version>1.10.3</version>
            <scope>test</scope>
        </dependency>

McpAssured supports SSE, Streamable HTTP, and WebSocket clients, and for a Streamable HTTP server like the docs show McpAssured.newConnectedStreamableClient() as the right client to create.

That is all we need for setup. No extra port configuration, no manual handshake code, no raw HTTP session management.

Before we continue, delete or archive the raw JSON-RPC smoke test from Part 1 if you still have it. Remove the test class that posts raw JSON-RPC to /mcp (e.g. a class named like RawMcpSmokeTest or McpSmokeTest in src/test/java/...). Keep it in Git history if you want. Do not keep it as your main verification strategy. It is too low level and too shallow for a server that an agent will drive.

Implementation

Replace raw JSON-RPC plumbing with a real MCP test client

The old smoke test did everything by hand. It built JSON request bodies as strings. It posted them to /mcp. It extracted the Mcp-Session-Id header manually. It string-matched the response body to check whether our tools were there.

That works, but only in the same way that curl | grep works. It proves bytes crossed the wire. It does not prove the MCP contract is right. It also makes tests harder to read, harder to maintain, and harder to debug when they fail.

Here is the first replacement test. Create src/test/java/com/example/mcp/DevToolkitMcpTest.java:

package com.example.mcp;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertNotNull;

import org.junit.jupiter.api.Test;

import io.quarkiverse.mcp.server.test.McpAssured;
import io.quarkus.test.junit.QuarkusTest;

@QuarkusTest
class DevToolkitMcpTest {

    @Test
    void allToolsShouldBeRegistered() {
        var client = McpAssured.newConnectedStreamableClient();
        try {
            client.when()
                    .toolsList(page -> {
                        assertEquals(5, page.size());
                        assertNotNull(page.findByName("toUpperSnakeCase"));
                        assertNotNull(page.findByName("countOccurrences"));
                        assertNotNull(page.findByName("base64Transform"));
                        assertNotNull(page.findByName("truncate"));
                        assertNotNull(page.findByName("saveNote"));
                    })
                    .thenAssertResults();
        } finally {
            client.disconnect();
        }
    }
}

This is a better test for a few reasons. First, it reads in MCP terms, not HTTP terms. We ask for toolsList, not for a POST request with a manually encoded JSON body. Second, failures are named. If saveNote disappears, the assertion fails at findByName("saveNote"). Third, this test is already running through an MCP-aware client that performs the session lifecycle correctly. The Quarkiverse docs explicitly call out that McpAssured speaks the transport-specific protocol and provides a fluent, typed assertion model for integration tests.

What this guarantees is simple: the tool registry is present and visible to a real MCP client. What it does not guarantee is that the schemas are correct or that the tools behave correctly. So we keep going.

Test the toUpperSnakeCase tool like Bob would use it

A tool that looks trivial is often where agent bugs start. The model sees the description, chooses the tool, and passes user content into it. That means weird whitespace, empty strings, and malformed input are normal. They are not edge cases in agent workflows. They are daily traffic.

Add this test to the same class:

 @Test
    void toUpperSnakeCaseShouldHandleNormalAndEdgeInput() {
        var client = McpAssured.newConnectedStreamableClient();
        try {
            client.when()
                    .toolsCall("toUpperSnakeCase",
                            java.util.Map.of("input", "my variable name"),
                            r -> {
                                assertFalse(r.isError());
                                assertEquals("MY_VARIABLE_NAME",
                                        r.content().get(0).asText().text());
                            })
                    .toolsCall("toUpperSnakeCase",
                            java.util.Map.of("input", "  spaces everywhere  "),
                            r -> {
                                assertFalse(r.isError());
                                assertEquals("SPACES_EVERYWHERE",
                                        r.content().get(0).asText().text());
                            })
                    .toolsCall("toUpperSnakeCase",
                            java.util.Map.of("input", ""),
                            r -> {
                                assertFalse(r.isError());
                                assertEquals("", r.content().get(0).asText().text());
                            })
                    .thenAssertResults();
        } finally {
            client.disconnect();
        }
    }

And update the imports:

import static org.junit.jupiter.api.Assertions.assertFalse;

This test is small, but it makes behavior explicit. Empty input is not a crash. It is not a null. It is not a tool error. It returns an empty string. That is a contract now.

This matters because Bob will reason from the returned text. If the tool suddenly returned null, or threw an exception that became a protocol error, the next step in the chain changes. The tool result is not just output. It is part of the model’s working context.

Test base64Transform on both the success path and error path

This is where MCP testing stops looking like REST testing.

In MCP, tool failures and protocol failures are not the same thing. The official MCP specification says tool execution errors belong inside the successful JSON-RPC result object with isError: true, while protocol errors are reserved for issues like malformed requests, unsupported operations, or unknown tools. The spec also explains why: clients can expose tool execution errors to the model so it can self-correct. Protocol errors are much less useful for recovery. (Model Context Protocol)

That is not a small detail. It is the difference between “the server is broken” and “the tool understood the call but rejected the input.”

Add this test:

 @Test
    void base64TransformShouldSucceedAndFailGracefully() {
        var client = McpAssured.newConnectedStreamableClient();
        try {
            client.when()
                    .toolsCall("base64Transform",
                            java.util.Map.of("input", "hello world", "operation", "encode"),
                            r -> {
                                assertFalse(r.isError());
                                assertTrue(r.content().get(0).asText().text()
                                        .contains("aGVsbG8gd29ybGQ="));
                            })
                    .toolsCall("base64Transform",
                            java.util.Map.of("input", "aGVsbG8gd29ybGQ=", "operation", "decode"),
                            r -> {
                                assertFalse(r.isError());
                                assertTrue(r.content().get(0).asText().text()
                                        .contains("hello world"));
                            })
                    .toolsCall("base64Transform",
                            java.util.Map.of("input", "hello", "operation", "explode"),
                            r -> {
                                assertTrue(r.isError());
                                assertTrue(r.content().get(0).asText().text()
                                        .contains("Unknown operation"));
                            })
                    .thenAssertResults();
        } finally {
            client.disconnect();
        }
    }

And add the missing import:

import static org.junit.jupiter.api.Assertions.assertTrue;

What this guarantees is that the tool can complete valid work and report invalid business input without breaking the session. What it does not guarantee is that your descriptions and schemas are good enough for the model to choose the tool correctly. We test that next.

Verify that the model-facing schema is actually useful

A tool that exists but has a vague description is not production-ready. A tool that has a missing or misleading schema is worse. The model decides whether a tool is relevant based on the published contract, not based on your Java implementation.

The Quarkus MCP Server docs make this explicit in a different way: tools are discovered and validated at build time, and JSON Schema generation plus parameter validation are automatic parts of the server model. That means the published tool definition is not incidental. It is the interface.

Add this test:

 @Test
    void toolSchemasShouldBeCompleteAndDescriptive() {
        var client = McpAssured.newConnectedStreamableClient();
        try {
            client.when()
                    .toolsList(page -> {
                        var truncateTool = page.findByName("truncate");
                        assertNotNull(truncateTool);
                        assertNotNull(truncateTool.description());
                        assertFalse(truncateTool.description().isBlank());
                        assertNotNull(truncateTool.inputSchema());

                        var countTool = page.findByName("countOccurrences");
                        assertNotNull(countTool);
                        assertNotNull(countTool.description());
                        assertFalse(countTool.description().isBlank());
                        assertNotNull(countTool.inputSchema());
                    })
                    .toolsCall("truncate",
                            java.util.Map.of("input", "a".repeat(200), "maxLength", 10),
                            r -> {
                                assertFalse(r.isError());
                                String result = r.content().get(0).asText().text();
                                assertTrue(result.length() <= 10);
                                assertTrue(result.endsWith("..."));
                            })
                    .toolsCall("countOccurrences",
                            java.util.Map.of("text", "banana", "substring", "an"),
                            r -> {
                                assertFalse(r.isError());
                                assertEquals("2", r.content().get(0).asText().text());
                            })
                    .thenAssertResults();
        } finally {
            client.disconnect();
        }
    }

This test does two different jobs. It checks behavior, and it checks discoverability. That combination matters. A correct implementation with a bad schema still produces bad agent behavior. Bob cannot choose the right tool consistently if the contract it sees is vague.

Test the saveNote stateful round-trip

This is the most important test in the suite.

A state-changing tool is where agent-driven systems stop being stateless request/response code and become workflows. Bob saves something under a key, then reads it back later using a resource template. If the write path and the read path are tested in isolation, you can still miss the real bug: the loop is broken.

Add this test:

  @Test
    void saveNoteThenReadItBackViaResourceTemplate() {
        var client = McpAssured.newConnectedStreamableClient();
        try {
            client.when()
                    .toolsCall("saveNote",
                            java.util.Map.of("key", "testkey", "content", "# Hello from the test"),
                            r -> {
                                assertFalse(r.isError());
                                assertTrue(r.content().get(0).asText().text()
                                        .contains("testkey"));
                                assertTrue(r.content().get(1).asText().text()
                                        .contains("dev-toolkit://notes/testkey"));
                            })
                    .resourcesRead("dev-toolkit://notes/testkey",
                            r -> {
                                var contents = r.contents().get(0).asText();
                                assertEquals("# Hello from the test", contents.text());
                                assertEquals("dev-toolkit://notes/testkey", contents.uri());
                            })
                    .thenAssertResults();
        } finally {
            client.disconnect();
        }
    }

This test is important because it matches the real agent path. The assertions lock in the current contract (e.g. URI shape and response text); if you change the server’s contract, update these tests deliberately. Bob calls the tool, gets back a URI, then reads that URI. If one side changes its format, or if the write succeeds but the resource template resolves incorrectly, the failure shows up here.

Now add the rejection case:

  @Test
    void saveNoteShouldRejectBlankKey() {
        var client = McpAssured.newConnectedStreamableClient();
        try {
            client.when()
                    .toolsCall("saveNote",
                            java.util.Map.of("key", "", "content", "this should not be saved"),
                            r -> {
                                assertTrue(r.isError());
                                assertTrue(r.content().get(0).asText().text()
                                        .contains("Key must not be blank"));
                            })
                    .thenAssertResults();
        } finally {
            client.disconnect();
        }
    }

This is the kind of bug that causes ghost failures later. If blank keys are accepted, the write side looks fine and the read side looks broken. In reality, the contract was broken at the first step.

Test resources and resource templates as first-class contracts

Resources are not just static documentation for Bob. They are part of the context supply chain. The model reads them to decide what is available and what to do next.

Test the server-info resource first:

  @Test
    void serverInfoShouldListAvailableNoteKeys() {
        var client = McpAssured.newConnectedStreamableClient();
        try {
            client.when()
                    .resourcesList(page -> {
                        assertNotNull(page.findByUri("dev-toolkit://server-info"));
                        assertNotNull(page.findByUri("dev-toolkit://java-string-cheatsheet"));
                    })
                    .resourcesRead("dev-toolkit://server-info",
                            r -> {
                                String content = r.contents().get(0).asText().text();
                                assertTrue(content.contains("Online"));
                                assertTrue(content.contains("conventions"));
                                assertTrue(content.contains("architecture"));
                            })
                    .thenAssertResults();
        } finally {
            client.disconnect();
        }
    }

Now test the missing-note case:

    @Test
    void readingMissingNoteShouldReturnHelpfulContent() {
        var client = McpAssured.newConnectedStreamableClient();
        try {
            client.when()
                    .resourcesRead("dev-toolkit://notes/doesnotexist",
                            r -> {
                                String content = r.contents().get(0).asText().text();
                                assertTrue(content.contains("Note Not Found"));
                                assertTrue(content.contains("doesnotexist"));
                            })
                    .thenAssertResults();
        } finally {
            client.disconnect();
        }
    }

And test the resource template itself:

    @Test
    void resourceTemplateShouldBeRegisteredAndAccessible() {
        var client = McpAssured.newConnectedStreamableClient();
        try {
            client.when()
                    .resourcesTemplatesList(page -> {
                        var template = page.findByUriTemplate("dev-toolkit://notes/{key}");
                        assertNotNull(template);
                        assertEquals("Project Note", template.name());
                    })
                    .resourcesRead("dev-toolkit://notes/conventions",
                            r -> assertTrue(r.contents().get(0).asText().text()
                                    .contains("camelCase")))
                    .thenAssertResults();
        } finally {
            client.disconnect();
        }
    }

The important part here is not just that the template exists. The important part is that the resource URI Bob receives from the tool is a URI Bob can actually follow later.

Test prompts like user-facing contracts

Prompts are easy to ignore because they are not “execution logic.” That is a mistake. Bob surfaces these prompts to users, asks for the declared arguments, and then sends the rendered content to the model. If the arguments are wrong or missing, the prompt is broken at the UX layer.

Add this test:

 @Test
    void promptsShouldBeRegisteredWithCorrectArguments() {
        var client = McpAssured.newConnectedStreamableClient();
        try {
            client.when()
                    .promptsList(page -> {
                        assertEquals(2, page.size());

                        var explainError = page.findByName("explain-error");
                        assertNotNull(explainError);
                        assertNotNull(explainError.description());
                        assertTrue(explainError.arguments().stream()
                                .anyMatch(a -> a.name().equals("error")));

                        var codeReview = page.findByName("code-review");
                        assertNotNull(codeReview);
                        assertNotNull(codeReview.description());
                        assertTrue(codeReview.arguments().stream()
                                .anyMatch(a -> a.name().equals("code")));
                    })
                    .promptsGet("explain-error",
                            java.util.Map.of("error", "NullPointerException at line 42"),
                            r -> {
                                assertEquals(1, r.messages().size());
                                String text = r.messages().get(0).content().asText().text();
                                assertTrue(text.contains("NullPointerException"));
                            })
                    .thenAssertResults();
        } finally {
            client.disconnect();
        }
    }

The Quarkiverse testing guide shows prompt list and prompt get testing as first-class McpAssured operations, just like tools and resources. That is the right mental model. Prompts are part of the contract too. (docs.quarkiverse.io)

Add one full regression test as your CI gate

Unit-like integration tests are good. A full smoke pass is still useful, but now it should smoke the whole contract, not just the transport.

Create a second test class: src/test/java/com/example/mcp/DevToolkitMcpRegressionTest.java

package com.example.mcp;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertFalse;
import static org.junit.jupiter.api.Assertions.assertNotNull;
import static org.junit.jupiter.api.Assertions.assertTrue;

import java.util.Map;

import org.junit.jupiter.api.Test;

import io.quarkiverse.mcp.server.test.McpAssured;
import io.quarkus.test.junit.QuarkusTest;

@QuarkusTest
class DevToolkitMcpRegressionTest {

    @Test
    void fullContractSmokePass() {
        var client = McpAssured.newConnectedStreamableClient();
        try {
            client.when()
                    .toolsList(page -> {
                        assertEquals(5, page.size());
                        assertNotNull(page.findByName("toUpperSnakeCase"));
                        assertNotNull(page.findByName("saveNote"));
                    })
                    .resourcesList(page -> {
                        assertNotNull(page.findByUri("dev-toolkit://server-info"));
                    })
                    .resourcesTemplatesList(page -> {
                        assertNotNull(page.findByUriTemplate("dev-toolkit://notes/{key}"));
                    })
                    .promptsList(page -> {
                        assertEquals(2, page.size());
                        assertNotNull(page.findByName("code-review"));
                    })
                    .toolsCall("toUpperSnakeCase",
                            Map.of("input", "hello world"),
                            r -> assertEquals("HELLO_WORLD",
                                    r.content().get(0).asText().text()))
                    .toolsCall("countOccurrences",
                            Map.of("text", "abcabc", "substring", "abc"),
                            r -> assertEquals("2",
                                    r.content().get(0).asText().text()))
                    .toolsCall("saveNote",
                            Map.of("key", "smoketest", "content", "# Smoke"),
                            r -> assertFalse(r.isError()))
                    .thenAssertResults();
            client.when()
                    .resourcesRead("dev-toolkit://notes/smoketest",
                            r -> assertTrue(r.contents().get(0).asText().text()
                                    .contains("# Smoke")))
                    .thenAssertResults();
        } finally {
            client.disconnect();
        }
    }
}

The McpAssured docs describe this style explicitly as batch testing: chain multiple MCP operations, then validate them together with thenAssertResults().

This is the test that belongs in CI. If it fails, your agent-facing contract is not healthy enough to ship.

Capture raw MCP traffic when the bug only appears in an agent loop

This is the test you will care about at 2am.

One of the most useful McpAssured features is raw message inspection. The Quarkiverse testing guide documents snapshot() for capturing requests and responses after a test interaction. It also shows that you can inspect the raw JSON-RPC method names and result payloads directly. (docs.quarkiverse.io)

Add this test method to DevToolkitMcpTest:

    @Test
    void inspectRawJsonRpcTraffic() {
        var client = McpAssured.newConnectedStreamableClient();
        try {
            client.when()
                    .toolsCall("base64Transform",
                            java.util.Map.of("input", "debug me", "operation", "encode"),
                            r -> {
                            })
                    .thenAssertResults();

            var snapshot = client.snapshot();
            if (!snapshot.requests().isEmpty() && !snapshot.responses().isEmpty()) {
                System.out.println("→ Request:");
                System.out.println(snapshot.requests().get(0).encodePrettily());
                System.out.println("← Response:");
                System.out.println(snapshot.responses().get(0).encodePrettily());
            }
        } finally {
            client.disconnect();
        }
    }

This is not a business assertion test. This is a debugging test. You can exclude it from CI (e.g. with @Tag("debug") and a profile that skips that tag) if you want to avoid console output in automated runs. When Bob behaves strangely and you cannot tell whether the problem is your Java code, your schema, or the model’s follow-up reasoning, snapshot output gives you the exact MCP exchange your server produced during the test run.

That is much better than guessing from logs.

Configuration

For this tutorial, the nice part is that we do not need special McpAssured configuration. The default setup with @QuarkusTest and newConnectedStreamableClient() is enough for the existing Streamable HTTP transport.

If you want extra visibility during development, enable traffic logging in your Quarkus application while running the server manually. The Quarkus MCP Server development tools guide documents traffic logging and Dev UI support for HTTP-based MCP servers. That is useful when you want to compare what Dev UI shows, what the server logs, and what your tests capture through snapshots. (docs.quarkiverse.io)

Look at src/test/resources/application.properties and uncomment the below line:

quarkus.log.category."io.quarkiverse.mcp".level=DEBUG

This setting is optional. It helps when a test fails and you want to correlate server-side activity with the client-side snapshot.

The important part is not fancy test config. The important part is that your tests stay close to the published MCP contract.

Production Hardening

What happens under agent-driven load

A REST API often gets tested one request at a time. An MCP server rarely gets used that way in real life. An agent lists tools, reads resources, calls a write tool, reads a resource template, maybe triggers a prompt, and then repeats the cycle. Your contract is stateful even if each transport request is stateless.

That means you need to test chains, not just calls. The saveNote round-trip is a simple example, but the pattern scales. If one MCP feature produces identifiers, URIs, or content that another feature consumes, write at least one regression test that traverses the whole path.

Concurrency and correctness are still your problem

McpAssured handles session lifecycle, message exchange, and typed assertions. It does not make your server safe under concurrent writes. If two agent sessions save the same note key at the same time, your correctness guarantee depends on your implementation, not on the test library.

Right now, your ConcurrentHashMap note store is fine for a tutorial server. It is not a persistence model. It gives thread-safe map operations, but it does not give you auditing, quotas, ownership, TTL cleanup, or rollback. This is exactly why Part 3 should add authentication, per-user write limits, and stronger validation before you let autonomous tools write state.

Tool errors must be designed, not improvised

The MCP spec is clear here. Tool execution problems belong in tool results with isError: true, while protocol errors are for invalid requests, unknown tools, and server-level failures. (Model Context Protocol)

In practice, this means you should decide deliberately which failures the model can recover from. Invalid operation names, blank keys, or business-rule violations are usually tool errors. Missing methods, malformed JSON-RPC messages, or unsupported protocol features are protocol errors. If you blur that line, the agent loses its ability to self-correct.

Tests lock in the contract

Your tests encode the current server contract: error message text (e.g. “Key must not be blank”), URI shapes, and response structure. If you change the server’s behavior or wording, update the tests deliberately so they remain an accurate specification. Where you call r.content().get(0) or r.contents().get(0), the examples assume at least one element; if a tool or resource can return empty content, assert non-empty (e.g. assertFalse(r.content().isEmpty())) before get(0) so failures stay clear.

Schema quality is part of production quality

This is easy to forget because schemas are generated for you. But generated does not mean automatically good. The model still depends on your descriptions, argument names, and semantic clarity.

A tool called truncate with a useless description like “does string stuff” will technically work. It will still be a bad production tool because the agent has weak guidance about when to use it and what maxLength really means. Test presence, then inspect descriptions, then fix wording when the contract is vague.

Raw snapshots are your replay mechanism

When a Bob session goes wrong, reproduction is usually the hard part. The raw snapshot gives you a path back to determinism. The Quarkiverse testing docs explicitly support request and response inspection through snapshot(), and that turns “the agent did something weird” into a concrete JSON-RPC exchange you can replay in a test.

That is the kind of tool that saves real time when production behavior gets confusing.

Verification

If tests fail with connection or startup errors, ensure the Quarkus application starts and the MCP endpoint is available (e.g. no port conflicts, and the test runs with @QuarkusTest as shown).

Start by running the full test suite:

mvn test

Expected result:

[INFO] Tests run: 12, Failures: 0, Errors: 0, Skipped: 0
[INFO] BUILD SUCCESS

Your exact number of tests can differ if you add more methods, but the build should be green.

Now run only the regression test:

mvn -Dtest=DevToolkitMcpRegressionTest test

Expected result:

[INFO] Running com.example.mcp.DevToolkitMcpRegressionTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0

This verifies your CI gate. It checks that the MCP server exposes the expected tools, resources, templates, and prompts, and that a stateful write/read loop still works.

Finally, connect the running server to Bob exactly like you did in Part 1 and try these manual scenarios (optional; requires IBM Bob and the same connection setup as in Part 1—URL, etc.):

- Ask Bob to save a note under key "release-plan"
- Ask Bob to read the same note back
- Ask Bob to explain a NullPointerException through the explain-error prompt
- Ask Bob to base64 encode "hello bob"

What you are verifying here is not just that the server responds. You are verifying that Bob can traverse the same contracts your tests now cover: discover tools, call tools, follow resource URIs, and render prompts.

Conclusion

We replaced a raw JSON-RPC smoke test with contract-focused MCP integration tests that match how IBM Bob actually uses your Quarkus server. The new suite verifies registration, schemas, tool behavior, stateful write/read flows, prompts, and raw request/response traffic. That closes the gap between “the server starts” and “the agent can safely build on the result.” The Quarkus MCP Server docs and McpAssured guide make this testing model first-class, and that is exactly the right direction for production MCP work.

The complete code for the server series is available in the GitHub repository.