How building an MCP App changed the way we understand the value of MCP

It’s been over a year now since we released our Jellyfish MCP. We’ve learned a ton, had a lot of fun keeping up with the latest technological developments, and delivered real tangible value to our customers along the way. Since the beginning of this year alone, usage (requests) has nearly tripled and the number of customers using our MCP has grown around 40% month over month.

The most important value that it brings to us, however, is how usage patterns and customer interactions with it inform our thinking about the future of our product. As more and more SaaS companies move towards a “headless” product vision, we’ve been thinking a lot about where Jellyfish fits into that world, and the MCP has provided a perfect testing ground for our hypotheses and experiments.

For a product like ours, MCP isn’t just a new piece of UI. Its promise is deeper: a flexible, conversational access point to the underlying data. A user can point an LLM at our server and interrogate their Jellyfish data in essentially any way they want, including questions we never built a view for in the web app. The data stops being trapped behind the views we happened to build. The user brings their own client, asks whatever they want, and gets it back in whatever shape is useful that day: a table, a summary, a chart, without us having to anticipate the question in advance.

So when Anthropic launched MCP Apps earlier this year, we were thrilled by the thought of being able to offer our customers a new, highly flexible way to interact with their data. We thought this might be the thing we had been waiting for, to finally bridge the gap between our MCP and the main primary product surface. We had to try it out, and we found what we thought was a perfect use case.

A customer of ours, a Jellyfish MCP power user, had been running a Monday-morning ritual on top of our MCP server for months. He’d paste a carefully refined prompt into Claude Desktop and it would pull a curated subset of his initiatives from Jellyfish, format them into a card grid, and generate a week-over-week prose summary. He’d built the workflow himself, refined it over time, and while a few of the steps were manual and a little annoying, for the most part it worked.

We thought an MCP App could be a great way to convert his improvised solution into something more polished, and in many ways it was. Just not in all the ways we wanted it to be. We spoke to him about it, identified his pain points, and set out to build him a better solution. The gap we set out to close was the lack of a persistent, refreshable, and sharable home for his workflow: he was regenerating his summary from scratch every week, with no reliable record of old data and no way to refresh without retyping his long, carefully crafted prompt. So we built him the real version: a highly configurable interactive dashboard, served from our MCP server, rendered inline in Claude Desktop.

It had a card grid of major active initiatives, FTE investment, progress bars, projected dates, week-over-week deltas, and per-card drill-downs into weekly trajectory data for each one. There were status and team filters at the top, plus a saved combination of fields, statuses, and team scope that the user could configure to their liking. Mechanically, it was five MCP tools, an HTML resource for the iframe, and local JSON persistence for configuration preferences in the user’s home directory. The whole thing ran as part of our existing MCP server, with no separate deployment, no hosted infrastructure, and no new auth flow. We used the standard patterns for MCP Apps: iframe-as-resource, companion tools backing every interactive control, and the ability to fetch additional data on demand without an additional LLM round-trip. It worked exactly as promised.

Ultimately, an MCP App doesn’t extend the flexible-data-access promise. In some ways it even cuts against it. The tool layer gives the user open-ended ways to interrogate the data. An MCP App takes a slice of that and freezes it back into a fixed, pre-built view. That’s genuinely useful, but it is still a view, with the same essential shape and constraints as any other UI we’d built.

So the offering ends up being a third category of thing, sitting alongside (1) our main web app and (2) the flexible tool layer. It doesn’t have the infinite flexibility of the tool layer, and it doesn’t have the depth of the full app. It’s its own surface, in between.

That’s not a failure mode– it’s just what an App is, and it’s worth being clear-eyed about that before you build one. For a user who already lives in our main app, a thinner version of that, embedded in chat, isn’t actually much of an upgrade. The chat container, the iframe sandbox, and the available tool surface all cap how much depth you can push through it.

The chat surface is for glanceable previews and quick actions. The full product is for deep work. The tool layer is for everything in between that we hadn’t anticipated and built a view for.

While we do still see genuine value in MCP apps, and we’re planning to release the one we have, we’re largely keeping our efforts focused for now on expanding and reinforcing the underlying infrastructure on top of which our MCP is built. This means designing better, more efficient, MCP-friendly endpoints, implementing a more flexible permissions structure for improved shareability, and better instrumentation.

What we want our MCP to offer people right now is more of the flexibility: the open-ended, interrogate-it-any-way-you-want access that drew us to the protocol in the first place. That’s the real value of MCP to us, and this project helped to clarify that.

We’ve been doing our homework and learning about some really interesting, creative solutions that others are implementing when faced with these same challenges, and we’re testing out some of them now. Stay tuned for more about how we’re approaching these challenges and what we’ve been learning along the way!