Help us improve
Share bugs, ideas, or general feedback.
From a2a-multi-agent
Implements A2A JSON-RPC 2.0 transport layer: request/response formats, method routing, batch requests, HTTP details. For custom A2A transport handling or protocol debugging.
npx claudepluginhub orcaqubits/agentic-commerce-skills-plugins --plugin a2a-multi-agentHow this skill is triggered — by the user, by Claude, or both
Slash command
/a2a-multi-agent:a2a-jsonrpc-transportThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
**Fetch live docs**:
Builds A2A servers handling JSON-RPC requests at agent endpoints, routing methods, managing task states, and executing agent logic via SDK handlers.
Implement a JSON-RPC 2.0 A2A server with task lifecycle management, SSE streaming, and push notifications for multi-agent workflows.
Implements AP2 payment protocol as A2A extension in multi-agent systems: mandates DataParts in messages, Agent Cards for capabilities, payment task flows, and inter-agent communication.
Share bugs, ideas, or general feedback.
Fetch live docs:
https://a2a-protocol.org/latest/specification/ for the transport layer sectionsite:github.com a2aproject A2A JSON-RPC transport for transport protocol detailshttps://www.jsonrpc.org/specification for the JSON-RPC 2.0 base specificationA2A uses JSON-RPC 2.0 as its transport protocol because:
Every A2A request is a JSON-RPC 2.0 request:
{
"jsonrpc": "2.0",
"method": "message/send",
"id": "unique-request-id",
"params": { ... }
}
"2.0"message/send, tasks/get)Success:
{
"jsonrpc": "2.0",
"id": "unique-request-id",
"result": { ... }
}
Error:
{
"jsonrpc": "2.0",
"id": "unique-request-id",
"error": {
"code": -32600,
"message": "Invalid Request",
"data": { ... }
}
}
application/json for regular requestsapplication/json for message/send, text/event-stream for message/stream200 OK — errors are in the JSON-RPC response body, not HTTP status codes| Method | Direction | Purpose |
|---|---|---|
message/send | Client → Server | Send message, get synchronous response |
message/stream | Client → Server | Send message, get SSE stream |
tasks/get | Client → Server | Retrieve task by ID |
tasks/cancel | Client → Server | Cancel a task |
tasks/resubscribe | Client → Server | Re-subscribe to task's SSE stream |
tasks/pushNotificationConfig/set | Client → Server | Register push notification |
tasks/pushNotificationConfig/get | Client → Server | Get notification config |
tasks/pushNotificationConfig/list | Client → Server | List notification configs |
tasks/pushNotificationConfig/delete | Client → Server | Delete notification config |
agent/authenticatedExtendedCard | Client → Server | Get extended Agent Card |
The server must route incoming requests by the method field:
method fieldA2A doesn't mandate built-in idempotency, but best practice is:
message/send, sending the same message twice should be handled gracefullyjsonrpc field is exactly "2.0"message/stream)Content-Type: application/json for all non-streaming requests-32601Fetch the specification for any additional transport requirements, header conventions, and method parameter schemas before implementing.