test-a2a-interop
Test A2A interoperability between agents by validating Agent Card conformance, exercising all task lifecycle states, and verifying streaming and error handling. Use when verifying a new A2A server implementation before deployment, validating interoperability between two or more A2A agents, running conformance tests in CI/CD for A2A services, debugging failures in multi-agent A2A workflows, or certifying that an agent meets A2A protocol requirements for a registry.
Best use case
test-a2a-interop is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Test A2A interoperability between agents by validating Agent Card conformance, exercising all task lifecycle states, and verifying streaming and error handling. Use when verifying a new A2A server implementation before deployment, validating interoperability between two or more A2A agents, running conformance tests in CI/CD for A2A services, debugging failures in multi-agent A2A workflows, or certifying that an agent meets A2A protocol requirements for a registry.
Teams using test-a2a-interop should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/test-a2a-interop/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How test-a2a-interop Compares
| Feature / Agent | test-a2a-interop | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Test A2A interoperability between agents by validating Agent Card conformance, exercising all task lifecycle states, and verifying streaming and error handling. Use when verifying a new A2A server implementation before deployment, validating interoperability between two or more A2A agents, running conformance tests in CI/CD for A2A services, debugging failures in multi-agent A2A workflows, or certifying that an agent meets A2A protocol requirements for a registry.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
Related Guides
SKILL.md Source
# Test A2A Interoperability
Validate that an A2A agent implementation conforms to the protocol specification by testing Agent Card discovery, task lifecycle management, SSE streaming, error handling, and multi-agent communication patterns.
## When to Use
- Verifying a new A2A server implementation before deployment
- Validating interoperability between two or more A2A agents
- Running conformance tests as part of CI/CD for A2A services
- Debugging failures in multi-agent A2A workflows
- Certifying that an agent meets A2A protocol requirements for a registry
## Inputs
- **Required**: Base URL of the A2A agent under test
- **Required**: Authentication credentials (if the agent requires them)
- **Optional**: Second agent URL for bidirectional interop testing
- **Optional**: Specific skills to test (default: all skills in the Agent Card)
- **Optional**: Test timeout per task (default: 60 seconds)
- **Optional**: Output format for the conformance report (`json`, `markdown`, `junit`)
## Procedure
### Step 1: Fetch and Validate Agent Cards
1.1. Retrieve the Agent Card from the well-known endpoint:
```bash
curl -s https://agent.example.com/.well-known/agent.json -o agent-card.json
```
1.2. Validate required top-level fields:
```typescript
const requiredFields = ["name", "description", "url", "skills"];
for (const field of requiredFields) {
assert(agentCard[field] !== undefined, `Missing required field: ${field}`);
}
```
1.3. Validate each skill entry:
```typescript
for (const skill of agentCard.skills) {
assert(skill.id, "Skill missing id");
assert(skill.name, "Skill missing name");
assert(skill.description, "Skill missing description");
assert(
Array.isArray(skill.inputModes) && skill.inputModes.length > 0,
`Skill ${skill.id} missing inputModes`
);
assert(
Array.isArray(skill.outputModes) && skill.outputModes.length > 0,
`Skill ${skill.id} missing outputModes`
);
}
```
1.4. Validate authentication configuration:
- If `authentication.schemes` includes `oauth2`, verify `credentials.oauth2` has `tokenUrl`
- If `authentication.schemes` includes `apiKey`, verify `credentials.apiKey` has `headerName`
1.5. Validate capability flags are boolean values.
1.6. Record validation results in the conformance report:
```typescript
interface ConformanceResult {
test: string;
category: "agent-card" | "lifecycle" | "streaming" | "error-handling" | "interop";
status: "pass" | "fail" | "skip";
message?: string;
duration_ms?: number;
}
```
**Got:** Agent Card passes all structural validation checks.
**If fail:** Record each validation failure with the specific field and reason. Do not abort; continue testing other aspects. An invalid Agent Card is itself a test result.
### Step 2: Send Test Tasks Covering All Lifecycle States
2.1. **Test: Task submission (submitted -> working -> completed)**
Send a task that the agent should be able to handle based on its declared skills:
```typescript
const submitResult = await sendJsonRpc(agentUrl, {
jsonrpc: "2.0",
id: 1,
method: "tasks/send",
params: {
id: `test-${uuid()}`,
sessionId: `session-${uuid()}`,
message: {
role: "user",
parts: [{ type: "text", text: skillExamples[0] }],
},
},
});
assert(submitResult.result, "tasks/send should return a result");
assert(submitResult.result.id, "Result should include task ID");
assert(
["submitted", "working", "completed"].includes(submitResult.result.status.state),
`Unexpected initial state: ${submitResult.result.status.state}`
);
```
2.2. **Test: Task polling (tasks/get)**
Poll until the task reaches a terminal state:
```typescript
let task = submitResult.result;
const startTime = Date.now();
while (!["completed", "failed", "canceled"].includes(task.status.state)) {
if (Date.now() - startTime > TEST_TIMEOUT_MS) {
fail(`Task ${task.id} did not complete within ${TEST_TIMEOUT_MS}ms`);
break;
}
await sleep(1000);
const getResult = await sendJsonRpc(agentUrl, {
jsonrpc: "2.0",
id: 2,
method: "tasks/get",
params: { id: task.id },
});
task = getResult.result;
}
assert(task.status.state === "completed", `Task should complete, got: ${task.status.state}`);
```
2.3. **Test: Task cancellation**
Submit a task and immediately cancel it:
```typescript
const cancelTask = await sendJsonRpc(agentUrl, {
jsonrpc: "2.0",
id: 3,
method: "tasks/send",
params: { id: `test-cancel-${uuid()}`, sessionId: `session-${uuid()}`, message: { ... } },
});
const cancelResult = await sendJsonRpc(agentUrl, {
jsonrpc: "2.0",
id: 4,
method: "tasks/cancel",
params: { id: cancelTask.result.id },
});
assert(
cancelResult.result.status.state === "canceled",
"Canceled task should be in canceled state"
);
```
2.4. **Test: Input-required state (multi-turn)**
If any skill supports multi-turn interaction, send an ambiguous request that should trigger `input-required`, then provide the follow-up:
```typescript
// Send ambiguous request
const multiTurnTask = await sendJsonRpc(agentUrl, { ... });
// Poll until input-required or completed
// If input-required, send follow-up
if (task.status.state === "input-required") {
const followUp = await sendJsonRpc(agentUrl, {
jsonrpc: "2.0",
id: 6,
method: "tasks/send",
params: {
id: task.id,
sessionId: task.sessionId,
message: { role: "user", parts: [{ type: "text", text: "Column A and Column B" }] },
},
});
assert(
["working", "completed"].includes(followUp.result.status.state),
"Follow-up should resume task"
);
}
```
2.5. **Test: State transition history**
If the Agent Card declares `stateTransitionHistory: true`:
```typescript
const getWithHistory = await sendJsonRpc(agentUrl, {
jsonrpc: "2.0",
id: 7,
method: "tasks/get",
params: { id: completedTaskId, historyLength: 100 },
});
assert(
Array.isArray(getWithHistory.result.history),
"Task should include history array"
);
assert(
getWithHistory.result.history.length >= 2,
"History should have at least 2 entries (submitted and completed)"
);
```
**Got:** All lifecycle state transitions work correctly. Tasks complete successfully, cancel cleanly, and multi-turn interaction functions when supported.
**If fail:** Record the specific state transition that failed, the expected state, and the actual state. Include the full JSON-RPC response in the report for debugging.
### Step 3: Validate SSE Streaming Responses
3.1. Skip this step if the Agent Card declares `streaming: false`.
3.2. Send a `tasks/sendSubscribe` request and validate the SSE stream:
```typescript
const response = await fetch(`${agentUrl}/subscribe`, {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
jsonrpc: "2.0",
id: 10,
method: "tasks/sendSubscribe",
params: {
id: `test-stream-${uuid()}`,
sessionId: `session-${uuid()}`,
message: { role: "user", parts: [{ type: "text", text: "Stream test task" }] },
},
}),
});
assert(
response.headers.get("content-type")?.includes("text/event-stream"),
"Response must be text/event-stream"
);
```
3.3. Parse SSE events and validate structure:
```typescript
const events: SSEEvent[] = [];
const reader = response.body.getReader();
const decoder = new TextDecoder();
let buffer = "";
while (true) {
const { done, value } = await reader.read();
if (done) break;
buffer += decoder.decode(value, { stream: true });
// Parse SSE events from buffer
const lines = buffer.split("\n");
for (const line of lines) {
if (line.startsWith("event: ")) {
currentEvent.type = line.slice(7);
} else if (line.startsWith("data: ")) {
currentEvent.data = JSON.parse(line.slice(6));
events.push(currentEvent);
}
}
}
```
3.4. Validate the event sequence:
- First event should be a `status` event with state `submitted` or `working`
- Intermediate events may include `status` updates and `artifact` deliveries
- Final event should have `final: true` with a terminal state
- No events should arrive after the final event
3.5. Validate that SSE connection cleanup works:
- Close the connection mid-stream
- Verify the task can still be retrieved via `tasks/get`
- Verify no server errors from the premature disconnect
**Got:** SSE stream delivers correctly formatted events in the right sequence, ending with a final terminal event.
**If fail:** If SSE is advertised but the endpoint returns a non-SSE response, record as a conformance failure. If events arrive out of order, record the sequence. If the stream never terminates, record a timeout.
### Step 4: Test Error Handling and Edge Cases
4.1. **Test: Unknown method**
```typescript
const unknownMethod = await sendJsonRpc(agentUrl, {
jsonrpc: "2.0",
id: 20,
method: "tasks/nonexistent",
params: {},
});
assert(unknownMethod.error?.code === -32601, "Should return method not found");
```
4.2. **Test: Malformed JSON-RPC request**
```typescript
const malformed = await fetch(agentUrl, {
method: "POST",
headers: { "Content-Type": "application/json" },
body: '{"not": "valid jsonrpc"}',
});
const response = await malformed.json();
assert(response.error?.code === -32600, "Should return invalid request");
```
4.3. **Test: Get nonexistent task**
```typescript
const notFound = await sendJsonRpc(agentUrl, {
jsonrpc: "2.0",
id: 22,
method: "tasks/get",
params: { id: "nonexistent-task-id" },
});
assert(notFound.error, "Should return error for nonexistent task");
```
4.4. **Test: Cancel already completed task**
```typescript
const cancelCompleted = await sendJsonRpc(agentUrl, {
jsonrpc: "2.0",
id: 23,
method: "tasks/cancel",
params: { id: completedTaskId },
});
assert(cancelCompleted.error, "Should error when canceling completed task");
```
4.5. **Test: Authentication enforcement**
If authentication is configured, send a request without credentials:
```typescript
const unauthResponse = await fetch(agentUrl, {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ jsonrpc: "2.0", id: 24, method: "tasks/get", params: { id: "x" } }),
});
assert(unauthResponse.status === 401, "Should reject unauthenticated requests");
```
4.6. **Test: Agent Card is publicly accessible without auth**
```typescript
const publicCard = await fetch(`${agentUrl}/.well-known/agent.json`);
assert(publicCard.status === 200, "Agent Card should be publicly accessible");
```
**Got:** All error conditions return appropriate JSON-RPC error codes without crashing the server.
**If fail:** Record each error handling test that fails. Server crashes during error testing are critical failures that must be fixed before deployment.
### Step 5: Generate Interoperability Conformance Report
5.1. Aggregate all test results into a structured report:
```typescript
interface ConformanceReport {
agentUrl: string;
agentName: string;
agentVersion: string;
testDate: string;
summary: {
total: number;
passed: number;
failed: number;
skipped: number;
};
categories: {
agentCard: ConformanceResult[];
lifecycle: ConformanceResult[];
streaming: ConformanceResult[];
errorHandling: ConformanceResult[];
interop: ConformanceResult[];
};
conformanceLevel: "full" | "partial" | "minimal" | "non-conformant";
}
```
5.2. Calculate the conformance level:
- **full**: All tests pass, including streaming and push notifications
- **partial**: Core lifecycle tests pass, some optional features fail
- **minimal**: Agent Card valid and basic task send/get works
- **non-conformant**: Agent Card invalid or basic lifecycle broken
5.3. Generate the report in the requested format:
- **json**: Machine-readable for CI/CD integration
- **markdown**: Human-readable with pass/fail tables
- **junit**: XML format for test framework integration
5.4. Include recommendations for fixing failures:
```markdown
## Failed Tests
| Test | Category | Message | Recommendation |
|------|----------|---------|----------------|
| cancel-completed-task | error-handling | Server returned 500 | Add guard for terminal state transitions |
| sse-final-event | streaming | No final event received | Ensure SSE sends event with final:true |
```
5.5. If bidirectional testing was requested (two agents), validate:
- Agent A can discover Agent B's Agent Card
- Agent A can send a task to Agent B
- Agent B can send a task to Agent A
- Both agents handle concurrent tasks without interference
**Got:** A complete conformance report with pass/fail results, conformance level, and actionable recommendations.
**If fail:** If the report generation itself fails, output raw test results to stdout as a fallback. The test data should never be lost due to a reporting error.
## Validation
- [ ] Agent Card is fetched and structurally validated
- [ ] At least one task completes the full lifecycle (submitted -> working -> completed)
- [ ] Task cancellation works correctly
- [ ] Error responses use correct JSON-RPC error codes
- [ ] SSE streaming is tested if advertised in capabilities
- [ ] Authentication is enforced on task endpoints but not on Agent Card
- [ ] Conformance report is generated in the requested format
- [ ] Failed tests include actionable remediation guidance
- [ ] Test suite can run in CI/CD without manual intervention
## Pitfalls
- **Testing against a cold server**: Some agents take time to initialize. Add a health check or warmup request before running tests.
- **Hardcoded test data**: Use dynamic task and session IDs (UUIDs) to avoid collisions when running tests repeatedly. Never assume a specific task ID is available.
- **Ignoring timing**: Task transitions are asynchronous. Always poll with backoff rather than asserting immediate state changes.
- **SSE parsing complexity**: SSE events may span multiple chunks. Buffer incoming data and parse complete events, not raw chunks.
- **Testing only the happy path**: Error handling tests are as important as success tests. Malformed requests, invalid transitions, and auth failures must all be covered.
- **Network dependency**: Tests should be runnable against localhost for development and remote URLs for production. Parameterize the agent URL.
- **Assuming skill behavior**: The test suite validates protocol conformance, not skill correctness. Use example phrases from the Agent Card to trigger skills, but do not assert specific output content.
## Related Skills
- `design-a2a-agent-card` - design the Agent Card being tested
- `implement-a2a-server` - implement the server being tested
- `build-ci-cd-pipeline` - integrate conformance tests into CI/CD
- `troubleshoot-mcp-connection` - debugging patterns applicable to A2A connectivity
- `review-software-architecture` - architecture review for multi-agent systemsRelated Skills
write-testthat-tests
Write comprehensive testthat (edition 3) tests for R package functions. Covers test organization, expectations, fixtures, mocking, snapshot tests, parameterized tests, and achieving high coverage. Use when adding tests for new package functions, increasing test coverage for existing code, writing regression tests for bug fixes, or setting up test infrastructure for a package that lacks it.
test-team-coordination
Execute a test scenario against a team, observing coordination pattern behaviors, evaluating acceptance criteria, and generating a structured RESULT.md. Use when validating that a team's coordination pattern produces the expected behaviors during a realistic task, comparing coordination patterns on equivalent workloads, or establishing baseline performance for a team composition.
run-puzzle-tests
Run jigsawR test suite via WSL R. Supports full suite, filtered by pattern, or single file. Interprets pass/fail/skip counts and identifies failing tests. Never use `--vanilla` (renv needs `.Rprofile` to activate). Use after R source changes, after adding a puzzle type or feature, before commits, or when debugging a specific failure.
run-ab-test-models
Design and execute A/B tests for ML models in production using traffic splitting, statistical significance testing, and canary/shadow deployment. Measure performance differences and make data-driven rollout decisions. Use to validate a new model before full rollout, compare candidate models from different algorithms, measure business metric impact of model changes, or meet regulatory gradual rollout requirements.
skill-name-here
One to three sentences describing what this skill accomplishes, followed by key activation triggers. This field is the primary mechanism agents use to decide whether to activate the skill — it is read during discovery before the full body is loaded. Start with a verb. Include the most important "when to use" conditions inline. Max 1024 characters.
write-vignette
Create R package vignettes using R Markdown or Quarto. Covers vignette setup, YAML configuration, code chunk options, building and testing, and CRAN requirements for vignettes. Use when adding a Getting Started tutorial, documenting complex workflows spanning multiple functions, creating domain-specific guides, or when CRAN submission requires user-facing documentation beyond function help pages.
write-validation-documentation
Write IQ/OQ/PQ validation documentation for computerized systems in regulated environments. Covers protocols, reports, test scripts, deviation handling, and approval workflows. Use when validating R or other software for regulated use, preparing for a regulatory audit, documenting qualification of computing environments, or creating and updating validation protocols and reports for new or re-qualified systems.
write-standard-operating-procedure
Write a GxP-compliant Standard Operating Procedure (SOP). Covers regulatory SOP template structure (purpose, scope, definitions, responsibilities, procedure, references, revision history), approval workflow design, periodic review scheduling, and operational procedures for system use. Use when a new validated system requires operational procedures, when existing informal procedures need formalisation, when an audit finding cites missing procedures, when a change control triggers SOP updates, or when periodic review identifies outdated procedural content.
write-roxygen-docs
Write roxygen2 documentation for R package functions, datasets, and classes. Covers all standard tags, cross-references, examples, and generating NAMESPACE entries. Follows tidyverse documentation style. Use when adding documentation to new exported functions, documenting internal helpers or datasets, documenting S3/S4/R6 classes and methods, or fixing documentation-related R CMD check notes.
write-incident-runbook
Create structured incident runbooks with diagnostic steps, resolution procedures, escalation paths, and communication templates for effective incident response. Use when documenting response procedures for recurring alerts, standardizing incident response across an on-call rotation, reducing MTTR with clear diagnostic steps, creating training materials for new team members, or linking alert annotations directly to resolution procedures.
write-helm-chart
Create production-ready Helm charts for Kubernetes application deployment with templating, values management, chart dependencies, hooks, and testing. Covers chart structure, Go template syntax, values.yaml design, chart repositories, versioning, and best practices for maintainable and reusable charts. Use when packaging a Kubernetes application for repeatable deployments, parameterizing manifests for multiple environments, managing complex multi-component applications with dependencies, or standardizing deployment practices with versioned rollback capability across teams.
write-continue-here
Write a CONTINUE_HERE.md file capturing current session state so a fresh Claude Code session can pick up where this one left off. Covers assessing recent work, structuring the continuation file with objective, completed, in-progress, next-steps, and context sections, and verifying the file is actionable. Use when ending a session with unfinished work, handing off context between sessions, or preserving task state that git alone cannot capture.