Your API as an MCP tool surface

Two adapters, one mental model. --enable-mcp-adapter exposes the target API's methods as MCP tools. bowire mcp serve exposes Bowire's own primitives (discover / invoke / record / mock) as MCP tools.

Claude Desktop, Cursor, Copilot, custom MCP clients — same wire, same auth, same recordings. The adapter generates tool definitions automatically from the discovery pass, so a new method on a running server is callable by the agent within the next discovery tick.

MCP adapter — the agent calls your methods

Pass --enable-mcp-adapter and every discovered method becomes an MCP tool with JSON Schema input. The agent sees one tool per method, types match the schema, streaming responses surface as MCP streams.

The agent's view: an MCP server at the URL you point its config at, with one tool per discovered method (e.g. UserApi.GetUser, Orders.Create, EventsHub.NotifyAll). Each tool carries a JSON Schema derived from the method's discovered shape — the agent picks the right tool and supplies typed arguments without you authoring an MCP server.

Auth flows through whichever provider the workbench itself runs under (Bearer / JWT / OAuth2 / mTLS); the agent never sees a second credentials store. Streaming methods (gRPC server-streams, SignalR hub events, MQTT subscriptions, GraphQL subscriptions) surface as MCP streaming tools so an agent can subscribe to a feed the same way a human would in the workbench.

MCP adapter docs → 
sequenceDiagram
    autonumber
    participant Plugins as Protocol plugins
    participant MCP as MCP endpoint
    participant Agent as AI agent
    participant API as Target API

    Note over Plugins,MCP: Startup
    Plugins->>MCP: DiscoverAsync() · per method
    MCP->>MCP: build tool catalogue (JSON Schema per method)

    Note over Agent,API: Runtime
    Agent->>MCP: initialize
    Agent->>MCP: tools/list
    MCP-->>Agent: tool catalogue
    Agent->>MCP: tools/call (typed args)
    MCP->>Plugins: dispatch
    Plugins->>API: invoke
    API-->>Plugins: response / stream
    Plugins-->>MCP: typed result
    MCP-->>Agent: tool result / stream
On boot, IBowireProtocol.DiscoverAsync() builds a tool catalogue (one JSON-Schema-typed tool per discovered method) and registers it with the MCP endpoint. At call time, tools/call hands typed args to the matching protocol plugin — gRPC, REST, GraphQL, WebSocket, MQTT — and the response (or stream) flows back to the agent.

bowire mcp serve — the agent drives Bowire

The flip side: an MCP server that exposes Bowire's own primitives. An agent can chain discover → invoke → assert → switch env → replay the same way a human would in the workbench.

Primitives exposed: bowire.discover, bowire.invoke, bowire.subscribe, bowire.env.list, bowire.record.{list, start, stop, replay}, bowire.mock.{start, stop, list}, bowire.allowlist.show. Two transport modes: stdio for desktop clients (Claude Desktop, Cursor) and HTTP for remote agents (Copilot in CI, custom MCP runners).

Tools are gated by the same allow-list the workbench uses — an agent can't reach a method a human couldn't. Run the two adapters side by side if you want an agent that can both call your methods and orchestrate Bowire's record / mock / replay around them.

MCP serve docs → 
sequenceDiagram
    autonumber
    participant Agent as AI agent
    participant Serve as bowire mcp serve
    participant Allow as Allow-list
    participant Ops as bowire.* ops
    participant State as ~/.bowire/

    Agent->>Serve: tool call (stdio · HTTP)
    Serve->>Allow: check method
    alt allowed
        Allow-->>Serve: ✓
        Serve->>Ops: execute
        Ops->>State: read / write
        State-->>Ops: snapshot
        Ops-->>Serve: result
        Serve-->>Agent: tool result
    else denied
        Allow-->>Serve: ✗
        Serve-->>Agent: refuse
    end
The agent orchestrates Bowire’s own primitives (bowire.discover, invoke, record.{list,start,stop,replay}, mock.{start,stop,list}, env.{list,switch}) over stdio or HTTP. The allow-list is the same gate a human would face; recordings, envs, mocks live in ~/.bowire/ so state stays reachable across calls.

Three concrete shapes the agent unlocks

Patterns where an MCP-driven Bowire pays off the setup cost.

  • Agent as a teammate. “Find every order in the last hour that has status=failed, attach the response payloads, draft a slack message.” The agent calls OrderApi.List via the MCP adapter, parses the typed response, picks the failed ones — without anyone hand-wiring an MCP server for the order API.
  • Agent as a regression runner. “Replay yesterday's captured session against staging and tell me which 5 calls differ.” The agent calls bowire.record.list, picks the most recent, runs bowire.record.replay against the staging env, parses the diff. Everything via bowire mcp serve; no shell-out, no log-parsing.
  • Agent as a mock conductor. “Spin up a mock for the order API, run my integration tests against it, then tear it down.” bowire.mock.start → tests run → bowire.mock.stop. The mock fixture lives in version control as a recording; the agent never needs the real backend.

Wire an agent in

Two adapters, both ship in the same CLI. Drop the URL into your agent's config, you're done.

AI-agent workflow MCP adapter docs Feature reference

A different lane fits better? All solution lanes →