What is MCP (Model Context Protocol)? A plain guide for agile teams
If your team uses an AI assistant, someone has probably asked whether it can "just read Jira" or "post that in Slack". The Model Context Protocol, MCP for short, is how that now works. This is a plain explanation of what it is, how it differs from the APIs and webhooks you already know, how it signs you in, and where it belongs in an agile team's week, and where it doesn't.
What MCP actually is
MCP is an open standard for connecting an AI assistant to the tools and data it can't see on its own. Anthropic published it in late 2024, and it has since been taken up by the other big assistant makers and most AI coding tools. The idea is simple: instead of every assistant building its own plug-in for every product, a product publishes one MCP server, and any assistant that speaks MCP can use it.
There are three parts to keep in mind:
- The client is the assistant you talk to: a chat app, a coding tool in your editor, or an agent in your terminal.
- The server is the product's side: a small service that knows how to search your tracker, read a document or create a meeting room.
- Tools are the actions a server offers, each with a name, a short description and a typed list of inputs, such as "search issues by project and status" or "add a comment to an issue". Servers can also offer read-only resources (files, records) and ready-made prompts, but tools are what most people mean.
When you connect a server, the assistant asks it what tools it has. From then on, when your request needs one, the model picks the tool, fills in the inputs, and shows you the call. You describe the outcome ("pull this sprint's unestimated stories"), not the steps.
A server either runs on your own machine, started by the assistant as a local program, or lives on the web at an address you add to the assistant. Most products offer the second kind, a remote server, because there is nothing to install.
How MCP differs from a REST API or a webhook
MCP doesn't replace APIs. Most MCP servers call the product's own API underneath. What changes is who decides which call to make, and when.
| REST API | Webhook | MCP server | |
|---|---|---|---|
| Who starts it | Your code, when you wrote it to | The product, when an event happens | The assistant, when your request needs it |
| Who decides what to call | A developer, ahead of time | A developer, ahead of time | The model, at the moment, from the tool descriptions |
| How it's discovered | Reading the documentation | Configuring a URL | The client asks the server for its tool list |
| Who it acts as | Usually a key or a service account | The product itself | You, with your own permissions |
| Best for | Fixed automations, scripts, CI | Reacting to events | One-off, varied requests in plain language |
The practical difference: a script does the same thing every time, which is what you want for a nightly sync. An assistant with MCP tools does something slightly different every time, which is what you want for "find the three stories in this sprint that touch billing and summarise what we said about them".
How it signs you in: OAuth, PKCE and registration
A remote MCP server acts for a real person, so it needs to know who you are. The standard uses OAuth, the same family of sign-in you already use for "Sign in with Google" or connecting Slack to another app. In plain terms, the first time an assistant uses a server:
- The server says "you need to sign in" and where. It answers the first call with a pointer to its sign-in service, so the assistant can find it without any setup from you.
- The assistant introduces itself. It registers as a client of that sign-in service, either on the spot or by pointing to a published description of itself. This is why you don't have to create an "app" in a developer console first.
- Your browser opens a consent page. You sign in to the product, if it has accounts, see which assistant is asking and what it will be allowed to do, and approve.
- The assistant receives a token, not your password. A step called PKCE proves that the app collecting the token is the same one that started the sign-in, so a token can't be grabbed on the way back. The token works only for that server, can expire, and can be revoked.
Compare that with the older way of connecting tools: paste a long-lived API key into a config file. That key usually has every permission you have, never expires, sits in plain text on a laptop, and is easy to commit to a repository by accident. If a server's setup page asks you to paste a key into your assistant, prefer one that offers the browser sign-in instead.
Why agile teams should care
A lot of what fills a sprint isn't the work itself but the preparation around it: gathering the tickets, reading the comments, drafting the summary, copying results from one place to another. That is exactly the kind of work an assistant with the right tools does well, because it is tedious, well-defined, and easy for a person to check.
- Refinement prep. Pull the stories that are next in line, list the open questions in their comments, and flag the ones with no acceptance criteria. We cover this in AI-assisted backlog refinement.
- Planning prep. Gather the candidate stories for a sprint and set them up for the meeting, so nobody spends the first ten minutes copying titles.
- Write-up. After a meeting, record the agreed estimates and decisions where they belong, instead of in someone's notes.
- Standups and retros. Draft what you did yesterday from your merged pull requests, or collect the incidents of the sprint before the retro.
Where it must not go: the vote
Planning poker works because everyone picks a card on their own, before seeing anyone else's. The value is in the spread: a 3 and a 13 on the same story mean two people see it differently, and that conversation is the point of the meeting. An assistant that offers its own estimate first, or votes alongside the team, anchors everyone to one number and erases the spread before anyone has seen it. Use the assistant to prepare the room and to write up the result, and keep it out of the vote itself. Here's how to read a reveal once the cards turn over, and what to hand to the assistant in sprint planning.
What you can do with it today
Most of the tools a software team uses every day, including issue trackers, code hosts, docs and chat, now publish an MCP server or have one built by the community. A typical setup combines two or three:
- Your tracker's server, to read and update issues.
- Your code host's server, to read pull requests and their review comments.
- A meeting tool's server, to set up the session and record what came out of it.
The assistant becomes the glue between them: "take the top ten unestimated stories in the backlog and set them up for Thursday's planning" touches the first and the third in one request.
A reasonable place to start
- Pick one ritual that annoys you. Usually it's the prep for refinement or planning. Don't connect everything at once.
- Connect one server, read-only first. If the consent page offers a read-only option, take it. Ask questions for a week before you let the assistant change anything.
- Read every tool call before you approve it. Assistants show you the call and its inputs. It takes seconds, and it is how you learn what the model gets wrong.
- Then allow writes, for one job. Creating a planning room or adding comments is a good first write: easy to check, easy to undo.
- Mind what you share. Whatever a tool returns goes to the assistant's provider. Use only the data your organisation allows you to share with it.
Common questions
Is MCP only for Claude?
No. It started at Anthropic, but it is an open standard, and the major chat assistants and AI coding tools support it. One server works with all of them.
Do I need to be a developer to use it?
Not for a remote server. In most assistants you paste the server's address into a "connectors" or "MCP servers" setting and approve it in your browser. Running a local server, or writing your own, is where developer skills come in.
Can the assistant do anything I can't?
It shouldn't. A well-built server acts as you, with your permissions, and nothing more. If you can't delete a project, neither can the assistant through that server.
How do I disconnect it?
Remove the server from your assistant's settings, and revoke its access from the product side if the product offers a list of connected apps. A revoked token stops working at the next call.
Will an assistant estimate our stories for us?
It can produce a number, but it shouldn't be the first number the team sees. See planning poker when AI agents write the code for what changes in estimation when an agent does the building, and what doesn't.
Where Estimay fits
Planning poker is a good fit for MCP at both ends of the meeting: setting up a room with the sprint's stories before it starts, and reading back the agreed estimates when it ends, with the secret vote in between left to the people in the room. That is what Estimay's MCP server does, with the same rule as the rest of Estimay: no account and no sign-up. The assistant signs in with OAuth as the guest of your browser, read only or read and write, and you can disconnect it at any time. Here is how to connect Claude and other assistants, and how to run planning poker from Claude Code.
Keep the vote human. Create a free room, share the link, and let everyone pick a card before anyone, or anything, shares a number. No sign-up needed.
Enjoying Estimay? A short review helps other teams find it.