Skip to main content
bridge generate mcp reads your existing API spec or database schema and writes a bridge.mcp/v1 manifest — a YAML file that describes the MCP server name, its data source, and every tool it exposes. You never write the manifest by hand. Once it exists, you pass it to bridge mcp serve or bridge mcp serve-http to run the server.
Bridge supports two generation sources today: OpenAPI 3.0 specs and database connections (Postgres and SQLite). Both produce the same manifest format and serve with the same commands.

​
Before you begin

  • Bridge installed and on your PATH (Installation)
  • For the OpenAPI path: an OpenAPI 3.0 spec file (JSON or YAML)
  • For the database path: a Postgres or SQLite provider already connected in bridge.yaml (Quickstart)

​
From an OpenAPI spec

bridge generate mcp \
  --from openapi ./openapi.yaml \
  --name my-api \
  --base-url-env API_BASE_URL \
  --bearer-env API_TOKEN \
  --out my-api.mcp.yaml
Bridge parses the spec, extracts every GET operation it can map to an MCP tool, and writes the manifest to --out. Only GET operations are supported in the current release. Operations that cannot be mapped are reported in the skipped field of the output — they do not cause the command to fail.

​
Base URL

Every OpenAPI-backed manifest needs a base URL for the runtime to prepend to every tool’s path. Bridge resolves it in this order:
  1. The environment variable named in --base-url-env, read at serve time
  2. A concrete servers URL in the spec itself
If neither is available, generation fails with an error telling you which one to add. If your spec already has a concrete servers entry, you can omit --base-url-env: 
bridge generate mcp \
  --from openapi ./openapi.yaml \
  --name my-api \
  --out my-api.mcp.yaml
If the base URL needs to vary by environment (staging vs production), use --base-url-env so the manifest stays environment-agnostic and the real URL comes from the process environment at serve time.

​
Bearer auth

If the API requires a bearer token, pass the name of the environment variable that will hold it: 
bridge generate mcp \
  --from openapi ./openapi.yaml \
  --name my-api \
  --base-url-env API_BASE_URL \
  --bearer-env API_TOKEN \
  --out my-api.mcp.yaml
Bridge stores the variable name in the manifest, not the token itself. The token is read from the environment when the server starts.

​
From a Postgres or SQLite database

Bridge can generate from any connected Postgres or SQLite provider. Connect one first if you haven’t already: 
bridge init
bridge connect postgres://localhost:5432/mydb --as db
Then generate: 
bridge generate mcp \
  --from db \
  --connection db \
  --name my-db \
  --out my-db.mcp.yaml
For Postgres, you can target a non-default schema with --schema: 
bridge generate mcp \
  --from db \
  --connection db \
  --schema analytics \
  --name analytics-db \
  --out analytics.mcp.yaml
SQLite does not use named schemas, so --schema is ignored for SQLite connections.

​
What Bridge generates from a database

Bridge introspects the schema and produces two tools per table:
  • list_<table> — returns multiple rows with optional filters, sort, and pagination
  • get_<table>_by_<key> — returns a single row by primary key
Tables without a detectable primary key get a list_* tool only. Tables with composite primary keys are skipped. Skipped objects are reported in the skipped field of the output. The manifest stores the connection name (from bridge.yaml), not the connection string itself, so it is safe to commit.

​
Generation output

Both paths print JSON to stdout on success: 
{
  "status": "generated",
  "manifest": "my-api.mcp.yaml",
  "name": "my-api",
  "tools": ["get_users", "get_orders", "get_products"],
  "skipped": [],
  "client_snippet": {
    "mcpServers": {
      "my-api": {
        "command": "/usr/local/bin/bridge",
        "args": ["mcp", "serve", "/absolute/path/to/my-api.mcp.yaml"]
      }
    }
  }
}
The client_snippet is the exact config block to paste into Claude Desktop, Cursor, or any MCP client that uses the mcpServers format. The path inside args is the absolute path to your manifest on the current machine.

​
Overwriting an existing manifest

By default, bridge generate mcp refuses to overwrite an existing file at --out: 
{
  "error": {
    "code": "provider_error",
    "message": "my-api.mcp.yaml already exists. Re-run with --force to overwrite."
  }
}
Pass --force to overwrite: 
bridge generate mcp \
  --from openapi ./openapi.yaml \
  --name my-api \
  --out my-api.mcp.yaml \
  --force

​
What generation does not cover

The current release supports:
  • GET operations from OpenAPI 3.0 specs
  • list and get-by-key SQL tools from Postgres and SQLite databases
It does not yet support:
  • POST, PUT, PATCH, or DELETE operations from OpenAPI specs
  • Custom tool descriptions or schema overrides at generation time
For the full manifest format and what you can safely hand-edit after generation, see MCP manifest.

Serve an MCP server

Run the manifest you just generated over stdio or HTTP.

MCP manifest

See the full bridge.mcp/v1 format and what each field does.

Providers

Set up a Postgres or SQLite provider before generating from a database.

Commands

Full flag reference for bridge generate mcp.