Skip to main content
Bridge comes up in the same conversations as MCP and A2A because all three sit near the agent stack. They are related, but they do different jobs — and Bridge now spans more of that stack than it did before. Bridge is both a context layer and an MCP server generator. MCP is the tool-and-resource protocol. A2A is the agent-to-agent coordination layer.
This page is the conceptual map. For the current Bridge CLI surface, see Commands, Configuration, and Providers. For the MCP generation and hosting workflow, see Generate an MCP server and Serve an MCP server.

​
Three different jobs in the stack

The easiest way to think about the three layers is to ask what problem each one solves.
LayerCore questionTypical surface
MCPHow does an app or host talk to tools, resources, and prompts?Client-server protocol
A2AHow does one agent discover and collaborate with another agent?Agent-to-agent protocol
BridgeHow does an agent read durable context from storage, and how does it expose that context to MCP-native hosts?Local-first CLI, provider model, and MCP server generation
These layers can overlap in a real system, but they are not interchangeable.

​
Where Bridge fits

Bridge started as a local-first CLI that normalized access to storage backends through one stable interface. That is still the core. What has changed is that Bridge now also generates and hosts MCP servers. That means Bridge can live at two different points in the stack depending on what you need: As a context reader: your agent calls Bridge directly to read files, tables, and rows using a stable JSON interface. As an MCP server: Bridge generates an MCP manifest from your API or database and serves it over stdio or HTTP, so any MCP-aware host can talk to your data without custom integration code. Today, Bridge gives you:
  • one config file: bridge.yaml
  • one command model: ls, read, status
  • one output format: structured JSON
  • one provider abstraction over your storage backends
  • MCP manifest generation from OpenAPI specs, Postgres schemas, and SQLite schemas
  • MCP hosting over stdio (for Claude Desktop and Cursor) and HTTP (for remote clients)

​
Where MCP fits

MCP is useful when you want a standardized protocol between a client or host and the tools, resources, and prompts that it can use. In practical terms, MCP is good at things like:
  • exposing tools to an MCP-aware host
  • exposing resources and prompts through a common protocol
  • negotiating capabilities between an MCP client and server

​
Bridge and MCP

Previously, the cleanest way to describe the relationship was: Bridge sits behind an MCP server. That remains a valid pattern. But Bridge now also generates and hosts MCP servers directly, which changes the picture. Use Bridge’s context commands (ls, read) when your agent reads context directly without an MCP host in the middle. Use bridge generate mcp and bridge mcp serve when your host is MCP-native and you want to expose an API or database to it without writing custom server code. These two modes are not mutually exclusive. A project can use bridge read directly in some parts of its pipeline and bridge mcp serve for MCP-native hosts in others.

​
Where A2A fits

A2A is useful when one agent needs to discover, contact, and collaborate with another agent. In practical terms, A2A is good at things like:
  • agent discovery
  • capability negotiation
  • long-running task collaboration
  • communication between agents without exposing their internal memory or tool implementation

​
Bridge vs A2A

Use Bridge when your main problem is durable context:
  • multiple agents need a stable way to read the same underlying project or backend context
  • you want storage access to look the same across backends
  • you want a context surface that is separate from a specific agent framework
Use A2A when your main problem is coordination:
  • one agent needs to delegate work to another
  • agents need a common language for collaboration
  • you care about agent discovery, task lifecycle, or modality negotiation

​
How they work together

A2A helps agents talk to each other. Bridge helps them refer to the same context. A simple mental model is:
  • A2A answers: “Which agent should do this work, and how do they collaborate?”
  • Bridge answers: “What shared context can those agents read while doing it?”

​
The stack Bridge is aiming for

The website and strategy materials describe a broader Bridge direction than the current CLI alone. Today:
  • Bridge CLI is local-first
  • Bridge reads context from your own storage and can expose it through MCP
  • Bridge does not yet provide a hosted cross-organization context layer
Over time:
  • Bridge Cloud is intended to add permissioned sharing, discovery, and access control
  • that is where Bridge starts to look more like a shared context layer across teams and organizations
That distinction matters because the conceptual vision is broader than the currently shipped CLI.
If you read Bridge as “the missing layer in the AI protocol stack,” the practical meaning today is: Bridge fills the storage-normalization gap locally and bridges it to MCP so any host can consume your data. The broader cross-org context layer is the direction Bridge Cloud is meant to extend.

​
A useful mental model

If you want a shorthand:
  • MCP gives your host a standard way to reach tools and resources
  • A2A gives agents a standard way to reach other agents
  • Bridge gives agents a standard way to reach context across storage — and can now also serve that context as an MCP server
That is why Bridge can live alongside both protocols without competing directly with either one.

​
Example architectures

​
Bridge as a direct context reader

You have an agent or pipeline that reads context without going through an MCP host. 
Agent -> bridge read -> your storage backends
Bridge returns structured JSON. No MCP involved. This is the simplest Bridge setup.

​
Bridge as the MCP server

You have an MCP-aware host and want to expose an API or database to it without writing a custom MCP server. 
Host (Claude Desktop / Cursor) -> bridge mcp serve -> API, Postgres, or SQLite
Bridge generates the manifest from your OpenAPI spec or database schema, then serves it. The host sees a standard MCP server. Bridge handles the protocol translation and data access.

​
A2A plus Bridge

One agent delegates work to another, and both need a common view of relevant context. 
Agent A -> A2A -> Agent B
Agent A -> bridge -> shared backend
Agent B -> bridge -> shared backend
Today that shared backend is still your own storage. In the longer-term Bridge vision, Bridge Cloud is where permissioned shared context across teams and organizations would fit.

​
What Bridge is not

Bridge is not:
  • a replacement for MCP’s full tool and resource protocol — Bridge generates and hosts a subset of MCP today (read-only tools from GET operations and SQL SELECTs)
  • a replacement for A2A if you need agent discovery and inter-agent collaboration
  • a full hosted security or policy platform today
  • a complete shared-session system today in the CLI alone
That clarity is important because Bridge becomes easier to understand once it is framed as a distinct layer instead of a universal protocol replacement.

​
When to reach for each layer

  • Reach for Bridge’s context commands when you want one stable interface across storage backends.
  • Reach for bridge generate mcp and bridge mcp serve when you need to expose a backend to an MCP-native host.
  • Reach for a separate MCP server implementation when you need capabilities Bridge does not generate yet — POST/PUT/DELETE tools, custom resources, or complex prompt templates.
  • Reach for A2A when agents need to discover each other and collaborate on tasks.
  • Use them together when you need both communication and durable context in the same system.

Introduction

Start with the high-level story of Bridge as a local-first context layer for agents.

Generate an MCP server

Generate a manifest from an OpenAPI spec, Postgres, or SQLite.

Serve an MCP server

Run a manifest over stdio or HTTP and wire it into Claude Desktop or Cursor.

Commands

See the concrete CLI surface that Bridge ships today.

Providers

See what each provider exposes and how it behaves at runtime.