We Stopped Building UIs for Mock Servers. Instead, We Gave Them to an AI Agent.

At proSapient, we connect clients with industry experts. Our clients range from large consultancy firms and private equity funds to corporate strategy teams and other research-driven organisations. Many of them run their own platforms, and we’re often integrated directly with those systems.

In the more advanced setups, that integration goes pretty deep. Project requests come straight into our platform, relevant expert information is shared through controlled workflows, and call scheduling is synchronised between both sides. It works well and keeps everything moving in real time.

The downside is that everything becomes tightly coupled.

The problem

Any change around the integration boundary needs to be handled carefully. You’re not just updating your own system — you need proper end-to-end testing, and quite often the client’s engineering team has to get involved. They trigger actions on their side, check payloads, and help validate edge cases.

That dependency slows things down. Releases take longer, coordination becomes part of the process, and over time it starts to affect confidence. When every change has the potential to break a live client connection, teams naturally become more cautious.

Sometimes a bit too cautious.

The obvious answer (and why it wasn't enough)

Mock servers are usually the first thing that comes up. You replicate the client API, simulate the workflows, and run tests independently.

In reality, it wasn’t that straightforward for us. None of our clients provided mock servers for their platforms, so if we wanted one, we had to build it ourselves.

That was always technically possible, but before the recent wave of AI tooling, it was a significant investment. You’re not just building the API layer — you also need some kind of interface so engineers can manage state, trigger scenarios, and inspect what’s going on. In practice, the UI can end up being almost as complex as the mock server itself.

At that point, it starts to feel like a project of its own.

So we stepped back and looked for a different approach.

The insight

The idea came out of a pretty practical situation. We had two client integration projects running in parallel, and both required mock servers we didn’t have. Given the complexity of the changes, building them stopped being optional.

While working through that, we realised something simple. The only people who were ever going to use these mock servers were our engineers and QA team. And by that point, everyone was already working daily with tools like Claude Code or Cursor. Talking to an agent had become a normal way to get things done.

That led to a different question:

What if the agent is the interface?

Instead of building dashboards or control panels, we expose the mock server through MCP (Model Context Protocol). In practice, that’s just a structured set of tools that an agent can discover and call.

No separate frontend layer. Just the mock API and an MCP layer on top.

The architecture

Under the hood, the mock server is fairly simple. It comes down to three main pieces.

API layer — inbound endpoints that accept requests from our platform, mirroring the client’s API surface. We generate most of this from their Swagger/OpenAPI specs.

Webhooks — outbound notifications that simulate client-side events and callbacks.

MCP interface — a set of tools exposed via Model Context Protocol. Each tool maps to something meaningful in the workflow, like creating a project, submitting an expert, or scheduling a call. Others are there to inspect state — listing active requests or checking call history.

Engineers connect to the MCP server from Claude Code or Cursor and just interact with it directly.

In practice, it looks something like:

• "connect to server at … using client id …”
• "create new project on that connection"
• "show me experts submitted to this project"

Nothing special in terms of syntax — just describing what they want to do.

The agent takes that input and turns it into tool calls, and the mock server executes them. You don’t have to click through forms or remember exact API payloads anymore.

How we built it

We sketched out the initial version in a day using Claude Code. Both client integrations came with well-defined OpenAPI specs, so getting the API layer in place was relatively straightforward. The specs were enough for Claude Code to generate endpoint stubs and data models that were close to what we needed.

From there, we started filling in the gaps. We added multi-tenant support, since we usually run several integration environments in parallel. Then webhook signing to match production authentication, and finally the MCP layer on top.

By the end of the week, we had something running in our test environment and ready for manual integration testing.

What changed

The impact was noticeable pretty quickly.

The most obvious one was speed. Engineers could iterate against the mock server without waiting for the client side to be available, which removed a lot of the usual friction.

It also changed how we plan testing. Instead of coordinating windows with client engineering teams, we just run everything on our side, when we need it.

Another big improvement was around edge cases. Things like webhook failures, malformed payloads, or race conditions used to be difficult to reproduce consistently. Now they’re easy to trigger on demand.

But probably the biggest shift was confidence. Teams are much more comfortable shipping integration changes when they’ve already exercised those scenarios in a controlled environment.

QA feedback was very positive as well. What used to be a fairly painful coordination process around integration testing is now much more straightforward.

The takeaway

Mock servers themselves aren’t anything new. What changed for us is how we build them and, more importantly, how we interact with them.

With AI coding agents, MCP, and existing API specs, the effort dropped significantly. What used to feel like a multi-week (or even multi-month) project, especially once you factor in a UI, turned into something we could get up and running in about a week.

The interaction model is probably the more interesting part. Once you rely on the agent as the interface, you don’t really need a frontend layer. Capabilities are easier to discover, and interacting with the system feels much closer to how engineers already work day to day.

At proSapient, we’ve always believed in building systems that amplify exceptional people rather than replace them. This approach fits naturally into that mindset — keeping engineers in the loop while removing a lot of the mechanical overhead around testing and tooling.

If you’re dealing with complex third-party integrations and still depend on external systems for testing, it’s worth taking another look at how you approach this. The trade-offs have shifted quite a bit recently.