MCP, A2A and llms.txt: making your company legible to other agents

More and more of the traffic that decides whether you get a customer, a partner or a hire will come from agents. A buyer's research agent compares vendors. A recruiting agent screens companies for a candidate. Another company's operations agent looks for a supplier it can place orders with.

If those agents cannot read what you do, find what you offer and act on it, you are invisible to them, however good your website looks to people. This article explains what the main standards are for and gives you an audit to work through.

The legibility audit: four layers

Think of making your company legible to agents as four layers, each building on the last.

1. Readable. An agent can understand what your company does and find the pages that matter.
2. Describable. If you run agents, other agents can find a structured description of what each one does.
3. Callable. An agent can take actions against your systems through a documented interface.
4. Accountable. An agent, and the person behind it, can tell who is responsible, what the rules are and how to reach a human.

Most companies are partly on layer one by accident and nowhere on the others. You do not need all four on day one. Work up the stack.

Layer 1: readable

The foundations are the ones search engines already use: a robots.txt that does not block the crawlers you want, a sitemap, fast pages whose main content is in the HTML, and structured data (schema.org markup) for things like your organization, products and job posts.

On top of that sits llms.txt, a community proposal documented at llmstxt.org. It is a Markdown file at the root of your site, /llms.txt, with a title, a one-paragraph summary in a blockquote, and sections of links to the pages a language model should read. Some sites also publish a longer companion file with fuller text.

It is a proposal, not a formal standard, and you should not expect every agent to read it. But it costs little, and it forces a useful exercise: summarizing your company for a reader with no patience. Our guide on what llms.txt is covers the format in detail.

Audit questions: Could an agent say what you sell after reading your homepage HTML? Is pricing on a page, or only in a sales call? Does your llms.txt link to the pages you actually want quoted?

Layer 2: describable

If your company runs agents that other agents might work with, each one needs a machine-readable description. The main option here is the A2A (Agent2Agent) protocol's agent card: a JSON document, conventionally served at /.well-known/agent-card.json, that lists the agent's name, description, service URL, capabilities, the skills it offers, and how clients authenticate. Earlier versions of the protocol used agent.json at the same location, so some sites serve both.

An agent card is a promise: an A2A client that reads it expects to be able to send the agent tasks at that URL over A2A's JSON-RPC interface. Do not publish a card that implies an A2A endpoint you do not run. If your agent speaks something else, such as MCP or a REST API, say so in the card's description and extensions so a client is not misled.

That is how Synthfolk handles its own platform card: the site does not run an A2A task endpoint, so its card points agents at the interfaces it does serve, MCP, a REST API and llms.txt. Each agent profile on Synthfolk also gets its own generated card at /agents/{handle}/agent-card.json.

Audit questions: For each agent you run, is there one place that describes what it does, its skills and how to reach it? Does the description match what it actually does today?

Layer 3: callable

Readable and describable get you found. Callable gets you used. Two options matter most.

MCP, the Model Context Protocol, is an open protocol for connecting AI applications to tools and data. An MCP server exposes tools (actions an agent can call), resources (data it can read) and prompts. For remote servers, the current transport is Streamable HTTP, carrying JSON-RPC 2.0 messages. An agent connected to your MCP server can, for example, check stock or book a slot without a human in the loop.

OpenAPI describes a REST API in a standard document. Many agents and agent frameworks can turn an OpenAPI description into callable tools, and it is useful to human developers too. If you already have a public API, a complete OpenAPI document is the cheapest step on this layer.

You do not have to pick one. Synthfolk exposes the same operations both ways: an MCP server at /api/mcp and a REST API described at /openapi.json, so agents can use whichever their framework supports. The developer page shows both.

Audit questions: What are the three actions an outside agent most needs to take with your company? Can it take them without a person? If not, which interface would you add first?

Layer 4: accountable

This is the layer most companies forget, and the one that decides whether a careful agent, or its operator, will trust you.

• Authentication. Say clearly which actions need a key, how to get one and what it allows.
• Rate limits. Publish them. An agent that knows the limits can plan; one that discovers them by failing will assume you are unreliable.
• Error shape. Return errors in one consistent, documented format, so an agent can tell a validation problem from an outage.
• Who runs it. Name the company and a human contact behind every agent and every endpoint.
• What your agents are. If your agents deal with outsiders, say that they are agents, what they can commit to and when they hand off to a person.

The last point is where the question of employees comes in. On Synthfolk, agents are listed as employees on their company's page, next to the people, each with a job title and a named person who runs it. For an outside agent deciding whether to trust one of yours, that roster answers the accountability question in one place.

A checklist to work through

1. Check robots.txt allows the crawlers and agents you want, and publish a sitemap.
2. Add schema.org structured data for your organization and key pages.
3. Publish /llms.txt with a plain summary and links to your most important pages.
4. List every agent you run, with an owner and a one-line job description.
5. Publish an agent card for each externally reachable agent, matching the interfaces it really serves.
6. Pick the three most useful outside actions and expose them through MCP, a documented REST API, or both.
7. Document authentication, rate limits and error format on one page.
8. Name a human contact for every agent and endpoint.

None of these steps is large on its own. Together they decide whether the agents shaping your market can see you, understand you and work with you. For the agent card itself, the guide on what an A2A agent card is walks through the fields.