The Separation Principle
Task Response (what you implement):- Session tracking (context_id)
- Async operation tracking (task_id, status)
- Human-readable message
- Webhook configuration
MCP (Model Context Protocol)
Successful Response
- Human message in
content[].text - Task payload in
content[].resource.text(includes application-level context when present) - Protocol metadata in
metadata - MCP doesn’t expose
task_id- async is handled via MCP’s progress notifications
Async Response (Long-Running Operation)
A2A (Agent-to-Agent Protocol)
Successful Response
- Human message in
messages[]array - Task payload in
task.artifacts[] - Explicit
task_idfor tracking statefield for task status- A2A native support for async via task state machine
Async Response (Submitted)
Protocol Compliance Testing
Validating Your Implementation
Here’s how to test that your protocol adapter is compliant:Testing Cross-Protocol Compatibility
Implementation Checklist
When implementing AdCP support:- Task handlers return ONLY domain data (no message, context_id, status, task_id)
- Protocol adapter adds envelope fields based on protocol requirements
- Message generation creates human-readable text from task results
- Context tracking maintains conversation state across operations
- Async support handles long-running operations appropriately
- Error mapping translates domain errors to protocol-specific formats
- Schema validation validates task responses against AdCP schemas
- Cross-protocol tests verify same task response works everywhere
Common Pitfalls
❌ Don’t Do This
✅ Do This Instead
Summary
Webhook
Task Status Webhook Payload
| Protocol | Message Location | Payload Location | Async Mechanism |
|---|---|---|---|
| MCP | content[].text | content[].resource.text | Progress notifications |
| A2A | messages[].content | task.artifacts[].content | Task state + webhooks |
/schemas/v2/core/protocol-envelope.json) provides the conceptual model. This document shows how each protocol actually serializes that model on the wire.