I made my website callable by another AI agent — here's the actual JSON-RPC

A developer has integrated the Agent2Agent (A2A) protocol into their llms.txt validator service, enabling other AI agents to discover and call it directly over HTTP without human intervention. The implementation uses a JSON-RPC 2.0 endpoint and a machine-readable agent card, demonstrating a practical example of agent-to-agent communication. The developer emphasizes that advertised skills must resolve to real, working behavior to maintain trust.

Most "AI integration" still means a human reads your docs and writes a client. A2A flips that: another agent reads a small machine description of what your service does and calls it directly — no browser, no scraping, no human in the loop. I wired it up on a small tool I run a free llms.txt validator and it's simpler than the acronyms suggest. Here's the whole thing, with the real requests. 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 of a public API: instead of publishing OpenAPI docs for humans, you publish a machine description another agent can consume and invoke. It has exactly two moving parts: That's it. You can ship a useful A2A surface with one skill and a single method. You serve 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 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." } } The card is a contract , not a meta tag. An agent fetches it, sees a validate llms txt skill, and knows both what you offer and where to call. The card's url points at a JSON-RPC 2.0 endpoint. An agent invokes the message/send method with a message; you do the work and return a Task . Here's a real call to my 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 the calling agent can use directly: { "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 HTML, no parsing, no guessing. The agent asked a question in natural language and got back exactly the data it needed. You can curl this yourself. You don't need the whole spec to start. Pick one real thing your service does and: /.well-known/agent-card.json with one skill. message/send method wrapping that capability. Task with the result as an artifact.Streaming, task history, and push notifications are all optional — set capabilities.streaming to false and add them only when you actually need them. They stack rather than compete: A2A reaches networked agents, WebMCP reaches in-browser ones, MCP wires tools into one model. It's tempting to drop an agent card to look modern and leave the endpoint returning 501 . Don't. An agent that fetches your card and calls a dead url trusts you less afterward — you've spent its call for nothing. Every skill you advertise should resolve to real, working behavior. That's why the validator https://llms-txt-validator.dev/ I built reports an A2A signal as "present" only when a live endpoint actually answers message/send . If you ship one, drop your agent card in the comments — I'd like to call it.