The half hour comes back.
The list arrives drafted. The lead edits and ticks instead of reading five messages and retyping three.
Your AI knows the whole internet and nothing about your business. MCP fixes that: it lets your AI into the tools your team already runs on. Here’s how, and what to do with it.
Every tool’s door was its own shape. Reaching one meant building something for that one.
One shape, agreed by everybody. Nothing changed inside the tools and nothing changed about your AI. Only the way in.
Your tools have always been able to talk to each other. Every one just did it differently, so connecting any two was a project. MCP gives them all one common language, so your AI can plug into any of them without one.
Connecting two tools isn’t new. What’s new is that your AI can walk through the door on day one, with nobody building anything first.
The question is what it should go in there to do. The answer is smaller than you’d think.
Yesterday’s delivery times typed from one screen into another. A certificate pulled from one portal into another file. Half an hour a morning, in every team, and nobody has ever counted it.
That’s one of them, and yours won’t be bugs. It’ll be a renewal, a delivery note, a timesheet. Count the teams in your business and multiply. Nobody assembles a sponsor and a business case to win back a morning routine, so start at the other end: not with a connection, with the job.
Write the job down and the route becomes the easy part. The route is the last line on the card, and the only one you can change your mind about later.
So pick one job. Here’s half an hour of it, running.
One person types one instruction and it reaches both tools. The AI does the reading and the drafting. The person does the deciding. Nothing gets opened in the second tool until they’ve read the list and ticked it.
The half hour that came back was the typing. Every decision inside it still belongs to the person who always made it.
Nothing was built and nothing was bought. So it’s worth being precise about what you did get.
Nothing new was bought and nobody else was involved. One person’s AI can now reach the tools they already use, and everything it does still lands with them alone.
The list arrives drafted. The lead edits and ticks instead of reading five messages and retyping three.
Neither tool changed and nothing sits between them. Both already had the door, and one prompt used both.
It happens in the window they already had open. Nothing to install and nothing to be trained on, which is why it survived the first busy week.
For work that starts and ends with one person, that’s enough.
It stops being enough the first time somebody else needs to know what happened.
Two tools plugged into a chat window are a convenience. Nobody decides to have nine. One line reached two tools, then seven more arrived over two years, a door each, every one of them somebody solving a small problem on a Tuesday afternoon.
Read yesterday’s customer messages, and open a job in the tracker for each one that is a bug.
Nobody will be saying MCP in two years. They’ll still be asking who owns this and where it’s written down.
Once more than one person depends on it, it has outgrown the chat window, and that’s a different kind of AI.
There’s no invoice with MCP on it. You buy the tool, and its door either comes built the agreed way or it doesn’t. If it doesn’t, somebody can build one over the door that tool already has for software. That’s a job of days, not a purchase.
It gets the access you hand it, and you choose whose access that is. What it reads goes where a pasted email already goes: to the AI your team uses, on the terms you already have with them.
It’s a second way into the same software. Every record stays where it is, the screens don’t change, and the people using them never see a difference.
A door nobody has walked through for a particular job changes nothing. It’s the job that gets connected, not the tool.
Opening a door into a system you pay for isn’t the risky part. Losing track of how many are open is. None of these four is technical. Each is somebody being able to say what a door is for, whose permission it uses, and who reads the result before anything leaves.
If nobody can name the job in a sentence, the door is open for no reason. Ask that before you ask anything technical.
The AI reads as whoever is asking and sees what they’re allowed to see, not what the person who set it up could see. How that works is on the AI and your data page.
Drafting is the AI’s half. Sending, opening and approving stay with people, and anyone involved should be able to say which half they’re doing.
One page, one owner, read once a quarter. The ninth door is never the one anybody remembers opening, and a door the vendor quietly rebuilt is still on the list and no longer working.
Start from the list nobody keeps: the things somebody on your team does by hand every morning that cross two tools. It will be longer than you expect. One job off it is enough to find out whether any of this is worth your time.
What goes in, what has to come out, and who checks the result. If it takes a paragraph, it’s more than one job.
Then open one, for that single job and nothing else. For whoever looks after your systems, that’s usually an afternoon, not a project.
Then count what came back, in minutes a morning. That’s the shape of an AI Jumpstart.
The jobs worth connecting are rarely the ones anybody put on a plan. An AI Jumpstart starts there instead: which two tools somebody opens in the same hour, what has to come out, and who approves it. Two to four weeks, fixed scope, proven on your real records.