Some people insist that MCP will make APIs obsolete. "I use MCP with OpenAPI all the time," shared Emmanuel Paraskakis, the founder of the API consultancy and training firm Level 250. We sat down together in December 2025 at the apidays conference in Paris, and we had a great chat around MCPs and APIs in general. According to Paraskakis, "if you have really good OpenAPI, (...) it means that you can produce a really good MCP server that has a good task success rate for the LLM." Watch the full recorded interview or go through the transcript to get all the details.
This article is brought to you with the help of our supporter, Scalar.
Scalar is the modern OpenAPI platform for the entire API lifecycle. Govern APIs with Scalar Registry, test offline with their built-in Client, generate beautiful documentation, and ship SDKs instantly - all from your single source of truth.
The “Behind the APIs” interview series is a collaboration between Scalar and the API Changelog newsletter.
Here’s the transcript of the “Behind the APIs” session with Emmanuel Paraskakis. Parts of the transcript have been edited for improved readability.
Bruno Pedro: Hello, I’m Bruno Pedro, and we’re here at the apidays conference with the collaboration between Scalar and the API Changelog newsletter, “Behind the APIs,” where we interview different people who are practitioners in the API industry. And today I have here with me Emmanuel Paraskakis. Emmanuel is the founder of Level 250. It’s an API consultancy and training company, and Emmanuel has decades of experience in API product management. Thank you, Emmanuel. I’m very happy to have you here. I know that you’re also participating as a speaker in the conference. There are a few interesting topics that I would like to talk to you about, and one of them, I know it’s a very hot topic right now: it’s MCP!
Emmanuel Paraskakis: Of course! I just got done doing a talk on MCP, so it’s on everybody’s mind. Yeah, I think that the need was there even before MCP. We saw, for example, OpenAI trying to do something like that with the function calls, where you could attach an OpenAPI, and it would try to bring it in. And then there were other efforts out there. There was one called agents.json that I thought very highly of because it used OpenAPI. But unfortunately, I think with technology, it’s not always the best technology or the one that we all hope for. It’s the one that gains traction. And MCP did gain traction. I think it was at the right place, right time, backed by the right people. Maybe those people didn’t have a lot of experience with these specs and APIs, and so on. So, you saw them go through various stages, but it’s open, there’s a lot of backing, and it’s evolving very, very fast. So, if we didn’t have MCP, I think we’d all be writing a little bit of point-to-point integrations, or some other similar kind of thing would have come up because the need was there.
BP: Right, right, right. Interesting, interesting. You’re right, MCP has been getting a lot of traction lately, and proof of that is, you know, the latest news that I’m sure you know about.
EP: Oh my gosh. Yeah, that was amazing. I woke up this morning and learned that MCP is now donated to a foundation, part of the Linux Foundation, which, to me, had echoes of OpenAPI. And I think it’s the right move to do. If you see who’s backing this, it’s all the right names, all the big names. So, I think that solidifies. Anybody who’s going to say, “Well, oh, you know, maybe MCP is not going to be a thing, you know, somebody else is going to come up with an alternative protocol.” When all of these big companies are behind it. It becomes very, very hard to have an alternative, even if it’s better.
BP: Yeah, it’s not just an attraction anymore. Now it has become a real standard that people can trust more. In a way, they know that it’s not going to go away. It’s not going to be abandoned. Yeah, yeah. Exactly, exactly. Exactly. Interesting. Interesting. Yeah, I mean, everyone knows more or less what MCP is for, but, in your opinion, what are the problems from a product perspective that MCP is really solving?
EP: So, I mean, the biggest problem that’s being solved is being able to connect data or APIs or actions to an LLM. If you think about how LLMs work, they are trained on their training data, which has a cut-off date, and that cut-off date could be, you know, months behind. And then you can bring in some more current data with RAG, but it’s still kind of static data. But for agents to be really, really useful in the world. If an agent wants to buy something, make a phone call, or, you know, look up the latest status of your ticket or a price. Then it needs real-time information. And we didn’t have something to get the real-time information. MCP is it. It’s basically, on a time continuum, the thing that gets you the dynamic current data. So that’s essentially the purpose. And secondarily, also it’s kind of like, I know it’s tired to say, USB-C, but it’s a good analogy. So, instead of doing point-to-point integrations, you all speak the same protocol, and hopefully you meet in the middle, and hopefully everything works.
BP: Yeah, it’s basically the USB-C analogy. I think it’s handy because it helps people see it, you know, visualize it as opposed to thinking about something that is hard to understand how it works.
EP: Now, I was saying in my talk today that it’s like USB-C, but maybe USB-C in 2015. Where we had agreed on the plug, on the connector, but not so much on what goes over the wire. People were still doing different things, not adhering to the spec.
BP: In a way, what’s been standardized was the pipe and not what goes in the pipe.
EP: But we’re rapidly advancing. We’re getting there, I think.
BP: Yeah. So, so behind the scenes, many people ask me also this, “What is actually going on behind the scenes on MCP?” Isn’t it just an API, in the end?
EP: I think at a high level, it is an API. And, it’s another iteration of APIs. So, just because it has more native capabilities for AI. I mean, that’s great, but it is by all definitions an API. And we need that API.
BP: Yeah, I mentioned it because people who prefer to use OpenAPI initially thought that MCP would go against OpenAPI or would be used instead of OpenAPI.
EP: I use MCP with OpenAPI all the time. And I find that if you have really good OpenAPI, which probably means also you have really well-structured APIs. I find it means that you can produce a really good MCP server that has a good task success rate for the LLM. So, hand in hand.
BP: Right, right. Yeah. Interesting. And the progress of MCP has also been interesting to follow. As you said just moments ago, it started very, you know, in a very, I would say, I mean, it started in a hackathon in the end. So, as some toy that someone just put together, and it’s been growing, and people have been adding more and more features to it. In your opinion, what are still the gaps that MCP has nowadays?
EP: So, before we talk about the gaps, I think one of the problems with MCP so far has been that the spec is iterating very, very fast. And that means whenever the spec iterates fast, it’s hard to adopt. Right? Because new things, new significant things are coming out, and it’s difficult for people to adopt it. And therefore, you have people adopting different versions of the spec at different times, maybe not the entire spec. And so you have this situation, which is normal, I think, in our situation. From what I heard from the maintainers, the spring version of the spec is going to be the last one that has really big changes. They’re going to try then to kind of slow the changes down so the adoption can catch up. So I think that’s great. I think we are doing a lot of things well for authentication. There is the URL mode elicitation feature that just came out. I think that was the one thing I was looking for to integrate well with the APIs. We have the asynchronous feature that is coming online. We have a lot to do with authentication. A lot of convenience things like icons and whatnot. So, we’re seeing a bit of maturity, I think. The gaps are still with security, you know, the S in MCP stands for “secure,” the old joke. And it’s also, I think, a tooling thing. I think all the AI gateway and the MCP gateway folks are going to step in and try to solve some of this because nothing in the spec is going to, I don’t think, help you solve, for example, prompt injection. If you can either pass in a prompt or whatever input is coming in can be interpreted by the LLM, the helpful LLM, as a prompt, then you’ll always have this problem. So I think it’s a tooling thing, it’s a it’s a best practices thing. So I think mostly the gaps are now in the execution and adoption, and developing the governance and best practices. Hopefully the API folks can help a little bit with the experience that we have in the governance. On the other hand, we see some new directions like MCP UI and MCP apps. So, that’s a whole new different thing. And we’re going to have to evolve on those as well. And I’m not sure how much a core part those are going to be from MCP, but they are there to address a gap. Why not make UIs? Why not make apps?
BP: Yeah, it shows that there’s a lot of creativity as well, and that means that the spec allows this creativity to happen. The spec is not rigid and closed.
EP: And I think it’s a good group maintaining this spec. They have a good process, very dynamic, lots of interested people, and lots of interest and investment from the participants. They’re really big companies.
BP: Yeah, that means that those participants see it as the future. One thing you said makes a lot of sense to me. You mentioned that some of the areas that will still be needed are related to, for example, to governance and other areas that some of the API folks could chime in and help with. Do you see now with the maturity of MCP... After all, MCP is just a spec. So, it’s not, let’s say, the implementation of the protocol. But do you see with the maturity of the spec it being more managed in a more product-oriented fashion in the future?
EP: Well, that’s a good question because that wasn’t the case when it started out. It was very much an engineering-led type of thing. I think that’s a TBD for the spec itself. Right? I think the economic and other types of realities are going to enforce a product approach. It’s not going to be like “Oh let’s just build it because we can,” because again, the investment and all these partners, they’re going to now follow us. They’re going to make it part of their products, and now if it’s part of their products, they’re going to pay attention to it. And so it’s not going to be science projects only. On the other hand, I think if you are doing a product-based approach for your APIs or other developer tools, I think that MCP can fit in there very well. So, if you are an API product manager, I think you are now also becoming the MCP product manager because, as we said, MCP is another kind of API.
BP: Interesting, interesting. Yeah, I think I feel the same way, you know, going forward, many people are still looking at it in this duality type of reality, MCP versus APIs. But I think behind the scenes, you know, MCP is in fact JSON-RPC. Which is one of many possible styles of APIs. Interesting. I’d love to keep chatting about these things, but we don’t have all the time in the world here. So thank you, thank you so much for sharing these thoughts.
EP: Thanks, Bruno. This is fantastic.
BP: Thank you, Emmanuel.
EP: All right, sir.
