No Handshake, No Session: Build a Stateless MCP Server in Java

The Model Context Protocol just forgot how to start a conversation. Revision 2026-07-28 deleted the initialize handshake. There is no session, no ping, nothing to resume. Every request now carries its own protocol version and capabilities in _meta — and if the server needs something, it asks inside the reply.

In this instructor-led workshop you will build a Java MCP server from scratch, over raw STDIO, with no SDK and no framework. Chapter by chapter you will implement the transport, JSON-RPC, server/discover, tools, resources, and prompts — then the pieces that only make sense once memory is gone: Multi Round-Trip Requests (ask by answering), MCP Apps (a tool that returns a UI), and Tasks (call now, fetch later).

You will leave with a working server you can point at Cursor, Claude Code, or Windsurf, and a wire-level understanding of the protocol that SDKs hide.

Audience: Java developers comfortable with JSON who want to see how agents actually talk to tools.
Prerequisites: JDK 21+, Gradle, and a laptop that can run MCP Inspector.

MCP Killed the Handshake: What Stateless Really Means for Agents

Older MCP was stateless in spirit and stateful in practice: initialize opened a session, and every later message leaned on that memory. The 2026-07-28 revision removed the handshake outright. There is no first message, no session, and a server that needs input cannot send a request — modern clients silently discard them.

This talk walks the wire. Live in MCP Inspector we will watch discovery replace initialize, watch _meta replace the session, and watch a server ask a question by answering a tool call. Then: a tool that returns a UI, a task handle instead of a blocking result, and why continuation state now has to travel on the wire — because the server has nowhere else to keep it.

If you have only used an MCP SDK, this is the protocol underneath. If you are about to build a server, this is why “just add a session” is the wrong instinct.

A Day in the Life of a TDD Agentic Developer

Test-Driven Development (TDD) has long been a cornerstone of building reliable, maintainable software. But what happens when we bring intelligent agents into the loop? This hands-on session explores how requirements can automatically drive the creation of executable unit tests, and how developer-focused agents collaborate with humans to ensure all tests pass with confidence.

We’ll begin with a quick refresher on the Red/Green/Refactor cycle and show how agentic workflows extend TDD by generating tests directly from acceptance criteria while keeping the human firmly in control. Then, through a live demo, we’ll walk from requirements to passing code: agents author tests, a developer agent produces the code, and together with the human in the loop, they iterate until the suite is green.

Attendees will leave with a clear understanding of how TDD evolves in the agentic era—faster feedback, safer refactoring, and higher confidence—while never losing the essential human guidance at the heart of software craftsmanship.

Introduction to the Agent-to-Agent (A2A) Workshop: Building Interoperable Agent Communication

The Agent-to-Agent (A2A) Workshop is an instructor-led series designed to introduce participants to the emerging standard for agent interoperability. Grounded in the A2A project and specification, the workshop ensures learners gain a solid grasp of the protocol by working directly with Java’s standard libraries and raw APIs.

The workshop follows a branch-based structure—beginning with 01-chapter and progressing through successive lessons. Each chapter builds on the last, guiding participants as they implement communication primitives, message routing, and interoperability layers aligned with the A2A specification. Along the way, learners will explore agent identity, capability exchange, and discovery, while working through real-world scenarios where agents from different ecosystems must collaborate.

By the end of the workshop, participants will be able to:
• Understand the goals and principles of A2A as a protocol for agent interoperability.
• Implement the core A2A handshake and message-passing flows.
• Connect heterogeneous agents and frameworks.
• Gain hands-on experience with JSON-based specifications, discovery registries, and cross-agent tool invocation.

While the material can be studied independently, the greatest value comes from guided instruction and group participation, where learners debug live agent communication and analyze interoperability challenges together. This foundation equips participants to build interoperable agents and tools, accelerating adoption of standards-based, multi-agent ecosystems

Bring your favorite command-line IDE and get ready to roll up your sleeves—this workshop is fully hands-on. You’ll implement your own A2A-compliant agent from scratch and see interoperability come to life.

Introduction to the Agent MCP Workshop: Building Your Own Java-based MCP Server

The Agent MCP Workshop is an instructor-led series designed to guide participants through developing a Java‑based server implementing the Model Context Protocol (MCP). This introduction sets expectations and provides orientation for the learning journey, including prerequisites, workshop structure, and branch-based lesson flow. Participants are encouraged to complete a pre-workshop setup (via 00-setup.md) before class to ensure their environment is ready. The workshop is structured across successive branches—starting with 01-chapter, each representing a progressive lesson where learners will build components of an MCP server from scratch. While self-study is possible, success depends on active instruction and group participation. The introduction also outlines workshop objectives, teaches working with Java’s standard libraries, JSON‑RPC messaging, tool registration, agent integration, and hands-on debugging techniques like STDIO-based communication and protocol-level routing. By setting these foundations, the introduction prepares learners to embark on a hands-on path toward building fully functioning, testable MCP-compatible agents and tools.

