Generating and Improving GraphQL API Mocks with AI Agents

Tom Akehurst

CTO and Co-founder

May 22, 2025

Table of Contents

This is some text inside of a div block.

GraphQL development can stall when you're blocked by unfinished backend components. Mocking your graph as you develop can help mitigate this, but working with GraphQL mocks can be uniquely time-consuming relative to other API types due to the often large and varied payloads that need to be constructed. AI can help with this by generating realistic data, expanding the range of queries responded to and assisting with maintenance of the mock as the schema evolves.

Below we outline a solution that combines WireMock and Cursor AI to generate a schema, build a mock implementation for it, then refine and enhance the data returned.. This lets you keep building and prototyping while the backend is still in development, and to improve your graph components as development progresses.

In this post, we'll show you how to implement this with a travel booking application example. You'll see how you can use agentic AI to analyze your codebase and generate appropriate schemas, while managing functional mocks in WireMock, which you can refine as you go.

A quick recap: MCP integration and GraphQL simulation

We’ll be using a few WireMock capabilities below, so here’s a quick recap of how they work:

WireMock's MCP server allows developers to create and manage mock APIs directly from their IDE through AI-powered coding assistants. It enables your AI coding agents like Cursor or GitHub Copilot to analyze your codebase, identify API dependencies, and automatically generate appropriate mock endpoints in WireMock Cloud - all without leaving your development environment.
Recently-introduced GraphQL mocking in WireMock Cloud lets you quickly simulate GraphQL APIs based on a schema and query response, and then add more sophisticated behaviors like response templating for dynamic data or simulating errors. WireMock also supports GraphQL federation, handling both individual subgraphs and entire federated supergraphs.

The use case we're solving for here

To return to an example we’ve used previously, imagine you're building a travel application. Your product manager wants a "Manage Bookings" page showing flights, hotels, car rentals, and activities. Simple enough—but several backend services providing this data are still being developed by other teams.

In our previous article, we showed how you can use WireMock Cloud to quickly generate some randomized data that matches the types and general shape of what you’d expect to see. This makes getting started far easier than traditional GraphQL mocking approaches which require you to define everything in advance; however, this requires that schema to actually exist, which might not always be the case if components are still being developed. There are also obvious limitations to using randomly generated data in terms of maintaining realistic test suites and relationships between entities.

This time, let’s look at what happens when we want to simulate realistic data that mirrors what the real APIs will deliver - booking references, valid flight numbers, actual airports, and logical travel dates - and to do so before the actual API exists.

With modern tools and AI assistance, you can create these realistic GraphQL mocks quickly and refine them as your understanding evolves, letting both frontend and backend development proceed in parallel. Our idea here is to unblock teams even earlier in the development lifecycle, minimize rework, and also allow us to make our APIs better during active development.

Using AI to prototype changes quickly and realistically

Now that we understand the challenge - building a travel booking page with incomplete backend APIs - let's see how AI can speed up our solution.

The video shows a method that wasn't possible a year ago. Instead of spending hours manually defining GraphQL schemas and creating test data, we're using Cursor AI with WireMock MCP server to handle the heavy lifting.

WireMock MCP connects AI coding assistants directly to WireMock Cloud. Tools like Cursor AI analyze your code, understand what you're building, and publish mock API changes -right from your IDE.

Here's how our solution works:

1. Generate the initial schema.

We prompt Cursor AI to create a GraphQL schema for our travel booking API by analyzing existing models, UI components, and service interfaces. It infers relationships and generates a schema with all the types we need—bookings, flights, airlines, hotels, etc. Using the MCP integration, this schema is automatically published to WireMock Cloud.

2. Generate initial data

Remember - the way GraphQL simulation is implemented in WireMock Cloud means that once we have this mock, we can start querying it immediately. When we query this endpoint through Postman, WireMock generates valid (but basic) test data based on the schema. The data is in the right shape, but it is not really realistic as it is generated using the Faker library.

We can then convert this response data into a stub in WireMock Cloud:

3. Refine the data with AI

Here's where it gets interesting. Once we’ve converted any request to a stub in WireMock Cloud, then ask Cursor AI to improve the data and make it more realistic:

‍

As we discover more API needs, we can keep improving the schema and data. For example, we can create variations for specific testing scenarios, with data shaped to test particular edge cases or user flows, or for individual booking queries based on. As we continue to leverage AI assistance to handle most of the implementation details, this makes the entire process of developing, testing, and refining GraphQL APIs significantly more efficient.

Iterating on the API based on our prototype

Prototyping with schema can guide the development of GraphQL APIs, and the features that depend on them. Traditional approaches often have backend teams building detailed schemas in isolation, only to discover they missed what users actually need. With our method, your prototype becomes a working specification that shows real-world requirements early. You can also discover issues much earlier by seeing how the queries from your frontend and how they interact with mock data.

This benefits the team producing the API because it gets clear requirements for how they design the schema and response formats. By working with very detailed prototypes and testing them against various simulated scenarios, developers can spot design issues before things are implemented in production, rather than after - so that by the time you start actual API development, you've eliminated much of the guesswork..