One tool. Seven apps. More than a thousand capabilities that discover, test, and maintain themselves. Here’s the design that makes a traditional MCP server look like a hand-drawn map.
Every AI platform conversation eventually hits the same tax: context cost. Load an agent with the usual Google Workspace coverage and you’re serving it tool schemas from Gmail, Drive, Calendar, Docs, Sheets, Slides, and Contacts. Seven servers. Dozens of tool definitions. Every one of them permanently resides in the model’s context, billed on every single turn, whether the task needs them or not. Then someone has to maintain all of it: every new endpoint Google ships, every payload shape, every OAuth connection, every optimization, by hand, per tool, forever.
We built a different way. The Google Workspace MCP server by Workato covers all seven services through one tool. Not one tool per app. One tool, plus two helpers that load once and are never needed again. Behind it sits a semantic layer of more than 1,000 known-good actions, and behind that sits an offline self-learning loop that discovers new Google capabilities on its own, learns the language real users actually speak, and promotes a capability only after it survives a canary test and an adversarial review by three AI models.
Here’s the part I keep coming back to: there is no engineering involved when Google ships a new feature. No schema update. No release. The server notices, tests, and adds it. The humans went out of the maintenance business, and the server got smarter in the process.
The context bill, today
The economics show up in the design itself.
One tool schema instead of dozens. A conventional multi-server setup pays for every tool definition on every turn of every session. Our fixed floor is one primary tool and two lightweight helpers that load once. Everything else, all thousand-plus capabilities, lives server-side in the semantic layer and is looked up at call time. The user never pays rent on capabilities they’re not using.
No LLM in the hot path. An early design had an AI interpreting every request. It was slow and it hallucinated, because AI just makes stuff up unless you force it not to. So the AI moved out of the serving path entirely. The hot path is a deterministic lookup against the semantic layer: a phrase maps to a capability, the capability executes, done. That’s why calls are fast, repeatable, and cheap, and why we sit at close to 100% for accuracy on standard reads and writes.
Workflows collapse into single calls. The server watches which capabilities get used together, mines the successful sequences, and turns them into compound capabilities. Draft an email, send it, archive the thread: one call instead of three, and one model turn instead of three. Every call you don’t make is a whole turn of context you don’t pay for.
Built to get cheaper, not just today. This is the part I’d bet on. Every response shape in the server is defined by data, in a registry, not by code or recipe. When we want a leaner default projection for a capability, returning the fields an agent needs to make its next decision and leaving the rest one hop away, that’s a config row, not an engineering ticket. We measured exactly this lever on the Gmail MCP rebuild and cut tool output by nearly 80% across full workflows. On this server, that same optimization applies to any of the 1,000+ capabilities as data. Optimization isn’t a project here. It’s a table edit.
How it stays current with zero engineers
Once a day, the server crawls Google’s public discovery catalog: the machine-readable description of every endpoint and schema Google publishes. Version changes, new endpoints, new functionality, all of it.
The consequence is the thing. When Google adds a cool new capability to Gmail, nothing happens on our side. No sprint, no schema change, no deploy. The discovery sweep sees it, the learning loop picks it up, and the promotion pipeline decides whether and how it lands. The server maintains itself.
The self-learning loop
While the hot path executes, an offline loop watches what people actually say and do. Every request lands as a learning event. Phrases that show up get grouped, and new capabilities have to earn their way in: the gate requires real evidence, seen repeatedly, before the loop even reacts. A brand-new phrase or an unproven endpoint doesn’t get promoted on a first date. It gets parked with its evidence attached, so when the endpoint matures, the demand signal is already sitting there.
That’s the difference between a static MCP server and a living one. Most servers only know what a human typed into them at build time. This one studies its own traffic.
The canary: prove it before you promote it
If you’ve worked with engineering you know the phrase. Send the canary into the coal mine and see if it comes back.
Before any phrase gets promoted into the serving path, the system executes a canary: it runs the actual calls through a sandbox service account, creating the test email, deleting the test email, building the test slide, and compares what came back against what the phrase promised. If the phrase doesn’t produce the expected end result in the sandbox, it doesn’t ship. Users never meet a capability that hasn’t already been executed end to end.
Three AI models, keeping each other honest
Here’s the secret sauce, and it started with a problem every AI team has hit: left to its own devices, a single LLM judge gets agreeable. You ask “is this good to promote?” and it says “yeah, looks fine, let it rip.” Then a bad phrase lands in your semantic path and errors out in front of a user.
So I stopped trusting one model and hired a committee.
The judge. One model, with explicit instructions to weigh the canary evidence and form an opinion.
The dissenter. A completely different model, different weights, with opposite instructions: attack that thesis. Find the flaw. Its entire job is to disagree, which keeps the first model honest, because one AI policing another is a much harder system to charm than one AI grading its own homework.
The resolver. A third role that takes both opinions plus the hard evidence from the sandbox runs and issues a verdict: promote, retire, or park for later evidence.
Promotion means the phrase met the eval gate, survived a genuine adversarial attack, and was proven in a live sandbox. That’s the bar for touching the hot path, and it’s why the accuracy number holds up.
Under the hood
All of this runs on Workato, and the architecture is exactly what you’d hope: a data layer, an MCP tool, and an offline LLM loop.
The semantic layer is a set of Workato data tables, curated by automation recipes. The semantic registry holds every endpoint with its index key, capability ID, service mapping, and activation state. A retrieval index distills all of it down to a tight lookup table with checksums and pointers, so a request resolves in a handful of rows instead of scanning thousands. Error hints teach the server to self-heal when an upstream call misbehaves. Coverage-gap miners watch for what users are asking for that the layer can’t yet do.
The serving path runs on a custom connector, not the off-the-shelf Google ones. It’s thousands of lines of Ruby and it’s on version 121, if you want a sense of how many iterations the hardening took. I took the pattern inspiration from our Enterprise Data MCP team, who built a self-improving semantic layer for data: I figured there was no reason that couldn’t apply to an application MCP, and it turns out there wasn’t.
Every call executes as the end user through Workato’s identity system (VUA). The agent does things as you, scoped to your permissions. No shared service account pretending to be everybody. Identity, execution, and governance live in one platform.
Where this goes next
The pattern isn’t a Google thing. The semantic layer doesn’t care what’s behind it, which means the same design applies to Salesforce, Workday, or any application with a describable API. Take it further and you consolidate an entire business motion: the CRM, the enrichment tool, the deck, the email, learned as one observed workflow and served as one call. Define a process as a data table, populate it with what people actually do in order, and a semantic server can carry the whole workflow.
That last part is unproven, to be clear. But there hasn’t been a thing in Workato I haven’t been able to build with some creativity and an unwillingness to let go, so I like its odds.
The traditional model of MCP servers, where humans define every tool, maintain every schema, and optimize every payload by hand, isn’t just expensive. It’s unnecessary. The server that maintains itself is here, and it’s already smarter than the day it shipped.
