What an MCP server is, and when to build your own

Every AI tool now ships with MCP servers. ClickUp has one. Azure DevOps has one. An MCP server is a program that gives an AI a list of actions it is allowed to take. This is part 1 of MCP for Delivery Teams. It covers how MCP works, what changed in the 2026 spec, and when your team should build its own server instead of using the vendor's.

The demo: is the sprint ready?

Before every sprint planning I ask one question: are we ready to commit? So I asked Claude, "Is the Platform team ready for Sprint 24?"

Claude called a tool named check_definition_of_ready. The tool read the team's stories from ClickUp and checked each one against our Definition of Ready. The answer:

• Platform committed 41 points against an average velocity of 28 over the last two sprints. That is 146 percent.
• Four stories are not ready. One has no acceptance criteria. One is 13 points and needs splitting. One is blocked on a security review. One is UI work with no design attached.

There was no dashboard, no export and no spreadsheet. The answer came from live tracker data.

Why a protocol

A language model on its own can't do anything outside the conversation. Text goes in, text comes out. It can't read your backlog, check your calendar or query your database. To do useful work it needs tools.

Before MCP, every AI app wired up its own tools for every system. Five AI apps and ten systems meant 50 custom integrations, each breaking on its own schedule. MCP is a shared protocol. Each system builds one server. Each AI app builds one client. Any client can talk to any server, so 50 integrations become 15. That is why every vendor shipped one.

Host, client, server

MCP has three pieces.

• The host is the AI app you use: Claude, Claude Code, Cursor or Visual Studio Code.
• The client lives inside the host. There is one client for each server you connect.
• The server wraps one system. My server wraps our delivery rules. ClickUp's server wraps ClickUp.

When I ask a question, the host decides it needs a tool. The client sends the request to the right server. The server does the work and returns a result, and the model writes the answer from that result. The model never touches ClickUp directly. It only sees what the server returns. That matters for security, which Episode 3 covers.

Tools, resources and prompts

A server can offer three things.

• Tools are actions the model can call, like get_sprint_capacity and check_definition_of_ready. Each tool has a name, a description written for the model, and a schema for its inputs.
• Resources are data the app can load as context, like a team's Definition of Done.
• Prompts are templates a user picks, like a sprint readiness review that runs the right tools in order.

In practice, tools do most of the work. Here is the capacity tool from the series repo, written with FastMCP in Python:

@mcp.tool(title="Get sprint capacity", annotations={"readOnlyHint": True})
def get_sprint_capacity(team: Team, sprint: Sprint) -> dict[str, Any]:
    """Returns a team's focus hours for a sprint after PTO: per-member hours
    (hoursPerDay x (workingDays - ptoDays)), rawHours, focusFactor and focusHours.
    Use when asked how much capacity a team has or whether PTO changes what they can commit.
    """
    try:
        return readiness.get_sprint_capacity(team, sprint)
    except Exception as err:
        raise _client_error(err) from None

The docstring is written for the model, not for people. It says what the tool returns and when to use it. The type hints become the input schema, and the read-only hint tells hosts the tool can't change anything.

What changed in the July 2026 spec

The MCP specification released on July 28, 2026 changed how clients and servers talk.

In older versions, a client opened a session with a handshake. It sent an initialize request, the server answered with its capabilities, and both sides kept a session ID on every call. That worked on a laptop but was hard in production. You needed sticky sessions or a shared store so every server instance knew about every session.

The 2026 revision removed the handshake and the session. Every request carries its own protocol version and client details. A new server/discover method lets a client ask what a server supports.

For a team lead, the point is this: a stateless MCP server is a web API. It runs on serverless hosts, scales behind a load balancer, and has no session store to maintain. The server in this series is a small Python app on Vercel with no database. It reads ClickUp and Azure DevOps on every request.

One warning. Many tutorials and AI answers still describe the old handshake. Check which spec version a guide targets.

Build your own or use the vendor's

ClickUp has an official MCP server, and Microsoft's Azure DevOps MCP server became generally available in August 2026. So why build one?

• Use the vendor's server for the vendor's data: tasks, work items, comments and boards. The vendor maintains it and handles sign-in.
• Build your own only for logic that is yours. Vendor servers can list my stories, but they don't know my capacity rules, my Definition of Ready, my release calendar, or how ClickUp teams compare to Azure DevOps teams.
• Don't wrap a vendor API that already has an official server. That is more code to maintain and no new capability.

The setup in this series is three servers in one session: mine for delivery rules, ClickUp's for ClickUp, and Azure DevOps's for Azure DevOps.

The cross-tracker check

The second demo asks about the Mobile team, which lives in Azure DevOps.

"How much capacity does the Mobile team have next sprint?" Claude picked get_sprint_capacity from my server. Mobile has 266 hours after PTO. With a 70 percent focus factor that is about 186 focus hours. Capacity comes from a team config file in this demo, because ClickUp has no capacity API and Azure DevOps only tracks capacity for real users. In your own setup, point it at the Azure DevOps capacity screen or your PTO calendar.

"Which Mobile stories are not ready?" Same tool, different team, different tracker. Three stories failed:

• Dark mode is UI work with no design link.
• Dispatcher chat has no acceptance criteria.
• The delay prediction banner depends on an API the Data team hasn't built yet.

That last dependency crosses from Azure DevOps to ClickUp. Neither vendor server would catch it on its own.

Two more questions showed the boundaries. "Show me the Platform backlog in ClickUp" went to ClickUp's own server, not mine. "What was last quarter's revenue?" got an answer that Claude has no tool for that. It didn't guess. The model acts only through the tools you give it, and that is what makes it safe enough to use with your team's work.

Where MCP fits

Think of AI work in four layers.

1. Prompting shapes how the model answers.
2. Retrieval brings in knowledge the model doesn't have.
3. MCP lets the model act on your systems.
4. Evals check that the results are right.

MCP is the action layer. It is also the layer with the most risk, because it touches real data.

What's next

Episode 2 builds this server from scratch in Python, deploys it to Vercel, and connects it to both trackers. Episode 3 adds the official ClickUp and Azure DevOps servers and sets the rules for letting AI write to your tracker: sign-in with Microsoft Entra ID, confirmation, audit, and what happens when a ticket tries to hijack the model.

The code is public under the MIT license at github.com/aleger/mcpseries, tagged v0.1 for this episode. The teams and work items in the demo are fictional.