Building an MCP server is easy. Building one that gives an AI agent the right information without burying it in raw API output is much harder. Large raw outputs mean more output tokens which means more cost.
Our first Gmail server worked. That was not the problem. The problem was that it often returned far more than the task required. Workato gave us a way to measure the waste, trace it back to the workflow that caused it, fix the implementation quickly, and prove that the change held up in real use. This is where AIRO MCP by Workato was the difference maker.
The result: less output, more useful work
The rebuilt Gmail by Workato MCP takes up less space in the model’s context, asks less of the agent, and does more than the version it replaced. In a world where every token is billable, less output equals less cost.
- 79.8% less tool output than the native Gmail connector across six complete workflows.
- 79.3% less total data exchanged with the model.
- 60 of 60 workflow executions completed successfully.
- We ran 32 functional and adversarial checks. Every one passed, and all 29 tools routed correctly.
We did not get there by hiding useful information. We got there by returning what the agent actually needed and leaving out raw email structure, duplicate history, and payload it would never use.
Measure the workflow, not just the tool call
A small response is not actually efficient if it forces ten follow-up calls. So we compared complete tasks, not just individual tool calls.
The benchmark covered three versions of the same Gmail experience:
- The legacy Gmail by Workato MCP and its normal multi-tool paths.
- The rebuilt V2 server with task-shaped, bounded responses.
- The native Gmail connector available to the same AI client.
We used the same authenticated mailbox and the same test messages wherever both systems supported the task. Single-call tests used ten measured runs after warm-up. Each of the six multi-step scenarios used five measured runs after one warm-up. Every dependent call counted because the cost of a workflow is the cost of finishing the job, not the cost of the first response.
Workato made the development loop faster
Workato was not simply the runtime. It was where we inspected behavior, reshaped responses, tested changes, controlled releases, and watched how the server was used in production.
We used three tools inside that loop:
- Codex: designed the tests, ran the comparisons, analyzed responses, and coordinated each iteration.
- AIRO MCP: connected the analysis directly to Workato job evidence, recipes, MCP skills, schemas, and server configuration. It let us inspect the evidence and update the underlying Workato assets from the same development session.
- Browser automation: covered the smaller set of UI-only steps, including final catalog and deployment validation.
The number of tools is not the interesting part. Workato kept the whole cycle connected. We could move from evidence to a recipe change, then to testing, release, and observability without losing the thread.
What we changed
Search that helps the agent decide
The rebuilt search tool can return a minimal list, a compact result, or a triage view with enough context to decide what to read next. That small amount of useful context keeps the agent from having to open every result.
Readable threads without the extra weight
The new read path returns readable text, reply context, labels, and attachment details without dragging along raw email encoding or repeated quoted history. The agent can ask for the newest message or a bounded part of the thread, so deep threads stay useful instead of becoming progressively more expensive.
Replies and attachments that finish the job
Workato resolves the reply thread from the source message, adds the caller’s Gmail signature when requested, and checks addresses and headers before Gmail is called. It also returns attachment details and lets the user download those files. Correctly threaded replies, native signatures, and attachment downloads give our server functionality the native connector in this comparison did not offer.
The savings held up in real workflows
Across six real-world tasks, Gmail by Workato MCP produced 17,320 estimated output tokens. The native Gmail connector produced 85,546. Every measured workflow completed successfully.
The savings held across very different jobs, including inbox triage, exact-subject review, multi-thread reading, metadata lookup, attachment retrieval, and draft review. Individual reductions ranged from 4.1% to 96.3%. Across all six workflows, Workato used 79.8% less output.
The largest gains appeared when the task involved multiple messages or attachments. In one three-conversation review, the native connector returned 24,185 estimated output tokens; Workato returned 3,041. For a PDF attachment workflow, the comparison was 38,081 versus 2,408.
This matters in actual use. The agent receives far less material and avoids unnecessary recovery calls. Our next development cycle will be focused on reducing the remaining latency without giving back those gains.
From development to production without breaking users
We kept the existing MCP endpoint intact. New tools became the preferred routes, while legacy tools remained available for existing automations.
Workato records which tools are called, who called them, the environment, and how long each job takes. Collection happens outside the response path, so monitoring adds no user-facing latency.
Requests run as the authenticated Gmail user, with Gmail permissions as the security boundary. Identity, execution, deployment, and telemetry stay in one governed Workato platform.
Why Workato made the difference
Most conversations about MCP efficiency start with the prompt. Ours did not. We started with the system producing the tool response.
Each MCP tool is backed by a Workato recipe, so we could shape the response before it reached the model. We validated the request, called Gmail, parsed the result, applied limits, removed duplication, and returned a predictable response. AIRO let us inspect and edit those assets directly, which turned problems into fixes very quickly.
Workato also made the improvement practical to operate. We tested under load, preserved backward compatibility, promoted only changed assets, and watched adoption after release. The same platform supported the build, rollout, and proof.
What comes next
V2 is in production. We are developing V3 alongside it with a custom Gmail connector that moves batching and parallel enrichment closer to the Gmail API.
The user-facing tools can remain stable while the implementation gets faster. That is what it means to treat an MCP server as a product, not a thin API wrapper.
An API wrapper exposes Gmail to a model. Workato makes Gmail useful. That is what we built.