Agent protocols overview

This section is the technical reference. It’s written for developers building agents and for owners who want the detail; protocol names are used precisely here. If you run a business and just want things to work, you can stop at Where people and agents find you, the protocols are our job, not yours.

One profile, four surfaces

Every published CoreLoop business is one canonical profile projected onto four agent-facing surfaces:

• MCP — a per-business Model Context Protocol server at coreloop.so/api/mcp/{slug}, plus a cross-business network endpoint at coreloop.so/api/mcp/coreloop-directory (the older /api/mcp/directory address still works).
• A2A — an Agent2Agent protocol endpoint at coreloop.so/api/a2a/{slug}, with an agent card at coreloop.so/{slug}/.well-known/agent-card.json, plus the cross-business network endpoint at coreloop.so/api/a2a/coreloop-directory.
• llms.txt — plain-text discovery files, per business and platform-wide.
• WebMCP — in-page tools on the CoreLoop Page, on a custom domain, and on the business’s own website.

The surfaces are derived views, never independent copies. A profile edit propagates to all of them; none can drift from the others.

On a business’s custom domain the same surfaces are served same-origin — the page, llms.txt and the agent card resolve at the domain root, and MCP/A2A requests are answered there.

Platform-level discovery

Three documents describe CoreLoop itself rather than any one business:

• coreloop.so/llms.txt — the platform index.
• coreloop.so/.well-known/mcp.json — an MCP server card (SEP-1649 shape) advertising the network endpoint over streamable HTTP, all seven of its tools, and the per-business URL templates. It is served CORS-open so browser-based agents can read it.
• coreloop.so/.well-known/agent-card.json — the A2A twin of the above: CoreLoop’s own agent card, describing the network endpoint at coreloop.so/api/a2a/coreloop-directory and its three skills (find a business, compare one business’s services, ask a business). The card is generated from those skills, and the endpoint itself serves the identical document.

The directory page itself says the same thing in its own structured data: alongside the list of businesses on it, it declares the two network endpoints above as its own agent interfaces, each pointing at whichever of the documents above documents it. So an agent that lands on the human directory page can find the machine one without being told where to look.

All three carry only CoreLoop’s own identity — never an enumeration of businesses and no business data. The first two also carry /{slug} URL templates so an agent can build a per-business address itself; the agent card carries its skills, a link to these docs and the CoreLoop icon instead.

The gates every request passes

All network surfaces share the same request discipline, in a fixed order: resolve the business (renamed slugs return a 301) → publishing-status gate (only published profiles are served; anything else errors before revealing whether the slug exists) → per-channel owner switch → rate limit → execute → log the interaction.

Shared properties worth designing against:

• Public and unauthenticated, secured by rate limits, response bounds, and logging rather than API keys.
• Read-only, with two exceptions. Sending an inquiry (see MCP) is the only thing that writes data on our side: a rate-limited message delivered to the owner. It is the same single behaviour under two names — send_inquiry on a business's own channel, and send_business_inquiry when an agent reaches the business through the network endpoint. The other is WebMCP’s form_draft, which does not send anything anywhere — after the visitor confirms, it types values into form fields the owner has approved, on the page in front of them, leaving the submit button to the visitor.
• No PII. Responses contain business information only, never owner or customer data.
• Locale-aware where it matters: ?locale query parameter beats Accept-Language, which beats the profile’s original content locale. (llms.txt is the documented exception.)
• Owner-controllable. Every surface obeys a per-channel switch and the master unpublish.

Questions, and who carries which tool

One tool is worth singling out. ask answers a plain question with quoted passages from the business’s own material — its website text, anything the owner wrote or listed themselves, and its public documents — each with its source: a retrieval over the business’s own text, never generated prose, and offered only while that business’s knowledge is eligible. It answers on MCP, and on A2A it is what free-text messages route to; in a visitor’s browser it is allowed but starts switched off until the owner turns it on.

Which channel carries which tool is the owner’s decision, tool by tool: Where each tool is offered explains the Access table and the two coarser switches that sit above it.

What these surfaces do not do

No booking or payment execution, no write access to profile data, no per-customer state. The toolset is accurate answers plus a single, rate-limited inquiry path.