Workato · 2025
Enterprise MCP servers
Building an MCP server was an engineering task. We made it something a business team could do — and that IT could still govern.
The people who understand a business problem are rarely the people who can ship a secure MCP server. Every custom server needed engineering time, which capped experimentation and left the useful automations unbuilt.
Existing MCP catalogs offered pre-built servers from common providers, but none let a team encode its own business logic. Workato already had the raw material — recipes, connections, an identity layer. The opportunity was composition: let people assemble a server out of assets they already trusted.
Published server
becomes discoverable
The two paths we designed against.
We shipped a card catalog, watched what people did with it, and replaced it with a list
Cards were the familiar format — every MCP catalog uses them, and we explored a lot of variations before shipping. Then usage showed the real problem: people couldn't tell whether a server they needed already existed, so they made another one. Workspaces filled with near-duplicates.
A catalog layout suits a fixed set of vendor-published items. This content was user-defined and metadata-heavy, which the grid couldn't carry — hard to scan, barely sortable, and it forced a weak call to action. We moved to a list.
"AI Hub" tested as a name nobody wanted to click
MCP servers started buried inside the API platform, reachable only by users already provisioned for it. Almost nobody found them. We pulled every AI capability into one top-level section and called it AI Hub.
Customers told us the label was ambiguous and they hesitated to click it — a vague container is its own kind of hidden. We reworked the navigation to name the capability directly.
Default to identity, not shared tokens
Tokens are the path of least resistance for an MCP server and the fastest way to lose control of one — they get passed around, over-scoped, and never expire on schedule. We made every new server default to Workato Identity when the workspace had it enabled, so builders grant access by user group instead.
Verified user access followed: end users sign in to each application the server touches, so a server can never hold more permission than the person prompting it.
Our PM and I broke the north star into milestones small enough to verify and big enough to matter. We let requirements stay fluid across them so engineering could plan — we weren't going to solve it all at once, but we could keep it moving with the people we had.
Ship the smallest thing that proves an MCP server can come out of Workato
We built on the existing API platform: a toggle that turned an API collection — already assembled from endpoint recipes — into an MCP server, plus the URL an end user needs to install it in Claude or another client. No new object model, no new infrastructure.
It also told us what was wrong. Only users provisioned for the API platform could reach it, so almost nobody discovered it. MCP servers had to move into the core platform, not sit as a setting inside one product.
Most catalogs offer both local and remote install. Following Anthropic's lead on where clients actually run, we shipped remote URLs only and cut the local instructions — one less branch in the install flow to explain.
Give MCP servers a home, a landing page and a way in
We pulled every AI capability into one top-level section, built the MCP landing state inside it, and assembled the creation flow from the design system's existing wizard components — fastest path to something customers could use and react to.
MCP is not a native Workato concept, so I borrowed from MCP server patterns customers had already seen elsewhere rather than inventing a Workato-specific mental model. The naming didn't survive contact with customers — see decision 02 — but the placement did.
Two questions IT asks before approving anything: who can use it, and what can it reach
A Settings section let builders switch a server's authentication method, and I worked with the PM to prioritize real controls over both halves of the problem — which people get access, and which application permissions they carry once they have it.
Verified user access came out of this milestone: the end user signs in to every app the server connects to. Getting it right meant sitting with product and engineering until I understood how those sign-in handoffs actually behave, failure states included. The defaulting decision is decision 03.
One page where you assemble a server out of things you already own
The wizard came out and a single-page workflow went in: pick tools from the assets already sitting in your Workato workspace. This was the milestone that delivered the actual promise — teams encoding their own business logic so an agent behaves predictably every time, instead of installing someone else's generic server.
A templates panel came later, for people who wanted to see how a server works before they had their own resources ready. The hard part was tone: inviting enough that a non-technical builder starts, precise enough that they understand what they just published.
Interaction design for the composable flow. A short screen recording works better here than a still.
Tool descriptions turned out to be a performance feature
The model relies on a tool's description to decide whether to call it. That reframed a text field as something worth designing for: we allowed long descriptions to stay visible in the list view and invested in rich text editing so builders could structure them for accuracy.
The detail page was rebuilt around that — room for varied tool metadata, expanded instructions, and inline affordances to add a tool or edit a description without leaving the page. I explored several table layouts for Skills, and worked with the Digital Design team on generated avatars so every row stopped falling back to the same MCP icon.
Give builders a way to see what their servers are doing
An analytics dashboard shipped as a limited preview to selected accounts, and we kept iterating on it while the preview ran and live feedback came in. It's also what made the launch numbers observable at all — including the failure rate we didn't like.
A 34% tool failure rate was the number I cared about most, and the feedback form told us why it hurt: people couldn't see what was going wrong.
We answered with traceability, audit logs and inline education, and moved fast on them — these were table stakes for enterprise teams, not enhancements. Tool descriptions turned out to matter more than expected: the model needs them to pick the right tool, so we allowed long descriptions in the list and invested in rich text editing to help builders structure them well.