Hisham AlhussainFor about a year, every time I wanted an LLM to talk to one of our internal systems, I wrote a custom integration. A wrapper here, some JSON schema there, a slightly different version of the same thing for each framework. It worked, but it never felt like the right shape.
Then in late March, OpenAI announced they were adopting the Model Context Protocol, the open standard Anthropic put out late last year. Google followed with its own Agent2Agent protocol in April, and with Claude 4 coming out last month, it really feels like the ground has shifted. MCP stopped being "that Anthropic thing" and started looking like plumbing everyone agrees on.
What MCP actually gets right
The simplest way I explain it to people: MCP is a standard way for an AI app to discover and call tools, read resources, and use prompt templates from a server. You write the server once, and any client that speaks MCP can use it.
What I like about it in practice:
- Write once, use anywhere. One MCP server for our document store works in my editor, in a desktop assistant, and in our own agent code.
- Clear boundaries. The server owns the auth and the business logic. The model just sees well-described tools. That separation makes security reviews a lot easier.
- Discovery is built in. Clients ask the server what it can do. No more hardcoding tool lists in three places.
Where it still hurts
It's not all sunshine. A few things I've bumped into:
- Auth is still maturing. Remote servers with proper OAuth are getting better, but it's early. Expect some rough edges.
- Tool overload. It's tempting to connect ten servers with fifty tools each. Don't. Models get noticeably worse at picking the right tool when you flood them with options.
- Trust. An MCP server is code that your agent will happily call. Treat third-party servers like any other dependency: read them, pin them, and be careful about what data they can reach.
How I'm using it now
My rule is: if a tool is going to be used by more than one app, it becomes an MCP server. If it's a one-off for a single agent, I keep it as a plain function. That's kept things simple.
The bigger shift is mental. I've stopped thinking of "the agent" as one big program and started thinking of it as a model plus a set of capabilities it can plug into. That framing has made our designs a lot cleaner.
If you've been holding off because it felt like a fad, I think the window for that excuse has closed. Pick one internal system, wrap it, and see how it feels.