Transcripted Summary
Let's talk about what you need before we write any code.
# Prerequisites
Java 17 or higher. That's the minimum. If you're already running a Spring Boot project in your organization, you're probably there. If you're not sure, run java -version in your terminal to find out.
Maven, for dependency management and for building. The tools in this course are already found in Maven Central, so you don't need anything unusual set up.
VS Code. There's an extension pack for Java that gives you Maven support, project management, and a pretty solid debugging experience. But if you're more comfortable in IntelliJ or whatever else, that works too — it just needs to be MCP compatible.
GitHub. The code for these examples is hosted there. Make sure you have Git installed and clone the repositories into your local environment.
One thing worth calling out before we start: this course is using the official MCP Java SDK version 2.0.0. This is the SDK maintained by the MCP project itself, not a third-party wrapper. It's worth knowing where it lives so you can find the source, the changelog, and the issues whenever you need them.
# The Two Projects
Before we start any coding, I want to make sure you actually understand what we're building. Everything from here through to the end of the course is one connected example, and you'll need to understand each part as we go.
There are two projects.
The first is the Workbook Viewer web app. It's a Java Spring web application that reads Excel workbook files and displays them in a browser. You give it a workbook, it renders it. Simple premise, realistic problem. This is the kind of internal tool that shows up everywhere in enterprise software — data files, reports, spreadsheets, something that someone needs to view without opening Excel.
The second is the Workbook Generator. This is a Java library. No web layer, just functions whose entire job is to produce those spreadsheets. Specific shapes, specific data, specific structure. It knows how to build workbooks.
The viewer web app consumes what the generator produces.
Here's the problem those two projects don't solve on their own: someone still has to tell the generator what to make. How many rows, what kind of data, what columns. Right now, that means writing code or running a script with the right parameters. It's the kind of task that falls to whoever set up the project, documented in a README that nobody fully reads.
What we're going to build is an MCP server that lives inside the Workbook Generator project and exposes its capabilities to an AI agent. We're not making a new project — we're adding MCP to an existing one. Instead of writing a script, a developer or a tester can tell their AI assistant, "generate a workbook with 50 rows of sales, quarterly columns, and include edge cases like nulls and negative values," and the right spreadsheet comes out the other side.
That's the narrative thread for this whole course. We'll keep adding to this MCP server as we go — tools, resources, and prompts. And by the end, it'll be participating in a workflow where the Applitools Eyes MCP validates what the viewer web app actually renders when we load those generated workbooks.
The generator produces the data. The viewer displays it. Eyes confirms it looks right. All orchestrated by an agent that knows how to talk to each MCP server in turn. That's where we're headed. Let's go.
# Touring the Workbook Generator
Here we are with the Workbook Generator project open in VS Code. The project already has a couple of things staged for us.
First and foremost is the WorkbookGenerator class. This is the class responsible for actually creating those Excel workbooks. You'll note there's a function for generating, a function for making generate samples, writing the files, writing rows, entering random values — all these sorts of things that'll be very useful later on.
Similarly, there is a ColumnSpec.java file. This one just lists information about defaults and describes how to create certain kinds of information for the workbooks — things like text, integers, decimals, and dates.
We also have a WorkbookGeneratorTest class. This just contains the tests for those other functions we just went over. Good to have in place as we make changes.
# Adding the MCP Dependency
Let's start by actually implementing this MCP server. To begin, you'll go into the pom.xml file. This is how Maven projects manage their build tools. To add a new dependency for MCP, we go into the dependency section and paste this in:
<dependency>
<groupId>io.modelcontextprotocol.sdk</groupId>
<artifactId>mcp</artifactId>
<version>2.0.0</version>
</dependency>
The group ID indicates who this is coming from — the official Model Context Protocol provider. These are the people that manage and own all of this. So you're getting it straight from the source. The artifact ID is just the name of it: mcp.
We're using version 2.0.0. The version has changed multiple times since I started writing the script, so please keep in mind that the version could be newer when you get around to implementing this. Refer back to the official Model Context Protocol SDK for Java in case anything here is no longer accurate.
# Writing the Server Class
The next thing we'll do is go into the main/java/com/example/workbooktools folder and add a new Java class. Let's call it WorkbookMcpServer.java.
First, some imports. All three of them come from the io.modelcontextprotocol package we declared earlier:
McpJsonDefaults— this just provides default information for our server that we can fill in as we go.server.McpServer— the actual MCP server functions, basically the main entry point.server.transport.StdioServerTransportProvider— this one's a little different.
STDIO stands for standard I/O, and it means that your server communicates over the standard inputs and outputs. The host process spawns your server as a subprocess and they talk directly through that pipe. This is the right choice for local development and for servers running on the same machine as the host, because the alternative would be HTTP — network connections. This direct pipe keeps things simple. So remember: we're using STDIO.
Next we create our void main function. Some basic boilerplate. We declare the standard server transport provider — a new instance of StdioServerTransportProvider, a bit of a tongue twister. Then, using those McpJsonDefaults we imported, we call the getMapper function, which just sets those defaults for us.
After that, we run the MCP server. We reference that McpServer class, call sync with our transport provider to create a new server with the server info name of workbook-tools — keep it simple — and version 0.0.1. Then call build, and close off the function.
And there you have it. Pretty straightforward. There are no tools, no resources, no prompts. This is the basic element that creates a valid MCP server. With this, it'll start, it'll announce to the host what's happening, respond to the protocol handshake, and it's enough to verify before we go any further.
# Making It Runnable
Back in the pom.xml, we need a way to actually build and run this. So in the build and plugin section, we add another plugin using code from org.codehaus.mojo called the Exec Maven Plugin.
What it basically does is declare what class gets run when you try to execute it. So we configure the main class to be com.example.workbooktools.WorkbookMcpServer — which is in fact the name of the class we just wrote.
Now you should be able to call mvn package. This is one of the Maven commands. It's going to build all the files that we have, make sure that everything we need is grabbed, run the tests, and verify. Success. Because this builds, we should be ready to spin it up.
# Configuring the Host
With the code portion done, let's talk a bit about the configuration. The pattern is the same for Claude Desktop, Claude Code, Cursor, or any other MCP-compatible host you might be using: you have to have some kind of entry in the host's MCP config file pointing at your server.
I'm personally using Claude Code in this example, so here's the configuration entry for that. You'll create a new file called mcp.json and paste in the config.
This configuration file declares the MCP servers. The name, workbook-tools — again, that's the name we gave it in the server info. The type is stdio. The command is mvn for Maven. The args are the goal, compile, and exec:java. That's what we described with the plugin.
# Verifying with the MCP Inspector
Before connecting this to Claude Desktop or Cursor or whatever you use, we can use a really useful tool called the MCP Inspector. It lets you talk directly to the server without needing a full AI host in the loop. It's the fastest feedback mechanism that we have.
You can launch it with:
npx @modelcontextprotocol/inspector
It comes from the official MCP provider. If it's your first time running this, it might have to install the tool, but once it's going, it'll start the MCP Inspector listening on a local port using a session token. The Inspector comes up at a localhost address, and if you follow it, it'll open up the tool.
The transport type is STDIO. That's right. It has a command, arguments, environment variables, authentication, configuration. Let's just run it.
Ooh. Connection error. "Did you add the proxy session configuration token?" No, we didn't. Here it is — the session token. In the config section, we go to the proxy session token, paste it in, and try again.
Okay, so what's happening here? That is messy. New connection request. So it got far enough to actually attempt this, but it's not working. "Error from server: spawning process, not found." It doesn't know what that is.
Well, let's take a look. The command — that can't be right. If you remember, STDIO takes a command and arguments, which might remind you of what we have in the mcp.json: type, command, arguments. We need the command to be Maven, mvn, and the arguments need to be exec:java.
With this in place, let's try again. Connect. Ooh, look at that. Green and connected.
If you still see a server error, the most likely issue is that the project hasn't been built yet. Make sure that you ran mvn package, or in the VS Code terminal, try building.
Take a look here. We can see the note that the connected server does not support any MCP capabilities. Makes sense — that's accurate. There are no resources, no prompts, and no tools yet. But we can ping it. If we click that button, we can see the method ping response. And if we go all the way down to the end, "received post message." If we ping a couple more times, there it is. It's active. The server's running.
# Reviewing the Changes
Last thing before we're done, I want to walk through all of the changes we've made in source control:
- We created the config file,
mcp.json, which describes the name (workbook-tools), the type, the command, and the args — all the information that informed the Inspector tool. - We made changes to the
pom.xml, where we added the Model Context Protocol SDK (artifactmcp, version 2.0.0), and added theorg.codehaus.mojoExec Maven Plugin, configured to the main classWorkbookMcpServer. - We created the
WorkbookMcpServerclass, where we imported the MCP-relevant packages and added amainfunction describing the transport provider (STDIO), gave it the defaults, then actually called the MCP server logic — syncing the transport provider with our server info ofworkbook-toolsand the version — and built it.
These are all the changes needed to set up the groundwork for an MCP server.
We have a server. It starts, it registers, it passes the handshake. It doesn't do anything useful yet, but the host knows it exists and knows it's healthy.
The next section is where we give it something to actually do. We're going to expose the Workbook Generator's capabilities as tools. And once we do, an AI agent will be able to create workbook files on demand just by asking. Let's go give it some hands.
