Documentation Index
Fetch the complete documentation index at: https://agentclientprotocol.com/llms.txt Use this file to discover all available pages before exploring further.
Initialization
How all Agent Client Protocol connections begin
The Initialization phase allows Clients and Agents to negotiate protocol versions, capabilities, and authentication methods.
sequenceDiagram
participant Client
participant Agent
Note over Client, Agent: Connection established
Client->>Agent: initialize
Note right of Agent: Negotiate protocol<br/>version & capabilities
Agent-->>Client: initialize response
Note over Client,Agent: Ready for session setupBefore a Session can be created, Clients MUST initialize the connection by calling the initialize method with:
- The latest protocol version supported
- The capabilities supported
- The implementation information for the Client
{
"jsonrpc": "2.0",
"id": 0,
"method": "initialize",
"params": {
"protocolVersion": 2,
"capabilities": {},
"info": {
"name": "my-client",
"title": "My Client",
"version": "1.0.0"
}
}
}
The Agent MUST respond with the chosen protocol version, the capabilities it supports, and its implementation information:
{
"jsonrpc": "2.0",
"id": 0,
"result": {
"protocolVersion": 2,
"capabilities": {
"session": {
"prompt": {
"image": {},
"audio": {},
"embeddedContext": {}
},
"mcp": {
"stdio": {},
"http": {}
}
}
},
"info": {
"name": "my-agent",
"title": "My Agent",
"version": "1.0.0"
},
"authMethods": []
}
}
authMethods is optional. Returning one or more valid entries advertises the Agent’s authentication surface and means the Agent MUST implement both auth/login and auth/logout. If authMethods is omitted or empty, Clients MUST NOT call either method.
capabilities.auth is separate from this method surface. It advertises authentication-related extensions and does not change the availability rules for auth/login or auth/logout.
Protocol version
The protocol versions that appear in the initialize requests and responses are a single integer that identifies a MAJOR protocol version. This version is only incremented when breaking changes are introduced.
Clients and Agents MUST agree on a protocol version and act according to its specification.
See Capabilities to learn how non-breaking features are introduced.
Version Negotiation
The initialize request MUST include the latest protocol version the Client supports.
If the Agent supports the requested version, it MUST respond with the same version. Otherwise, the Agent MUST respond with the latest version it supports.
If the Client does not support the version specified by the Agent in the initialize response, the Client SHOULD close the connection and inform the user about it.
Capabilities
Capabilities describe features supported by the Client and the Agent.
All capabilities included in the initialize request are OPTIONAL. Clients and Agents SHOULD support all possible combinations of their peer’s capabilities.
The introduction of new capabilities is not considered a breaking change. Therefore, Clients and Agents MUST treat all capabilities omitted in the initialize request as UNSUPPORTED.
Capabilities may advertise top-level method surfaces or nested features that only apply within a supported surface.
Capabilities may specify the availability of protocol methods, notifications, or a subset of their parameters. They may also signal behaviors of the Agent or Client implementation.
Implementations can also advertise custom capabilities using the _meta field to indicate support for protocol extensions.
Client Capabilities
Clients MAY include defined capability fields in capabilities.
Omitted fields mean unsupported. Extension-specific capabilities belong in
_meta.
Terminal Authentication
Elicitation
Agent Capabilities
The Agent SHOULD specify whether it supports the following capabilities:
Session Capabilities
Supplying session: {} means the Agent supports session/new,
session/list, session/resume, session/close, session/prompt,
session/cancel, and session/update.
Optionally, Agents MAY support prompt extensions, MCP server transports, and
additional session methods such as session/delete by specifying nested
capabilities.
Session Prompt Capabilities
As a baseline, Agents that advertise session MUST support ContentBlock::Text and ContentBlock::ResourceLink in session/prompt requests.
Optionally, they MAY support richer types of content by specifying the following capabilities:
Session MCP Capabilities
Implementation Information
Both Clients and Agents MUST provide information about their implementation in the info field. It takes the following three fields:
Once the connection is initialized, you’re ready to create a session and begin the conversation with the Agent.
Last updated Oct 08, 2026