Due to the simple fact that three is less than half of seven, I’ll be referring to model context protocol as it’s initialism MCP. I believe it’s better known by it’s initialism anyway so I don’t believe anything has been lost.
I will not be explaining how MCP works. I’m going to talk about how to actually use it. If the use-cases I write about seem like they’ll work for you, I’ll have examples and links to appropriate documentation at the end of the article.
MCP is a standard by which chat applications can interface with things outside of the chat application without the developers specifically implementing those interactions. They implement the client side of the protocol and provide a method for users to register their servers and they effectively can now support infinite variations of interactions.
While this may sound amazing and easy, it does come with some very important restrictions and risks. Some of which remain with standard agents, some of which are new.
Likely the most important restriction is that the chat application runs on the user’s machine. The servers should also run on the user’s machine, but if the chat application / MCP client allow for a more complex authentication than it’s less of an issue. Importantly though, is that the tools/prompts/resources are still run from the agent in the chat application running locally.
If you do not run the MCP servers on the user’s device, you lose out on accessing anything on the device. If your use-case is a more controlled agent-based chat application, using MCP will not help you in most cases as they expect to be running on a user’s device. Most MCP servers currently require auth credentials provided as an ENV.
If your use-case is a more controlled chat based flow, google’s A2A may be a better mechanism for you. The unfortunate situation with A2A is that google is notorious for it’s new products being virtually unusable, but that may not be the case for A2A. I haven’t had a use-case that wouldn’t live in a dev environment yet so I’ve yet to dive in to that protocol.
Does that mean you can’t build your own MCP client and your own MCP servers to use with them? No of course you can, but MCP itself isn’t really needed in that case. You should only add a process/network abstraction if it’s meaningful, and if you control both sides I’d argue it isn’t.
The number one place I’ve seen MCP in is agentic coding tools like Claude Code or Cline. That’s because you can use MCP to enhance your development with context and actions provided by the server. Many of the interactions can be used to simplify or provide context to these tools.
Say for example you need to build a new table and API endpoints for that new table. You can use an MCP server that supports your database to understand it.
As the agent understands that information (through the MCP server) you can ask it to generate your new table and update any relevant indexes or procedures that should include that table. You can then ask it to make the same changes in your API as it’ll have the context of everything that changed in the database.
Can that be done by hand? Of coarse it can. I might even suggest doing the database changes by hand and automating the API changes. You could also do the reverse. Add the API changes, either by hand or agent, and have the agent make the database migration file. This can be tested through agent if you have integration tests for your API.
That’s a use-case that’s really only solved through MCP or other similar protocols running locally. As only by running locally will you have all the context.
My personal ultimate use-case for MCP is the generation of CI (continuous integration) yaml files. Quite a bit of my job involves the process of getting code deployed. If you've ever worked with a sufficiently large number of applications, this can be complicated. Simplifying that is generally done with reusable components.
The issue is how do you get teams the appropriate context to generate CI files with the reusable components and the values for those components? MCP allows you to inject that context in a number of ways. You can inject the format and usage of the components as resources. The values for the components can be filled by tools or resources. If the user if having an issue with their CI they can sanity check the values entered into it.
There are a number of similar use-cases. Enterprise design systems or libraries are a good one. Enterprise data cataloging is another. Your enterprise might want data named a certain way for lineage purposes. Using an MCP server to provide that context can save time later on. While you can use validation tools to check things before you commit them, making them correct the first time is always better.
Now that we've got a few use-cases I want to go over some not-so-slight problems with MCP.
While agents have always had the issue of needing to limit the scope of what they can do, MCP is on a whole different level. You should not, under any circumstances install an MCP server from an unstrusted source. I would even go so far as to say don't install them from a trusted source either unless they have a signature verifiable SBOM attached.
This is because they run on the user's machine, with the same level of access as the user. If you have anything in your session or in files readable by default by the user that could be secret, those can be read. If you have any credentials in your environment variables those can be read.
Even if you don't intend to expose any extra credentials to the MCP server, and even if the MCP server itself doesn't do anything with credentials, any dependancies that have been compromised might scrape that information anyway.
Additionally, new attacks are being routed through memory and agent guidance files. They use unicode characters invisible to readers but not by machines to jailbreak and execute malicious commands in chat agents.
It's the lack of sandboxing that makes it such a risk. Using containers for running the actions will allow you to sandbox them, but that's really only a solution for linux/mac. I'm not really sure what a solution could look like for windows.
The plus side is that most use-cases that I have would be completely custom made, and therefore implicitly trusted. The issue though is that as people experiment with this tech it will be extremely risky. Any popular community MCP server is going to be ruthlessly attacked for now by malicious actors, and with little/no controls over which servers a user can install it's more important than ever that user's access is limited as much as possible during normal operation.
In short, MCP is real great for certain use-cases, but potentially apocalyptic as far as security goes. Use trusted servers and you'll be fine.
Links