Shaping the MCP at GWI

This was a new experience for me. The MCP was a surface with no UI to manipulate. The outcomes were non-deterministic, and it sat on a data model with hard rules. Most of the design work happened in the connective tissue between them: the orchestration of the MCP, GWI's architecture, the client, the tools, the skills, and the resources.

Moving at pace

The landscape moved weekly. Frontier models shifted, clients were building proprietary tools, and I had to move fast to keep up. There was no design system or best practice for AI-native surfaces, so I had to define what good looked like.

The Impact

Since November, the MCP grew, fast.

• Users were able to query GWI data using objects they'd built on the platform.
• MCP usage skyrocketed between November and June.

That growth was why UX mattered. Users kept hitting the same walls, and we had to carve out a real happy path for the thousands of requests coming in.

The Problem

We spoke to around 100 users to hear what was working, what wasn't, and how they were actually working. Two topics kept coming up:

• Users wanted to query using audiences they'd created in the platform.
• Users wanted access to custom study data in the MCP.

The Challenge

GWI's data already had a structure, and that structure set the constraints for the experience.

Datasets

Each dataset is a survey that a set of respondents answered. Datasets are grouped under a top-level ecosystem, and an ecosystem can hold several studies beneath it. Custom studies are client-commissioned datasets that live under an ecosystem. Ecosystems aren't compatible with each other, since the respondents are different.

Audiences

A saved group of respondents, built by the user. Every audience is pinned to a single dataset or ecosystem.

A single organisation could have 100+ meticulously built audiences, and even more custom studies, on top of our global datasets and ecosystems. Respondents belong to one ecosystem, so audiences and studies from different ecosystems can't be combined. This rule is invisible to the user and easy for a model to trip over. Designing around it, without making the user learn it, was the real work.

Ideation

I started by mapping a hybrid user-flow and system diagram. It got us aligned on the happy path, but it also mapped out the error handling we'd need to navigate, and helped us think through which tools the flow required.

We mapped out the tools we'd need to solve the problems. There ended up being three:

• List Datasets. Lists a user's available datasets and lets them switch them on and off.
• Audience Browser. Lets users semantically search their audiences by title, description, and metadata.
• Audience List. Lists the audiences a user has saved to the platform.

The tools were the easy part. The hard part was the state between them, and how a change in one rippled into the others. Three decisions did most of the work.

Selecting an audience with nothing active shouldn't dead-end. So it auto-activates the audience's parent dataset and tells the user it did. They name what they want, and the system works out where it lives.

Clearing a dataset shouldn't wipe your work. So clearing the filter keeps your selected audiences and just widens the view. Switching to an incompatible dataset is different, and that one warns you first, because it has to drop what no longer fits.

A cross-ecosystem pick shouldn't fail silently or throw an error. So it becomes a choice, with the cost spelled out: switch and lose the current selection, or stay. The one-ecosystem rule is the highest priority in the system, and nothing overrides it, but the user always sees the trade before it happens.

None of this shows up as UI. It's a set of rules the model follows so the valid path stays the easy one.

Here's the whole thing in a single session, annotated.

I wrote the flow as a skill: markdown-defined guidance that runs inside the MCP itself.

That gave the developers a working prototype of how a user should move through the tools. It closed the gap between "here is what I mean" and "here is the thing running" to almost nothing, and it turned out to be the most useful handover artefact of the whole project.

MCP Apps

In January, the MCP launched MCP apps. This opened up some interesting use cases and gave us a surface to solve more of our users' problems. It looked like a big opportunity at first, but after some discovery there were a few cons:

• Another surface to maintain.
• Doesn't work for all clients.
• UX and UI restrictions imposed by the frontier models.

We decided to treat MCP apps as a bonus for the clients that could ingest them. We still needed a text-relay fallback that would work with any agent, though.

Datasets to sync - pick ONE ecosystem (Core, USA, or Kids); they're not compatible.
Reply "select USA", "toggle <name>", "expand <name>", or "clear".

├ (~) ▼ GWI Core
│  └ [~] ▼ GWI Syndicated
│     ├ [x]   GWI Core Plus
│     ├ [~] ▶ GWI Pulse          [13]
│     ├ [x]   GWI Alcohol
│     ├ [x]   GWI Automotive
│     ├ [x]   GWI Consumer Tech
│     ├ [x]   GWI Gaming
│     ├ [x]   GWI Luxury
│     ├ [x]   GWI Moments
│     ├ [x]   GWI Sports
│     ├ [x]   GWI Travel
│     └ [x]   GWI Work
├ ( ) ▶ GWI USA
└ ( ) ▶ GWI Kids

(•) active ecosystem  ( ) inactive  (~) active, partial
[x] selected   [ ] not selected   [~] partial
▼ open   ▶ closed

Using Cursor, I built a prototype MCP app wired directly to Claude. That gave us something real to demonstrate to the business, and a foundation of ideas to build on.

What Shipped

One MCP app, three tools, and their instructions all shipped across four months. Users could now query GWI data using every object they'd built on the platform.

What I took from it

The interesting part of this project was never the UI. It was designing a set of rules a probabilistic model would follow, on a surface I couldn't fully see, for data with constraints the user should never have to think about. The apps are the visible five percent. The other ninety-five is the tool design, the state model, and the flows that keep a valid answer the path of least resistance.