ACP: Agent Context Protocol

A service discovery standard for the agentic web.

ACP defines how services advertise their capabilities to AI agents. Instead of requiring agents to run local adapter servers, the service hosts a structured manifest. Agents fetch it at runtime and call the API directly over HTTPS.

• No local server process
• No SDK dependency
• No context injection at startup
• No resource overhead between tasks

One JSON file. Every agent on the internet can consume it.

---

How It Works

A service adds a services block to /.well-known/agents.json:

{
  "version": "1.0",
  "services": {
    "name": "Your API",
    "description": "What your API does in one sentence.",
    "version": "1.0.0",
    "base_url": "https://api.yourservice.com/v1",
    "auth": {
      "type": "bearer",
      "instructions": "Pass your API key as a Bearer token in the Authorization header."
    },
    "tools": [
      {
        "id": "do_thing",
        "description": "Does the thing.",
        "endpoint": "/thing",
        "method": "POST",
        "input": {
          "type": "object",
          "required": ["name"],
          "properties": {
            "name": {
              "type": "string",
              "description": "The name of the thing."
            }
          }
        }
      }
    ]
  }
}

An agent fetches this file, reads the tool definitions, and calls https://api.yourservice.com/v1/thing directly. No adapter. No translation layer. No local process.

---

The Problem ACP Solves

The current model for agent-service integration (MCP) requires agents to run a local server for every service they use. Each server injects tool definitions into the agent's context window, consumes local resources, and must be maintained by the consumer.

This is a device driver model applied to services that already have perfectly good APIs. ACP replaces it with the pattern the web already uses: the service describes itself, the client calls it.

	MCP	ACP
Who runs the adapter?	The agent (consumer)	Nobody. It's a JSON file.
Where do tool definitions live?	Injected into agent context at startup	Fetched on demand from the service
What runs locally?	A server process per service	Nothing
Who maintains it?	The consumer	The service provider
How does it scale to 50 services?	Poorly	The same as 1 service

Where MCP Still Makes Sense

ACP does not replace MCP for local tools (file system, databases, IDE integration), private integrations behind firewalls, or use cases requiring persistent bidirectional connections. For public and semi-public services with REST APIs, ACP is simpler.

---

The Spec Family

ACP is part of a three-spec family for the agentic web:

Spec	Full Name	Scope	Deliverable
ASM	Agent Site Manifest	Site-level	site block in agents.json
ACP	Agent Context Protocol	Service-level	services block in agents.json
LEAN	Layered Efficiency for Agentic Navigation	Design philosophy	Guides authoring of both

All three deliver through a single file: /.well-known/agents.json. A website with no API uses ASM. A headless API uses ACP. A full product uses both.

---

Repository Structure

spec/
  ACP-Spec-v0.1.md              # The specification
examples/
  minimal-api/                   # Simplest possible ACP manifest
  oauth-protected/               # Service with OAuth2 auth
  grouped-tools/                 # Using capability groups for large APIs
  migration-from-mcp/            # Side-by-side MCP server vs ACP manifest
README.md
LICENSE

---

Contributing

ACP is a living specification. Feedback, implementation reports, and example manifests are welcome.

• Open an issue to report problems or suggest improvements.
• Submit example agents.json manifests for real or fictional services.
• If you are a service provider or agent framework implementing ACP, we want to hear about it.

Author

Wesley Shoffner, Clocktower & Associates

License

MIT