How Asana built its ChatGPT app and Claude connector with MCPJam

Asana recently shipped a ChatGPT app and a Claude connector on a short timeline. The work required more than getting tool calls to succeed. Engineers needed to test specific inputs, inspect the rendered UI, and check mobile layouts without waiting for another deploy.

This case study is about the development workflow they used for that work. MCPJam let the team run tool calls with known arguments, inspect the resulting UI, and turn repeated scenarios into eval suites.

What other solutions did you consider, and how did you come to use MCPJam?

"The native MCP inspector, I guess. MCP inspector didn't have the ability to render UI, so the choice was pretty clear."

Jau Chan

Engineer at Asana

What made iteration slow

On this project, a UI change could require another deploy, another environment connection, and another pass through the end-to-end flow before the team could see the rendered result.

Michael Chu described the immediate problem as waiting on work that was incidental to the UI change itself: a deploy, then an LLM response, before he could inspect one tool call and the UI it produced.

Mobile added another check to each change. The team needed a way to preview how the UI behaved in a mobile-like environment without rerunning the full flow every time.

What MCPJam changed on this project

The immediate change was that engineers could inspect UI changes sooner.

"No longer have to do a 2 minute deploy for every UI change, or wait for an LLM response."

Michael Chu

Engineer at Asana

It also changed how the work could be split across engineers. One track could work on end-to-end ChatGPT connectivity while another worked on the UI instead of waiting for staging to connect.

MCPJam allowed us to start working on the UI in parallel with trying to get the end-to-end flow set up and working with ChatGPT.

In this project, connecting staging to ChatGPT itself took at least a couple of days, which made that parallelism especially valuable.

Testing one tool call with fixed inputs

The testing problem here was not just whether a tool returned JSON. Engineers often needed to run one tool call with fixed arguments and inspect the UI that appeared after that call.

Jau described this with flows like searching tasks, where the same inputs need to produce the same UI so the result can be inspected.

One big thing for me was being able to test tool calls with predictable inputs and getting the UI as output.

The native MCP inspector could show the tool call, but it could not show the rendered UI.

That meant the team could inspect the payload without checking the rendered result the user would actually see.

Timeline from prototype to production

Once the project was staffed, the schedule was short.

• The idea was seeded in early to mid October.
• Prototyping ran until late October, led by Prathmesh Patel.
• The project was officially funded and started in early November.
• A production-ready version was achieved by December 15.

The schedule moved quickly because UI work and ChatGPT connectivity could proceed in parallel, and because UI changes no longer required another deploy for every check.

After launch: evals, OAuth debugging, and regression checks

Shipping the first version did not remove the same debugging and regression problems. OAuth can fail at different steps. Metadata can be slightly wrong. Argument shapes can change as the app changes.

The Asana team pointed to three concrete tasks they kept using MCPJam for.

• Running eval suites more easily so interactive behavior can be rechecked over time.
• Debugging OAuth flows by seeing which step breaks and retrieving client IDs or refresh tokens after the fact.
• Catching tiny mistakes sooner instead of paying for another full deploy-and-test cycle.

Jau mentioned eval suites directly and pointed to Brandon Ramos for deeper detail on that work.

Useful for debugging OAuth flows, seeing which step breaks, if any, and retrieving client IDs and refresh tokens after-the-fact.

A much shorter iteration and feedback loop compared to deploying and testing on ChatGPT or Claude, only to realize one metadata field was incorrect.

Across these examples, the team needed to see the exact step that failed, rerun the same scenario with controlled inputs, and turn recurring cases into checks they could rerun later.

Why Asana is building these integrations

The business goal for these integrations was product discovery and new user adoption.

Jau described the goal as helping people discover Asana, understand what it offers, and try it through agentic applications. The work also extends beyond a single surface. Asana's Claude connector and ChatGPT app are already live, and the team continues building Asana into Claude and other MCP app experiences.