Endpoint conventions
What each endpoint slot in the capabilities and commerce blocks means, what shape its responses take, and what auth and scope conventions apply. The manifest never describes the endpoint's internals - that is the linked protocol's job. It just declares where the endpoint lives and what scopes it exposes.
Endpoint slots in the manifest
Every slot's purpose at a glance.
| Slot | Block | Protocol | Required? |
|---|---|---|---|
| mcpServers[] | capabilities | MCP | Recommended |
| a2aAgentCards[] | capabilities | A2A | No |
| nlwebEndpoint | capabilities | NLWeb | No |
| openApi | capabilities | OpenAPI 3.x | No |
| cli | capabilities | - | No |
| catalog | commerce | UCP / Schema.org | Only for commercial entities |
| paymentRails[] | commerce | AP2, ACP, x402 | Only for commercial entities |
| incidentWebhook | state | Webhook | No |
| statusPage | state | - | No |
MCP servers
The most important slot. Where tools, resources and prompts live.
Why MCP comes first
The chat v2 loop is the most common consumer of BCP manifests. When an Ultron agent reads a peer company's manifest, the first thing it looks for is an MCP server URL it can connect to. That URL becomes the entry point for every subsequent action.
Multiple servers
A company may expose multiple MCP servers, e.g. a public read-only catalog server and an authenticated write server. List them as separate entries inmcpServers. Consumers pick the one whose scopes match what they need.
OAuth metadata
When auth includesoauth2, the MCP server must host/.well-known/oauth-authorization-serverper RFC 8414. The BCP manifest does not duplicate that metadata - consumers fetch it from the standard well-known path on the MCP server's host.
A2A agent cards
One URL per agent card. Each card describes one agent.
A BCP manifest describes a company. An A2A agent card describes one agent. When the company runs multiple agents (sales bot, support bot, billing bot), each gets its own agent card and they are all listed ina2aAgentCards.
The agent card URL is alwayshttps://<host>/.well-known/agent.jsonper A2A's RFC 8615 convention. The manifest carries the full URL - consumers do not need to derive it.
AP2 payments
Where to submit signed payment mandates.
AP2 (Agent Payments Protocol, Google + Mastercard + American Express + Coinbase + PayPal + Adyen + Worldpay) is the broadest payment protocol in the agentic stack. AP2 sits as an extension over A2A and MCP, using three "Mandates" (Intent, Cart, Payment) as W3C Verifiable Credentials. The BCP manifest exposes the AP2 endpoint URL plus the accepted instruments.
Catalog (UCP)
A queryable product / service catalog endpoint.
The catalog endpoint returns a UCP-compatible product feed or Schema.org-typed product list. Used by agents to answer questions like "what do you sell" or "what tier should I buy for 5 users". The endpoint should support filtered queries; the exact query language is delegated to UCP.
NLWeb /ask
Natural-language query over the company's structured data.
NLWeb (Microsoft, R.V. Guha) exposes a single/ask endpoint that accepts a natural-language query and returns Schema.org-typed JSON. When a publisher operates a NLWeb instance, the BCP manifest links to it so consumers can use it for conversational queries without learning the publisher's internal API.
/mcpendpoint per their README. If a publisher runs NLWeb, they can either link to it from thenlwebEndpoint slot or from themcpServers array. Both are valid; the slots overlap by design because some consumers prefer one transport over the other.OpenAPI
Traditional REST API spec, for consumers that prefer it.
OpenAPI 3.x is still the most widely understood machine- readable API description. The manifest can link to an OpenAPI spec for consumers that want to generate clients, test endpoints, or fall back from MCP / A2A to plain REST.
CLI install
Optional, but useful for developer-friendly publishers.
Some companies want their CLI to be discoverable from a BCP manifest. Thecli object declares the install command and the executable name; that is enough for a developer agent to fetch and run.
Contact and booking endpoints
Where to send the human-style asks.
Not every action is a programmatic transaction. A consumer agent might want to submit a contact-form lead, request a sales call, or book a slot on a public calendar. These actions are surfaced as MCP tools under the public MCP server, with conventional scopes (see below) so consumers can find them deterministically.
- Lead submission
- Scope
leads.createon the public MCP server. - Sales call booking
- Scope
bookings.createon the public MCP server. - Contact form
- Scope
contact.sendon the public MCP server. - Direct mail
- Email address in
state.supportContact.email. Plain SMTP target, no protocol.
Scope vocabulary
Conventional scope names every BCP-compliant MCP server should support.
BCP defines a small vocabulary of conventional scopes so consumer agents can search a target manifest'spolicy.allowActions list with deterministic strings. Publishers may add custom scopes beyond this list; consumers ignore scopes they do not recognise.
| Scope | Means | Read or write |
|---|---|---|
| catalog.read | Read product / service catalog | read |
| pricing.read | Read pricing tiers and prices | read |
| docs.read | Read public documentation | read |
| leads.create | Submit a new lead to the company's CRM | write |
| leads.read | Read leads the agent has previously created (auth required) | read |
| bookings.create | Book a slot on the company's calendar | write |
| bookings.cancel | Cancel a previously-created booking | write |
| contact.send | Send a message via the company's contact form | write |
| agreements.sign | Counter-sign agreements (auth required) | write |
| billing.read | Read billing state for the agent's own account | read |
| billing.write | Modify billing state | write |
| webhooks.subscribe | Subscribe to events | write |
acme.specialAction). The unprefixed names above are reserved for the spec.