Transcripted Summary
# What is MCP?
MCP stands for Model Context Protocol. It's an open standard introduced by Anthropic in late 2024 that defines how AI models communicate with external tools, data sources, and services.
If you've worked with APIs or plugins before, MCP is going to feel familiar. Plugins give tools access to external services. APIs provide a way for external sources to call internal operations or query data. MCP doesn't replace any of those ideas — it standardizes how they all fit together in an AI context. Think of it as the agreed-upon shape of the conversation between a model and the outside world.
# The USB Analogy
The name "Model Context Protocol" might be accurate, but it's not particularly illuminating. Here's another three-letter acronym that might be more familiar to you: USB, the mighty Universal Serial Bus.
Before USB, every device had its own connector. Printers, keyboards, cameras — each one with its own proprietary cable, its own drivers, and its own nightmare. If you had N devices and M computers, you had N × M integrations to manage. Every combination was its own special problem.
I remember as a kid, I wanted to play a flight simulator game with a joystick, but the computer's plug didn't match what the joystick had. So I had to dredge for an hour through my dad's computer parts to find cables and adapters and try to rig together this Frankenstein contraption just to play my game.
USB fixed that by giving both sides a single interface to agree on. Now any device plugs into any computer. The device handles its own logic, the computer handles its own logic, and USB is just the handshake between them.
MCP does the same thing for AI. Any model that speaks MCP can connect to any tool or service that exposes an MCP server. One standard protocol instead of a pile of bespoke glue code. The model doesn't need to know how your server works internally. It doesn't need to know which model it's talking to. They just need to agree on MCP.
# The Three Components
There are three components to this architecture:
- The host is the AI application the user is talking to — Claude Desktop, Claude Code, Cursor, your own custom agent.
- The client is a component inside the host that manages the connection to servers.
- The server is what we're building. The process that actually reaches out and touches the real world.
The host is the brain. The client is the nervous system. The server is the hands.
# Why This Matters
Have you ever asked an AI chatbot to do some simple math? Something like two plus two, and gotten back 22 as confidently as can be? I've seen a lot of people give up on using AI after an experience like that, and it's easy to brush off the potential when they aren't being used for their best purpose.
Instead, imagine if that AI agent had access to a calculator tool. It could recognize, "Okay, this is mathematics. I'll have my math tool see to this," and pass the math off to something that's actually calculating instead of just trying to guess. An MCP server provides exactly that pathway. By writing some code that exposes tools and knowledge to the model, we get better information to the LLM and ultimately better results out of its reasoning.
LLMs are stuck. They're trained on data up to a cutoff date. They have no awareness of your codebase, your production database, your running systems. Every conversation starts from zero. So the model knows a lot about the world in general, but nothing about your world specifically.
The obvious fix is to give it information, and for a while that's what everyone was doing — pasting in code, copy-pasting error messages, manually shoving context into the prompt. It gets old fast and it only works in one direction. You can tell the model what your tests look like, but you can't have it run the tests.
So tool use arrived. You could give a model the ability to call functions, query data, trigger actions. That worked. But then everyone building AI features had to write custom glue code to wire their tools to their chosen model. Switch models, rewrite the glue code. Add a new tool, more glue code. Sound familiar?
MCP solves it the same way that USB did. Write one server. It works with any compatible host. You stop reinventing the integration layer every time and start actually building things.
A model that can only respond to what you tell it is a very sophisticated autocomplete. A model that can reach out, pull live data, trigger real actions, and hand results to the next step in a workflow — that's something closer to an agent. MCP is a big part of what makes that possible.
# MCP in the Wild
You've probably already used one and haven't realized it.
GitHub Copilot. Since late 2025, Copilot supports MCP directly inside VS Code. When it suggests a fix that references your actual project structure instead of hallucinating a method that doesn't exist, that context came from somewhere. That somewhere is MCP.
Playwright MCP. From a testing standpoint, Microsoft maintains an MCP server specifically for browser automation. Your AI agent can open a browser, navigate to a page, take a screenshot, and interact with elements, all through MCP tools — which, as someone who's written a lot of browser automation tests, feels a little surreal in a good way.
Enterprise assistants. If your company has an internal AI tool that can query your ticketing system or pull from a knowledge base, there's a very good chance that something is MCP-shaped.
It's become the de facto standard, adopted by Anthropic, OpenAI, Google, and Microsoft, and it was donated to the Linux Foundation in late 2025.
The pattern across all of these is the same. The AI isn't doing anything magical. It's just calling well-defined functions and reading well-defined data through a well-defined protocol. MCP is just the spec that makes all of it interoperable.
# What We're Building
All of those examples are things that you consume — tools someone else built, running on servers someone else maintains. This course is about becoming the person who builds those things.
We're going to build an MCP server in Java using the official Java MCP SDK. We'll start with the smallest possible thing that works and then grow it section by section, adding tools, resources, and prompts to solve one realistic problem all the way through: generating structured test data on demand for a web application.
By the end, that server is going to be participating in a multi-server agentic workflow alongside the Applitools Eyes MCP, doing visual validation of the UI that our generated data populates.
Don't worry, we'll get there. Let's start building.
