I’ve been programming services for more than 20 years now, and REST is my tool of choice. It’s such a standard way to communicate the capabilities of your system that it is a given whenever any component is created, whether you choose to go contract-first or add endpoints as you go. In the end, you have a beautiful API, visualized by a colorful Swagger UI which proudly presents your OpenAPI spec.

I almost forgot the dark days of SOAP with its inevitable XMLs, WSDLs, and other terms I’d rather erase from my memory.

Will I feel the same about REST in the future?

When I started using AI agents, I thought it was fun: letting AI build stuff for me, encouraging it to code this and that, programming by hand whatever it couldn’t manage. But the agents got smarter and better, and I rarely do anything but prompt and review code anymore.

Then, MCP came along. At first, I thought it was very helpful: you could access your database, Jira, Confluence, GitLab, and whatever other tools you needed directly from your terminal and ask AI to fetch data, update your tickets and wiki, or manage your PRs without using any other tools.

After a while, it got me thinking: why don’t we add an MCP server in each service, alongside its REST endpoints, allowing agents to access the data in the same way? That would mean I could fetch and manipulate data from my services, again — directly from my terminal.

That is, I don’t want to throw away my Postman/Insomnia/Bruno/whatever collections just yet, but it’s very handy to just ask AI to fetch data from a certain service.

And the best part is that you could combine data from multiple sources and ask the agent to do amazing things with it. I imagine if we teach our business people how to use agents that way, it might help them do some cool stuff like promoting “fetch customer data for the last month, and sales data for the same period, and visualize both in a table plus some nifty graphs”.

Who needs APIs, right? Who needs UI?

I’m exaggerating, of course. But using MCPs to access your services adds a measure of ad-hocness that is hard to achieve with traditional tools, because it is hard to consider all the ways you’d want to combine and explore your data and implement every use case you can imagine.

The ultimate interface is your terminal. It gives you endless ways to access and manipulate your data without UI limitations.

But to achieve that level of freedom, there are several aspects to consider:

• Security — of course, you don’t want to allow just anyone to access your precious data. So you need to control which clients can fetch and manipulate data from your services. MCP servers can use traditional ways to protect access, for example by using OAuth2, but getting tokens for your users to access MCP can be tricky.
• Discoverability — when you implement a new service and add new MCP endpoints, how will you share that knowledge and access with your users? Do you need a catalog of service MCPs that users can use?
• Versioning — just like you can’t make breaking changes to your REST endpoints, you can’t do the same for your MCPs, because some services might depend on your endpoint signature and expect the parameters and return value to look in a certain way. What is the proper way to version your MCPs?

I’m certain this list can be longer, but for now, I’d like to think we’re in the midst of some interesting times. It’s a revolution, if I may predict the coming future, in which MCPs will change the way we interact with our services. The terminal made a huge comeback when we started interacting with AI agents, and I think this is only the beginning.

Will MCP Kill the REST Star? was originally published in Geisli Consulting AB on Medium, where people are continuing the conversation by highlighting and responding to this story.