MCP tools enter their UI era

By late 2025, Workato had already made recipes and skills available as tools inside Claude, ChatGPT, Cursor, and other MCP clients. But most tasks still ended in text, even when users needed to compare records, review rich content, or make several decisions.

I believed interactive interfaces were the next step. The protocol was taking shape, users were moving more work into AI clients, and Workato already had the automation foundation to act quickly.

I was instrumental in advancing the initiative outside the formal roadmap. I changed our original no-code direction based on observed evidence and stayed hands-on through design, prototyping, technical decisions, beta, and GA.

MCP Apps were new, but the interaction model it opened up was quite familiar to me.

In 2017, I had designed the first Workbot for Slack experience concept and presented it to Stephen Franchetti, Slack's CIO at the time.

The idea was to make Slack more than a destination for notifications. A sales rep could inspect an opportunity and update Salesforce. A manager could review and approve a request. A support team could retrieve a ticket and trigger the next step.

Workato recipes handled the automation while Slack provided the work surface. The principle was simple:

Slack's interface options were limited before Block Kit, so Workato built on what was available.

When Slack launched Block Kit, it gave this pattern a stronger foundation. Workbot gained native forms, date pickers, dynamic menus, multi-step modals, and App Home experiences. Workato made them available through recipes without requiring builders to write Slack JSON. Builders could compose structured messages with fields, images, buttons, and menus. A button could pass business data into another recipe, update Salesforce, and then update the original message to reflect the action.

We also combined messages, images, buttons, and stored context to simulate richer views and pagination. More than 1,700 companies were using Workbot within months of launch, and it later became part of daily work across thousands of businesses.

MCP servers made Workato recipes callable from AI clients, but most interactions still ended in text or structured data.

SEP-1865 created an opening to add interactive interfaces. I had already seen with Slack how quickly product experience expectations changed when richer interactions became native to a conversational platform.

However, there was one important difference. Block Kit was a fixed component system tied to Slack. MCP Apps provided a full HTML surface across compatible AI clients. Recreating a fixed component library would have limited builders to what Workato chose to support. A code-first approach could let the interface fit the task.

A text response could identify a few accounts, but the rep would need more prompts to compare them and another system to take action. An MCP App could show every account in a sortable table, combine CRM data with recent activity, filter the results, open a record, and create a follow-up task through another Workato tool.

Workbot had already shown that people wanted to complete work inside a conversational surface. Claude and ChatGPT were becoming new work surfaces, and SEP-1865 offered a shared standard across MCP clients. This was the right time to learn while client behavior, SDK patterns, and authoring conventions were still taking shape.

I took the idea to our CPO shortly after the proposal appeared. Engineering built a proof of concept that launched an interface from a Workato tool inside an AI conversation.

The proof worked, but quarterly priorities left no room on the formal roadmap. Waiting a quarter would reduce our time to learn with customers.

Konstantin Zhandov, my engineering partner, proposed a small team around the existing MCP server work. I helped form it and became the de facto PM, design lead, and first builder.

We called ourselves Ship Happens Club. We set out to answer three questions:

My first instinct was to make MCP Apps drag-and-drop. Workato is a no-code platform, so I pushed to connect them to our existing Pages feature which supports drag-and-drop UI building. We also explored launching with only predefined views like forms, tables, and dashboards.

Then engineering built a code-first proof of concept. After playing with it, I realized it was more capable than either option.

We stopped pursuing Pages and removed a proposed dashboard template from scope. Claude and ChatGPT are already being heavily used to generate HTML, CSS, and JavaScript from a prompt. AI makes that flexibility accessible without requiring Workato to build every component first.

So our job became giving builders and AI the right context, then applying Workato's governance to the generated code.

The model interprets the request and selects the linked tool. That tool launches the app. Once loaded, the app manages the interface and can call other tools on the same MCP server. Workato recipes handle governed operations across business systems.

The launch tool can return a small acknowledgment while the app retrieves data through another tool. The model doesn't need to process every record for the user to see it, which reduces token use and model latency.

Once the code-first proof was ready, I asked Guanyi Fu to design the builder experience. His first pass didn't answer the main authoring question: how would data move between tools and the interface?

A builder needed to understand how a recipe's output became interface data, how a user's selection became an input, and how that input reached another tool.

I asked Guanyi to stop iterating on screens and build an MCP App himself. He used an office-booking app as a reference and worked through the full flow.

While building, he repeatedly needed to check which tools were available, their exact names, their required inputs, and the data they returned. That friction led us to place tool schemas beside the code editor.

Builders could inspect any tool's inputs and outputs without leaving the page. They could see what one system returned, choose which fields to display, and map a user action to the next tool.

Builders didn't need to understand the full protocol. The product needed to surface the details that determined whether an app worked.

The schema panel helped the builder understand the server. AI needed the same context.

I built a rough action that assembled the server description, tool names, descriptions, schemas, existing code, and SDK instructions into a starting prompt. Bochuan Li developed it into the "Code with AI" experience, with options to open the prompt in Claude or ChatGPT.

The panel gives builders a reference while editing, and the prompt gives AI the context to generate valid code.

Building real apps exposed issues that static design reviews missed.

Some tools create or change data, so the AI client asks the user for approval before running them. In our tests, that approval request could appear before the app displayed the form the user needed to review or complete. We added instructions telling the model to wait until the user clicked a button, but clients didn't follow them consistently. This led us to clarify when one tool should open the app and another should perform the action.

AI-generated code could add a new CDN, font, image host, or video in seconds. Automatically allowing each domain would let generated code expand the app's security boundary without consent. Requiring people to explicitly add each domain created errors and friction. To solve this, we chose to auto-detect and add new domains, but warn the builder before saving.

Renaming an app linked to a tool could break export and import to a higher environment because the relationship was resolved by name. I chose to let the import complete, even if it meant having unused apps in the target environment. A stray asset could be removed later. A failed deployment was more disruptive.

We needed to know whether code-first worked outside design and engineering.

I gave Daman, an embedded CSM, access to my preview workspace. He used Claude to generate interface code, AIRO to build deterministic recipes, and MCP to connect them. He produced a travel-planning app and a branded experience modeled on eBay listings.

His work showed that someone outside design and engineering could build a useful app, and that field teams could turn a customer scenario into a working experience without waiting for the product team. The eBay-style app became the video in the GA announcement.

I connected the emerging specification to an interaction model I had helped establish with Workbot. I took the idea to the CPO, helped form the team when the work fell outside the roadmap, and filled the product leadership gap.

I set the initial direction, then changed it when the proof of concept challenged my no-code assumption. I asked designers to build before designing, built working apps myself, and coded the first version of "Code with AI." I also made product calls with engineering on tool binding, render order, security defaults, naming, and lifecycle behavior.

Guanyi led the core design and identified the need to keep tool schemas beside the code. Bochuan turned my prototype into the final "Code with AI" experience. Serene surfaced the sequencing issue that shaped our documentation. Oleg, Denis, Andrey, and Anton built the underlying capability. Daman validated it with field teams.

My role was to keep product direction, design, implementation, and adoption connected.