---
title: "What Is agents.json? A Manifest for Website Tools"
description: "agents.json explained with a restaurant example. What the manifest describes, how an agent could use it and how it differs from WebMCP."
author: "Matthias Meyer"
published: 2026-02-15
updated: 2026-09-30
updates:
  - date: 2026-09-30
    note: "Identified agents.json as a custom manifest and corrected ChatGPT, WebMCP, A2A and permission claims."
language: en
tags: ["agents-json", "webmcp", "api", "ki-agenten", "discovery", "robots-txt"]
canonical: "https://studiomeyer.io/en/blog/agents-json-explained"
markdown_versions: ["https://studiomeyer.io/de/blog/agents-json-explained.md", "https://studiomeyer.io/en/blog/agents-json-explained.md", "https://studiomeyer.io/es/blog/agents-json-explained.md"]
publisher: "StudioMeyer, https://studiomeyer.io (llms.txt: https://studiomeyer.io/llms.txt)"
---

# What Is agents.json? A Manifest for Website Tools

A machine-readable description can tell an agent which interfaces a website provides. An `agents.json` is one way to do that. The file alone neither implements an interface nor makes ChatGPT or Claude automatically discover the site.

Different community proposals and custom implementations use the name agents.json. No universal standard requires every agent to support the following format. This article shows a **simplified custom manifest format** a website could publish at `/.well-known/agents.json`.

## What the file describes

A manifest can combine a name, address and documented public functions. Every function points to an implemented endpoint. A fictional restaurant might use this:

```json
{
  "schema_version": "1.0",
  "name": "Example Restaurant",
  "url": "https://restaurant.example",
  "tools": [
    {
      "name": "get_menu",
      "description": "Retrieve the current menu",
      "endpoint": "/api/menu",
      "method": "GET",
      "parameters": {}
    },
    {
      "name": "request_reservation",
      "description": "Submit a reservation request; confirmation is pending",
      "endpoint": "/api/reservation-requests",
      "method": "POST",
      "parameters": {
        "date": { "type": "string" },
        "guests": { "type": "integer", "minimum": 1 }
      }
    }
  ]
}
```

Here `schema_version` is the version of this custom format. The file is neither a WebMCP manifest nor automatically an MCP server. The `.example` address and endpoints are placeholders.

The important part is the effect: `request_reservation` submits a request rather than promising a confirmed booking. The server must handle missing information, permissions and errors.

## How an agent could use it

1. The agent or integration knows the manifest address.
2. It reads the function descriptions and chooses one matching the task.
3. It retrieves the menu through the documented GET endpoint.
4. Before requesting a reservation, it checks the required details and user authorization.
5. It reports the actual result: requested, confirmed or rejected.

Without a suitable integration the file may never be read. Publishing it therefore proves neither additional visitors nor automatic actions.

## agents.json, Agent Card and WebMCP

| Description | Purpose |
|---|---|
| Custom agents.json | Describe HTTP functions in an agreed format |
| A2A Agent Card | Advertise an agent and its executable skills |
| WebMCP | Register JavaScript tools in an open browser document |

A2A 1.0 puts the address, binding and protocol version in `supportedInterfaces`. This is a shortened excerpt, not a complete valid card:

```json
{
  "name": "Example Restaurant Agent",
  "supportedInterfaces": [
    {
      "url": "https://restaurant.example/a2a",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ],
  "skills": [
    {
      "id": "reservation-request",
      "name": "Request a reservation",
      "description": "Accepts a request; the restaurant confirms separately",
      "tags": ["restaurant", "reservation"]
    }
  ]
}
```

The [A2A guide](https://studiomeyer.io/en/blog/a2a-protocol-explained) shows a full card and workflow. A reservation skill needs an agent that actually responds. WebMCP instead uses the browser API `document.modelContext`; validating custom agents.json does not establish WebMCP conformance.

## Publish and secure it

Serve JSON at the documented address. Keep names, parameters and descriptions aligned with actual endpoints. Test each function before advertising it.

A publicly readable file does not always need `Access-Control-Allow-Origin: *`. CORS applies to browser requests, not ordinary server-side agents. Allow browser access only as needed. Read endpoints can also require authentication when they return customer data.

The manifest is not access control. Authentication, permissions, rate limits and checks on write actions belong on the server. Descriptions and results can also contain malicious instructions that an agent should treat as untrusted.

## Complement the website

`robots.txt` controls crawling rather than reliably preventing indexing. Sitemaps help discover URLs. An agents.json manifest describes possible interactions. These roles complement one another but do not form a mandatory shared standard.

A simple information site may gain little from a manifest. For an application with useful APIs, test a specific agent workflow. The file starts documentation; it does not guarantee AI traffic.

Sources: [A2A 1.0](https://a2a-protocol.org/v1.0.0/specification/), [WebMCP](https://webmachinelearning.github.io/webmcp/), [Google on robots.txt](https://developers.google.com/search/docs/crawling-indexing/robots/intro).

## Read more, WebMCP + agent protocols

- [A2A Protocol Explained: How AI Agents Talk to Your Website](https://studiomeyer.io/en/blog/a2a-protocol-explained.md)
- [WebMCP Reality Check: Where the Spec Actually Stands](https://studiomeyer.io/en/blog/webmcp-reality-check-may-2026.md)
- [WebMCP: The Emerging Web Protocol for AI Agents](https://studiomeyer.io/en/blog/webmcp-w3c-standard.md)