Protocol adapters

jawb's architecture treats every external protocol — WebMCP, MCP, OpenAPI, and the emerging commerce protocols (UCP, ACP, AP2, TAP) — as a versioned adapter, not a hardcoded assumption baked into the core. Protocol status changes; draft specs are revised. The internal tool/action/observation model stays stable while adapters absorb the churn underneath it.

Implemented today

• WebMCP — discovery only. See WebMCP for the details.
• MCP (Model Context Protocol) server surface, so agents can call jawb directly over the same API and policy checks the CLI uses. Built, and ships in the next release: see MCP server.

Not implemented yet

• OpenAPI adapter for approved site APIs
• Commerce protocols — Universal Commerce Protocol, Agentic Commerce Protocol, Agentic Payment Protocol, Trusted Agent Protocol — all later, later scope tied to merchant/checkout integration

Why this matters if you're integrating

If you're a website owner, declaring WebMCP tools is the only integration surface that exists right now. If you're automating jawb, you're calling the CLI (with --json), the Rust SDK, or its own local HTTP API — not a protocol adapter at all, since that API is jawb's native interface, not an implementation of an external spec.