At Shift 2026, Edvin Teskeredžić made a case that is easy to miss if you only look at the MCP hype: REST belongs on the delivery path, and MCP belongs around it as an architectural boundary, not a branding distinction.
Delivery systems need contracts that are boring, deterministic, testable, and repeatable. Agentic workflows are useful in the messy parts around delivery: discovery, setup, troubleshooting, guidance, and safe automation. If you try to make one layer do both jobs, you usually end up with worse APIs, harder testing, and an agent that looks clever right up until it touches production.
Why “just replace REST with an agent” sounds attractive
Edvin opened with the temptation many teams feel when they first get excited about AI systems: why not remove the API layer and let the model decide everything?
The pitch is seductive. One endpoint instead of many. No SDK sprawl. No versioned docs. No need to map every workflow into a conventional API shape. Just let the agent handle it.
The approach sounds tidy until you look at what production systems need. And most of what’s needed are the things agents aren’t good at by default:
- clear contracts
- deterministic behavior
- predictable auth and observability
- manageable latency
- bounded cost
- repeatable testing
Agentic systems are non-deterministic. They are harder to test. They are worse for high-volume, latency-sensitive work. And if you are paying for tokens, “let the model figure it out” approach is not a free abstraction, it’s an invitation to considerable cost surplus.
Edvin’s position was blunt: if your goal is a good software system, not a social-media demo, you should not put an LLM on the hot path just because it can talk convincingly.
The telco model makes the split obvious
To explain the boundary, Edvin reached for a telco analogy, and it holds up under scrutiny better than most software analogies do: telco hardware is built around this separation, not just loosely inspired by it.
Take BGP, the protocol Edvin referenced in the talk. A router has two very different jobs. The first is deciding where packets should go: exchanging reachability information with other routers, applying policy, and calculating the best path. That is the control plane, and BGP lives there.
The second job is actually moving packets according to whatever the control plane decided. It’s called the data plane, and it is kept deliberately simple.
Once the control plane makes a decision, it hands the data plane a simple rule: send traffic A to interface X, toward next-hop Y. Traffic A is some category of packets, say, everything headed to a particular destination network. Interface X is the outgoing port the packet should leave through. Next-hop Y is just the next router in line, the one this router should pass the packet to on its way to the final destination. The data plane then executes that rule on its own, independently of the control plane, even when the control plane fails.
As you can see from the example above, the resilience is not theoretical. Cisco’s Nonstop Forwarding with Stateful Switchover and Juniper’s Graceful Routing Engine Switchover exist specifically so a router keeps forwarding packets while its routing protocols recover in the background. The control plane can go down, while the data plane keeps working.
None of that separation is a coding convention or a naming choice. It is enforced by the hardware itself: these planes typically run on different processors, different subsystems, sometimes different cards entirely.
This design principle is exactly what is worth taking from telco. Not the specific technology, but the approach: splitting the work into high-level, multi-step operational work, and low-level work that skips complex logic in favor of fast, high-volume, reliable delivery. Framed that way, it becomes much easier to see which parts of a system are worth handing to an agent and MCP, and which parts need to stay on plain REST.
That is exactly how Edvin framed the relationship between REST and MCP:
- REST is the delivery path
- MCP is the operational layer around it
REST should stay deterministic and boring. MCP should help agents and humans handle the work around the system, not become the system itself. Or, as Edvin put it more memorably: “MCP is not the thing. MCP is the thing that gets you to the thing.”
MCP is a briefing layer, not a smarter brain
If MCP is the operational layer around REST, the natural question is what that layer does for the model. Edvin’s answer: MCP works less like a new brain and more like a structured briefing. It gives an agent access to the right capabilities in an organized way, without changing what the underlying model is capable of on its own.
It still needs guardrails. It still needs permissions. It still needs carefully designed tools.
That is also why Edvin emphasized that tool annotations (the read-only, destructive, or idempotent labels a tool declares about itself) are only hints. They are advice, not enforcement. Enforcement must happen in the server and in the surrounding system.
The practical takeaway is simple: treat an MCP server as a curated interface for tasks an agent can do well, not a dump of every endpoint you already have.
The next question is which tasks actually qualify.
The best MCP jobs are the ones humans hate
One of the strongest parts of the talk was Edvin’s list of where MCP belongs, and it follows one simple pattern: pick the jobs humans already hate doing. Good MCP work looks like operations, not delivery:
- discovery
- setup
- state inspection
- troubleshooting
- guidance
- safe automation
Those are the jobs where agents can remove friction without putting the core product contract at risk.
His example of sender provisioning made that concrete. Provisioning is a workflow that is painful for humans: it changes by country and regulator, involves compliance documents and verification steps, and often comes with a pile of configuration that’s easy-to-get wrong or forget. That is exactly the sort of multi-step, rule-heavy work an agent can help orchestrate.
The agent isn’t replacing the workflow, but rather it orchestrates it while the underlying delivery APIs stay clean and predictable. If you already have stable transactional APIs, you do not throw them away just because MCP arrived. You add MCP where it helps with operations and developer assistance.
Knowing where to add MCP is only half the problem, though. The other half is not overdoing it.
More tools is usually worse
A second useful theme from the talk was restraint.
Edvin argued against wrapping every endpoint in MCP. That sounds intuitive, but in practice it creates two problems:
- tool bloat: too many tools make selection harder for the agent
- context rot: too much tool metadata burns context before useful work starts
The better approach is to design task-oriented tools. One tool can call several REST endpoints under the hood if that is what the task needs. That keeps the surface area smaller and makes it easier for the model to choose the right action.
This is a useful rule even outside MCP. APIs are not valuable because they expose everything. They are valuable because they expose the right thing cleanly. That restraint isn’t only about usability, though. A smaller, well-designed surface is also easier to secure than a sprawling one, and that’s where the talk went next.
MCP raises the security bar, not the convenience bar
The talk spent a good chunk of time on failure modes, and that part deserves attention.
It pointed to the “lethal trifecta” problem: a system becomes dangerous when it combines:
- access to private data
- exposure to untrusted content
- the ability to communicate externally
That combination has already caused real MCP security issues, and the lesson from them is straightforward: agentic systems need stronger governance, not looser process.
His design rules were the right ones:
- keep deterministic delivery on APIs
- separate read and write tools
- confirm destructive or expensive actions
- scope tools by tenant and role
- log every tool call
- use structured outputs
That last point matters more than people sometimes admit. Plain text outputs are easy to start with and easy to regret later. Structured outputs force the system to state what happened in a way that can be checked, traced, and retried.
The framing was clear: most of these are not new ideas. They are the same things we already do in API and microservice design. The difference is that the caller is now an agent, which means the defensive posture must be explicit.
A recap of what all this means for teams building with agents
The talk’s strongest claim was also its simplest:
REST is how the system does the work. MCP is how agents understand, configure, and operate it.
That is a useful rule of thumb because it prevents two common mistakes.
The first mistake is trying to make agents the delivery layer. That usually creates fragile systems with vague contracts and weak observability.
The second mistake is treating MCP as a one-to-one mirror of every API endpoint. That usually creates tool sprawl, poor selection, and context waste.
The better path is a two-layer model:
- keep delivery deterministic and boring
- add MCP where workflows are operational, multi-step, and useful to automate
That is also where the Infobip Provisioning MCP server fits in. The transactional APIs still do the actual delivery. MCP helps with the operational workflow around them.
For developers, that is the practical takeaway from Edvin’s talk. Don’t ask whether MCP replaces your APIs. Ask which parts of your system are real delivery, and which parts are just the awkward work around delivery.
The answer is usually not “all of it.”
It is “much less than the hype suggests, and exactly where humans keep getting stuck.”
The slides of Edvin’s talk are attached below and include the full list of references and further reading.
