# A2A: let AI agents call your site

> A2A (Agent2Agent) is the open protocol that lets one AI agent discover and call another over the network — no browser, no scraping. Here's what it is and how any website can expose a skill, with the working agent we run on this validator.

An AI agent just validated this site without opening a browser, clicking a button, or scraping a page — it read a small JSON file, sent one typed request, and got a structured result back. That exchange is A2A, and any website can offer it.

## What A2A is

A2A (Agent2Agent) is an open protocol — now under the Linux Foundation — that lets AI agents *discover and call each other* over plain HTTP. Think of it as the agent-to-agent counterpart to a public API: instead of a human reading your docs and writing an integration, another agent reads a machine description of what your service does and calls it directly.

It has two parts: a discovery document (the **agent card**) and a callable endpoint (the **skill**).

## 1. The agent card — discovery

You publish a JSON file at `/.well-known/agent-card.json` describing who you are and what you can do. The required fields are `name`, `description`, `version`, `url` (your A2A endpoint) and at least one `skill`:

```
{
  "protocolVersion": "0.3.0",
  "name": "llms.txt Validator",
  "description": "Validate a website's llms.txt and return a score with findings.",
  "url": "https://llms-txt-validator.dev/a2a",
  "skills": [{ "id": "validate_llms_txt", "name": "Validate llms.txt",
              "description": "Given a domain or URL, fetch and validate its llms.txt." }]
}
```

## 2. The endpoint — a callable skill

The card's `url` points at a JSON-RPC 2.0 endpoint. An agent calls the `message/send` method with a message; you do the work and return a `Task`. Here is a real call to our agent:

```
POST /a2a
{ "jsonrpc": "2.0", "id": "1", "method": "message/send",
  "params": { "message": { "role": "user",
    "parts": [{ "kind": "text", "text": "validate llmstxt.org" }] } } }
```

…and the reply — a completed task carrying a human-readable summary and structured data:

```
{ "result": { "kind": "task", "status": { "state": "completed" },
  "artifacts": [{ "parts": [
    { "kind": "text", "text": "Validated llmstxt.org: score 100/100..." },
    { "kind": "data", "data": { "ok": true, "report": { "scores": { "overall": 100 } } } }
  ] }] } }
```

No browser, no HTML parsing — the agent gets exactly the data it asked for.

## A2A vs WebMCP vs MCP

  - **A2A** — networked agents calling your service over HTTP (orchestrators, other agents). This page.

  - **WebMCP** — an agent running *inside the browser* calling tools on your open page.

  - **MCP** — connecting tools to a single model or app, usually locally.

They're complementary: A2A reaches networked agents, WebMCP reaches in-browser ones. See [how the three fit together](/guide/agent-ready-llms-txt-webmcp-a2a).

## How any site can add one

You don't need the whole protocol to start — pick *one* real thing your service does:

  - Serve a valid agent card at `/.well-known/agent-card.json` with one skill.

  - Implement the synchronous `message/send` method wrapping that capability, and return a completed `Task` with the result as an artifact.

  - Streaming, task history and push notifications are optional — set `capabilities.streaming` to false and add them only when you need them.

## The one rule: back the card with a real endpoint

The card is a contract, not a meta tag. If you publish a card whose `url` doesn't actually answer `message/send`, every agent that trusts it hits a dead end. Expose A2A only for capabilities you can truly serve — that's how we built ours, and it's why our own report marks the signal present only when a working endpoint backs it. Want to see it live? Fetch our [agent card](/.well-known/agent-card.json).