Everyone in AI suddenly "supports MCP." It's in the launch posts, the sales decks, the changelogs. And it's a real, good standard — the thing that finally lets an assistant like Claude or ChatGPT do something in your app instead of only describing it.
But "we support MCP" is doing a lot of quiet work in those sentences. Standing up a server that answers a demo is easy. Standing up one that a thousand different customers can safely connect their own accounts to, all day, without stepping on each other, is a different job entirely.
What MCP is, without the acronym
MCP, the Model Context Protocol, is a common language between an AI assistant and an outside app. The app runs a small server that says "here are the things you can look up and the actions you can take," and the assistant can then use them on your behalf1.
That's the unlock. Without it, an assistant can only talk about your data. With it, the assistant can read your real records and actually do things — the same way a person clicking around your app would.
The demo is easy. Production is not.
A single-user MCP server is a weekend project. Wire up a few actions, point your own assistant at it, and it works. That's the version most "we support MCP" announcements are quietly describing.
Production is where it gets real. Now it's not you connecting, it's your customers — each with their own login, their own data, their own permissions. The server has to be up when they need it, handle many of them at once, and never once let one customer see another's anything. The protocol is the easy 10%. This is the other 90%.
Multi-tenant is the whole game
The hard word is multi-tenant: many separate customers sharing one service, each walled off from the rest. When an assistant connects, the server has to know exactly whose account it's acting on, hand back only that account's data, and take actions only that user is allowed to take.
Get this slightly wrong and it's not a bug, it's a headline. Most of the engineering in a serious MCP server is here — the login flow, the per-customer isolation, the scoping of what each connection can touch. It's unglamorous, it's most of the work, and it's exactly what a demo lets you skip.
What 'hosted' takes off your plate
A hosted MCP server is someone else running that 90% for you. You bring the actions you want to expose; the host handles the connection standard, the sign-in and consent flow, the multi-tenant isolation, and keeping the thing online.
That's what TCP3 runs: hosted, multi-tenant MCP servers with the auth and the isolation already built in, so your customers can connect their own accounts and your team doesn't inherit a new always-on service to babysit. You get the reach of MCP without owning the plumbing under it.
Connect once, act everywhere
The payoff is that once your app speaks MCP, it works inside every assistant that speaks MCP — today and the ones that ship next year. You expose your actions once, and your customers can reach them from wherever they already work.
That's the test worth holding it to: not "can we show an MCP demo," but "can a thousand customers safely connect their own accounts to it on a Tuesday." A hosted server is how you get to yes on the second one without spending a quarter building the first 90% yourself.
Frequently asked questions
What is an MCP server in plain terms?
- It's a small service that exposes your app's data and actions to AI assistants through the Model Context Protocol, a shared standard. Once it's running, an assistant like Claude or ChatGPT can look things up and take actions in your app on a user's behalf, instead of only talking about them.
Why not just build my own MCP server?
- You can, and a single-user demo is quick. The cost is production: authentication, per-customer isolation (multi-tenancy), consent flows, and uptime. That's most of the work and the part with real security stakes. A hosted server hands you that plumbing so you only build the actions unique to your app.
What does 'multi-tenant' mean and why does it matter?
- Multi-tenant means many separate customers share one service while staying fully walled off from each other. It matters because an MCP server must return only the connected user's data and allow only their permitted actions. Getting isolation wrong is a security incident, not a small bug.
Which assistants can connect to a hosted MCP server?
- Any client that speaks MCP. Because it's an open standard, the same server works across assistants that support it — so you expose your actions once and reach users wherever they already work, including clients that ship later.
Footnotes
- The Model Context Protocol the open standard for connecting AI assistants to apps. ↩
- Your business doesn't need another chatbot why an agent that acts beats a bot that only talks — MCP is how it acts. ↩