Can we replace the MCP to A2A with the official CLI https://github.com/a2aproject/a2a-cli ?

[aojea]

Can we replace this with the official CLI https://github.com/a2aproject/a2a-cli ?

Originally posted by @aojea in #357 (comment)

[kaisoz]

If it covers our current needs (which it does at a first glance) we should totally replace it. Will take care of it

[fer-marino]

a2a-cli builds on the same a2a-go SDK that sam-a2a-bridge already imports directly (a2aclient in cmd/sam-a2a-bridge/a2a.go), so this wouldn't be a protocol change - sam still speaks MCP externally to the agent framework, and the bridge's job of translating MCP tool calls into A2A calls to remote peers stays the same either way. It's specifically about swapping the internal A2A-client implementation from linking the SDK to shelling out to a CLI that wraps it.

Worth weighing before this lands: shelling out adds a process spawn per call, trades typed structs for stdout/stderr parsing, and means vendoring/pinning a separate binary - real costs for a sidecar in the request path, especially given the bridge already uses the SDK's native streaming (agentCardSummary.Streaming). That's only worth it if a2a-cli gives us something the SDK doesn't on its own - e.g. its transport-plugin extensibility (JSON-RPC/REST/gRPC without recompiling) or being the better-tracked reference implementation as the protocol evolves.

@kaisoz curious which of those was the motivation - happy to help if it's the transport-plugin story, since that's the one case where wrapping the CLI actually buys something the direct SDK import doesn't.

[aojea]

main motivation is avoiding to maintain more code, and offloading the work of catching up with changes to the a2aclient maintainers