III · Tool Use & EnvironmentEmerging★

MCP Bidirectional Bridge

also known as MCP Client and Server, Two-Way MCP, MCP Bridge Framework

Run a framework as both MCP client (consuming external MCP servers as tools) and MCP server (publishing its own agents, tools, and workflows back over MCP) so capabilities flow both directions across the protocol boundary.

This pattern helps complete certain larger patterns —

  • specialisesModel Context Protocol★★— Standardise how agents discover and call tools so that a tool written once is usable by any conformant agent.

Context

An organisation operates in a heterogeneous agent ecosystem where the Model Context Protocol (MCP) has become the common contract between tools, agents, and hosts. The team is choosing or building a framework that will both use external MCP services and offer its own agents and workflows to other MCP-speaking systems.

Problem

A framework that only acts as an MCP client can consume external capabilities but cannot expose its own agents and workflows to peers, locking its value inside its own runtime. A framework that only acts as an MCP server can be called from outside but cannot integrate external MCP tools without writing per-vendor adapters. Either asymmetry forces teams to commit to one framework and rewrite integrations whenever they want to combine its agents with another system, defeating the point of having a shared protocol.

Forces

  • MCP is rapidly becoming the cross-framework tool contract; participating only on one side limits composability.
  • Exposing internal agents as MCP servers requires careful contract design — schemas, auth, lifecycle, elicitation.
  • A framework can expose at multiple granularities: a tool, an agent, a workflow, a prompt, a resource.
  • Permission and credential management is non-trivial when the framework is both client and server.
  • MCP-as-Code-API (where the agent writes code that calls MCP tools as imports) is a useful third axis.

Example

A platform team picks Mastra as its agent framework. On the client side, Mastra connects to external MCP servers — GitHub, Slack, an internal Postgres MCP — so agents can use those tools. On the server side, Mastra publishes the team's internal agents and workflows over MCP so the company's other tools (a Pydantic-AI service, a Dify dashboard, Claude Desktop, an n8n workflow) can call them directly without an HTTP wrapper. When the team later evaluates Pydantic-AI for one new product line, the integration is a configuration change rather than a rewrite — both frameworks already speak MCP both ways.

Diagram

Solution

Therefore:

Build the framework with two symmetric MCP modules: a client module that lets agents call external MCP servers as tools (with auth, schema validation, and elicitation handling), and a server module that publishes internal artefacts — typically agents, tools, workflows, prompts, and resources — over MCP for external consumers. Treat the two as one architectural decision, not two: the same registry should describe both what the framework consumes and what it offers. Pair with mcp (the underlying protocol), mcp-as-code-api (code-as-import variant), and tool-agent-registry. The bridge is also a useful anti-lock-in stance — see vendor-lock-in.

What this pattern forbids. External capabilities must arrive through the MCP client surface and internal artefacts must be published through the MCP server surface; the framework's value is not allowed to be locked behind a non-MCP boundary that peers cannot cross.

And the patterns that stand alongside it, or against it —

  • complementsMCP-as-Code-API★— Materialize MCP servers as a directory of typed code wrappers so the agent writes code that imports them and large tool outputs flow between calls inside the sandbox without ever entering the model's context window.
  • complementsTool/Agent Registry★— Maintain a single queryable catalogue of both available tools and available agents, with metadata (capability, cost, latency, quality) the agent can use to pick the right one for a task.
  • alternative-toVendor Lock-In✕— Anti-pattern: couple application code directly to one model provider's SDK, request shape, and proprietary features so that switching providers requires rewriting application code rather than swapping an adapter.
  • complementsPerformative Message★★— Inter-agent messages are typed by communicative intent (request, inform, propose, accept, refuse, query) rather than by free-form prose, so receivers can dispatch on act type.
  • complementsHierarchical Tool Selection★— Organise tools into a tree of categories so the agent first picks a branch and then a specific tool within it.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

References

Provenance