This article by Adam Jones and Tadas Antanavicius, originally published on Pulse and republished with the authors’ permission, explains practical patterns for connecting many MCP servers and exposing them across multiple clients. The authors argue that while single-server, single-client demos are common, the real power of MCP comes from composing servers and making those integrations available across the clients people actually use.
Why multiple servers matter
A single Gmail MCP server can triage mail and draft replies, but Gmail already provides that interface. Greater value appears when that Gmail server interacts with other services. For example, an IKEA order confirmation with a receipt attached can be found by Claude Code, the attachment extracted, a one-time code retrieved from Gmail to log into Benepass (a benefits provider), the receipt uploaded there and the submission completed. No single app could handle that cross-application flow alone.
Multiple clients: exposing the same servers everywhere
It’s valuable to connect the same set of servers to multiple client interfaces: Claude Code, Claude.ai, Gmail, Linear, Slack, and so on. Typical scenarios include asking an inline Slack question like "@ai does our discussion here align well with current company strategy?" and receiving an answer that incorporates Notion OKRs and recent Zoom transcripts, or commenting on a Linear ticket "@ai schedule a meeting with John and draft an agenda based on the meeting I just had with Pam to address this." The article notes that native MCP client functionality is coming to many surfaces and that non-native integrations such as Claude Tag already help fill that need.
Importantly, you can provision many of these capabilities today by bridging the desired surface to an agent harness behind the scenes. A small amount of glue can inject a fully capable agentic harness and MCP client behind a webhook or polling process; native support is not strictly necessary.
Go remote ASAP; local servers are for prototyping
Local server installation is a major friction point for end users. Commands like “install npm, edit this JSON, set these env vars” don’t scale. Remote servers are easier to share—"here's a URL to paste"—and some surfaces (for example, claude.ai) only accept remote servers.
Pattern: wrap local servers with an OAuth front and per-user credentials behind. Tools like mcp-auth-wrapper convert a local implementation into a remote, multitenant server: OAuth in front and per-user credentials behind, so sharing a server becomes sharing a link instead of a setup guide.
Reduce configuration friction
Once you have one link per server, the question is where users paste that link. Provide per-client installation guidance. Services like install-mcp provide a clean UX that generates the right install link and per-client instructions so you can share a single page instead of writing a tutorial. If you want this inside your own product, use the mcp-install-instructions TypeScript library.
The authors are working to standardize the mcp.json file format to simplify this story long term, but they still expect non-CLI interfaces to have slightly different "enable connector" flows. For many enterprises, enabling connectors may become an IT responsibility with enterprise-managed auth.
Don’t make users repeat auths: use an aggregator
By default every user must authenticate each MCP server in every client, leading to many repeated OAuth flows. The solution is to centralize configuration and auth storage in an aggregated MCP server. A deployment of mcp-aggregator gives you a single endpoint and login, with every tool namespaced behind it. Configure each client once, log in per service once, and share one link with teammates. The article contrasts configuring 7 clients × 6 servers (42 connections) versus an aggregator approach that reduces the work (7 + 6 = 13 configurations: configure each side once).
mcp-aggregator is presented as a minimal DIY MCP gateway. If you need enterprise features like SSO or fine-grained IT controls, add them at this consolidation layer. Note: an aggregator by default may not preserve per-session constraint behavior, but you can re-enable constraints via query parameters (for example ?readOnlyTools=true or ?serversEnabled=datadog,sentry) or by exposing discrete MCP-server endpoints while aggregating auth.
Workarounds for missing MCP servers: give the agent a screen
Not every service has a ready MCP server. Example: Octopus Energy emails a confirmation and you want pricing data in Home Assistant, but the API key is only retrievable via a website login and there’s no API to fetch the key. The workaround is to let the agent operate the website.
computer-use-mcp is a minimal MCP server that can click and type like a human (Playwright-style) to log into a site, copy the key, and then use clean API calls to set up dashboards. With this escape hatch, "no API for that" or "too much work to find/build an MCP server" stops being a permanent blocker.
The authors summarize Anthropic’s framing: if you have an MCP server for the service, Claude uses that; if the task is a shell command, Claude uses Bash; if the task is browser work and Claude in Chrome is set up, Claude uses that; otherwise Claude uses computer use.
If you repeatedly rely on browser or computer use for predictable workflows, it’s worth abstracting those Playwright calls into a reliable MCP server (the Good Eggs example is cited as such a case).
Make local-only servers available remotely
Some servers must run on your personal machine. computer-use is an obvious example. mcp-local-tunnel demonstrates how to make machine-bound servers reachable through remote aggregation: a tunnel makes machine-bound servers look like ordinary remote endpoints.
Beware context bloat
Tool-calling naively can burden the model with unnecessary context: intermediate results and full tool definitions often get placed in the model context up front, consuming many tokens before the task starts. An example given: copying a Google Drive doc into Salesforce caused the entire doc to pass through the model twice for no reason. Anthropic measured a workflow that fell from 150,000 tokens to 2,000 tokens after addressing this.
Mitigations include:
- Code execution layer via MCP: tool-sandbox-mcp demonstrates an execute_code abstraction that inserts a code-execution layer between the agent and aggregated servers, reducing context bloat and working inside any MCP client.
- MCP as a CLI tool: call-mcp shows how wrapping tools this way allows composition with the usual CLI toolkit (shell, jq, cron, scripts).
- Search tools and truncating large responses: Claude Code does this natively; it can also be implemented as a bridge.
Each approach has trade-offs worth deeper discussion.
Putting patterns together: solve the M×N problem
With an MCP aggregator and a bit of glue code you can connect any service to any other service. While native MCP client implementations will eventually simplify this, the authors show practical application-by-application approaches today.
Example: embedding an MCP client harness inside a SaaS app (Linear) Using the earlier mcp-aggregator pattern, you can inject a Claude Code-powered MCP client into Linear. The harness can monitor Linear activity (for example, ticket comments), have whatever skills or MCP connections you want, and respond in Linear via a Linear MCP server or via the aggregator. The same pattern can be applied to other trackers (Jira, Asana) or to surprising surfaces: the authors show a few-hundred-line Claude Code agent inside Minecraft that can edit its own PR, check upcoming energy prices and set a calendar event, or build an in-game notice board.
Conclusion
The article presents a practical progression from single-server demos to multi-server, multi-client compositions: prefer remote multitenant servers, wrap local implementations with OAuth, provide per-client installation UX, centralize auth in an aggregator, use computer/browser automation as escape hatches, tunnel local-only servers for remote access, and mitigate context bloat with code-execution sandboxes or CLI wrappers. These patterns are attainable today for individuals, teams, and enterprises.
Authors: Adam Jones and Tadas Antanavicius. Original publication: Pulse blog (republished with permission).
