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 the cross-business network endpoint at coreloop.so/api/mcp/coreloop-directory (seven tools: search plus business-targeted reads and the shared inquiry path; /api/mcp/directory is the older alias, still served).
• 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 network router at coreloop.so/api/a2a/coreloop-directory behind the platform agent card.
• 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

Two 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 directory 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.

Both carry only CoreLoop’s own identity and /{slug} URL templates — never an enumeration of businesses and no business data.

A third platform document joined them with the network router: coreloop.so/.well-known/agent-card.json — a platform-level A2A agent card advertising the network router's three skills (find, compare, route-to-business). Like the other two it carries only CoreLoop's own identity; a business is only ever reached through it subject to that business's published status and its own protocol switches.

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 one exception (send_inquiry, see MCP).
• 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.

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.