To read more about this workshop see this article https://foojay.io/today/understanding-mcp-through-raw-stdio-communication/

The New Review Burden: More Code Generated Than Written — Now What?

As AI-assisted coding and automated generation tools pump out more lines than human developers ever could alone, the responsibility to catch subtle bugs and maintain quality has shifted heavily to the review stage.

In this talk, we’ll walk through practical ways to adapt your review process for a world where more code is generated than written by hand. We’ll cover how to establish clear team guidelines and require structured artifacts with every pull request — not just a list of files changed, but well-organized summaries that categorize and group code modifications by purpose and impact.

We’ll discuss how to classify PR types — from bug fixes to new features — and define levels of effort so reviewers can gauge how much time and scrutiny each change deserves. As tools generate more of our code, we also need AI and automated helpers to reason through those changes, highlight potential security concerns, and map out how modifications ripple through the codebase.

Finally, we’ll look at the non-negotiables: setting up static analysis gates (linters, PMD, SpotBugs, Checkstyle), enforcing agreed-upon quality metrics, and ensuring unit tests and coverage thresholds are met before code ever hits the main branch.

You’ll leave with a blueprint to review smarter and faster — and catch the bugs that AI might sneak in.

Turn Off the Wi-Fi: Spec-Driven Development That Delivers on a Local Model

Your agent just produced 400 lines that compile, pass tests nobody asked for, and encode a design you never approved. The industry's answer is "use a bigger model." That answer costs you your budget, your code's confidentiality, and your ability to reproduce a result six months from now.

There is a better answer, and Java developers have had it for twenty years: write the specification first, and make the tests the contract.

This session walks through a working, open-source pipeline where a requirements catalog — not a chat transcript — is the source of truth. A Java MCP server exposes a small, deliberately locked-down set of tools: no "write this file," no shell. The agent must validate a requirement's structure, survive a wording review that rejects ambiguity like should, handles, and properly, turn the accepted criteria into a tagged Gherkin scenario and a JUnit test, watch it go red, then make it green. A state machine refuses to let it refactor on a red bar, and every write lands in a staging area a human reviews.

Here is the part worth your hour: once that discipline lives in deterministic Java instead of in a prompt, model capability stops being the variable that decides quality. We run the identical loop twice against the same server — once with a frontier agent in an IDE, once with a coder model on the laptop on stage through Ollama — and compare the diffs. Then we look at what makes the local model hold up: JSON-only response contracts, one-finding-at-a-time correction, validate-and-retry that feeds the invalid reply back, and deterministic templates as the floor when generation fails.

Then comes the segment most talks skip: Where This Breaks. Real failures this project hit — format drift, fixing the wrong file, silently dropping a criterion, looping on an attempt that already failed — each with the deterministic check that now catches it, and an honest account of where a frontier model is still the right call.

The server and CLI were built this way themselves: every tool has a numbered requirement, a Cucumber scenario, and a test that fails the build when spec and scenarios drift apart.

To prove the point, the demo runs with the Wi-Fi switched off.

You will leave with:
A pattern for MCP servers that enforce a workflow instead of handing agents filesystem access
The deterministic validation layer that lets a local model produce output you would sign your name to
A spec format that maps onto Cucumber-JVM and JUnit 5, and the build gate that keeps the two from drifting apart
A named catalog of local-model failure modes, each with the guardrail that catches it
A repository you can run on your own machine, behind your own firewall.

For Java developers, tech leads, and architects accountable for what their AI agents produce — especially in regulated, air-gapped, or cost-constrained environments. Comfort with JUnit and Cucumber assumed; no MCP or LLM experience needed.

Formats: 50-minute session, or a hands-on workshop where attendees run the loop on their own machines against a local model.

Requirements: projector and my laptop. No conference network needed — the demo runs locally against Ollama. Stack: Java 21, Maven, MCP Java SDK 2.0, Cucumber-JVM 7, JUnit 5.

First delivery of this talk. The workshop material is rehearsed; the local-model comparison and failure-mode segment are new.

Code and follow-along harness: github.com/davidparry/tdd-bdd-agentic (AGPL-3.0).