A2A Playground launch: validate Agent Cards and debug agent-to-agent calls
CanAgentUse A2A Playground validates Agent Cards, checks discovery and version rules, prepares JSON-RPC and HTTP+JSON requests, and gives teams fix guidance before launch.
Share
A2A looks simple until versions enter the room. Agent Cards changed shape across releases. Discovery paths moved. Method names shifted. Transports and interfaces became more explicit. A card can look reasonable in a JSON viewer and still be wrong for the version it claims to support.
CanAgentUse now has an A2A Playground for that exact problem. It validates Agent Cards from a live URL or pasted JSON, inspects skills and interfaces, prepares version-aware request templates, and gives developers a place to test JSON-RPC or HTTP+JSON calls without building a client from scratch.
It is not an autonomous agent. It is a developer console. You choose the card, review the issues, edit the request, send the call, and inspect the response.
CanAgentUse A2A Playground is a free browser tool for validating Agent2Agent Agent Cards and manually testing A2A requests. It supports live URLs, pasted card JSON, version-aware checks, interface inspection, auth hints, raw request debugging, timelines, and recommended fixes.
Why A2A testing needs version awareness
Agent discovery is easy to describe: publish a card, let another agent find it, then talk to the advertised endpoint. The hard part is the details. A2A v0.1 used /.well-known/agent.json. Later versions moved toward /.well-known/agent-card.json. Older task methods differ from newer message methods. Required fields, modes, interfaces, and security declarations also changed.
A generic JSON validator cannot tell you enough. It may catch malformed JSON, but it will not always explain that a v0.2 card should use message/send templates, that a v0.1 card has a legacy discovery path, or that a current card needs clearer input and output modes.
The A2A Playground treats the protocol family as part of the test.
| A2A area | Why it matters |
|---|---|
| Discovery path | Different versions used different well-known card paths |
| Card shape | Required fields changed across versions |
| Methods | Legacy task send methods differ from message send methods |
| Interfaces | Declared transports must match the endpoint you test |
| Skills | Integrators need accurate names, descriptions, modes, and examples |
| Security | Auth hints and schemes need to match real endpoint behavior |
What the A2A Playground does
Live URL mode starts with an agent website or a direct Agent Card URL. The playground discovers candidate cards, fetches the selected card, detects the version family, validates the shape, normalizes interfaces, and prepares test requests for the advertised endpoint.
Card JSON mode is for drafts. Paste a card before it is public, optionally provide a base origin, and check the structure before you wire the endpoint into a public agent site.
The playground then gives you a workbench for the practical parts: request headers, auth challenges, JSON-RPC bodies, HTTP+JSON responses, streaming samples, task lookup, cancellation, raw payloads, and timeline events.
It also generates fix guidance. When a card is missing a required field, using a legacy path, advertising unclear skills, or declaring an endpoint that cannot be called, the tool should give you a concrete next step instead of a generic "invalid" label.
Use cases
Use it before launch. Publish the card to a staging origin, run live URL mode, and confirm that discovery, card validation, advertised endpoint, skills, capabilities, and auth hints all line up.
Use it while integrating with another team. When a partner says their agent supports A2A, ask for the Agent Card URL and test the declared interface. The playground makes it easier to tell whether the issue is card metadata, request shape, endpoint behavior, or authentication.
Use it for migration work. If you have an older Agent Card, the playground can show which parts belong to the version you are using and which parts need to change for newer discovery and message flows.
Use it for QA. A QA tester can paste card JSON, check raw output, run a request template, and hand engineering the timeline. That beats "the agent did not reply" by a lot.
What it shows
The A2A Playground is built around evidence. It shows the card, the normalized interpretation, and the protocol traffic side by side.
| View | What you get |
|---|---|
| Discovery | Candidate card URLs, selected source, status, redirects, and errors |
| Validation | Version-specific field checks and issue severity |
| Agent summary | Name, provider, description, URL, version, skills, modes, capabilities |
| Interface review | Preferred transport, additional interfaces, endpoint URLs, auth hints |
| Request workbench | JSON-RPC and HTTP+JSON templates with editable headers and bodies |
| Timeline | Each call, response, stream sample, warning, error, and extracted state |
| Fixes | Recommended snippets and migration guidance |
This matters because A2A debugging often happens at boundaries. One team owns the card. Another owns the agent runtime. A third owns auth. The playground gives them a common artifact to discuss.
Limits and safety boundaries
The A2A Playground does not certify complete protocol compliance. It validates practical discovery, card structure, request setup, and bounded runtime behavior, but it is not a formal certification body.
It does not create external webhooks, store credentials or transcripts server-side, use browser cookies, or silently normalize broken cards. If something is wrong, the tool should show the issue rather than hiding it.
It also will not run destructive skills automatically. You decide which request to send. If the target agent treats a request as a real task, then the task is real from that server's point of view. Use staging endpoints and test auth when skill execution can affect systems outside the playground.
Private and internal network targets are rejected by default. The tool is for public or explicitly testable A2A endpoints, not hidden services behind your local network.
Cost
The A2A Playground is free to use on CanAgentUse. There is no CanAgentUse charge for validating a card, pasting JSON, or sending a manual test request from the playground.
The target agent may still have its own costs. A request can use model tokens, queue work, call tools, trigger logs, or hit downstream services. If the agent endpoint bills for those operations, the cost belongs to the target system.
The biggest cost for most teams will be cleanup: publishing the right card path, fixing version mismatches, naming skills clearly, documenting modes, aligning auth, and making endpoint errors useful enough for integrators.
How it fits with CanAgentUse
CanAgentUse already checks agent-facing discovery signals as part of broader readiness work. The A2A Playground is the hands-on layer for Agent Cards. It helps teams move from "we published something" to "a developer can find it, understand it, call it, and debug it."
That distinction is important. A card can be present but not useful. A skill can be listed but not explained. An endpoint can be advertised but fail every realistic request. The playground gives teams a way to see those failures before customers or partner agents do.
FAQ
What is A2A Playground?
A2A Playground is a browser tool for validating Agent2Agent Agent Cards and manually testing A2A protocol requests against advertised endpoints.
Can I paste an Agent Card instead of using a live URL?
Yes. Card JSON mode lets you validate draft cards before publishing them. Live URL mode is better when you need to test discovery and endpoint behavior.
Does the playground support every A2A version?
It is version-aware and designed to handle the major differences across A2A card shapes, discovery paths, and request templates. It is still a practical testing tool, not a formal certification program.
Is A2A Playground free?
Yes. CanAgentUse does not charge for using the playground. The target agent may still charge or consume resources when you send real requests.
Share