TL;DR
Google’s Agent Development Kit has implementations in Python, Go, TypeScript, Java and Kotlin. MCP clients connect agents to tools across these languages, while A2A supports communication with remote agents. Common protocols do not imply identical features: the Kotlin documentation currently describes A2A consumption, not exposing a Kotlin agent as an A2A server.
A framework for more than one runtime
Python remains a practical choice for experimentation, but enterprise systems also run on JVM services, Go backends, browser applications and mobile devices. Google’s ADK spans five languages: Python, Go, TypeScript, Java and Kotlin. Google says each implementation is built for its own runtime and type system while sharing an architecture and open protocols. (Source : Google Cloud — One Agent Development Kit, five languages)
This matters when an agent must live near existing services. A team with a Java platform does not necessarily want a separate Python deployment solely to call a model. A browser-facing product may prefer TypeScript; an Android application has different constraints from a server. Native support reduces some integration friction, but it also means teams must examine the capabilities of each SDK rather than assume a one-to-one translation.
MCP and A2A solve different problems
Google says every ADK language includes an MCP client. In this setting, the Model Context Protocol connects an agent to tools or data exposed by an MCP server. A2A, by contrast, is used to communicate with a remote agent over HTTP. One protocol provides access to tools; the other provides a way for agents to exchange tasks and responses. (Source : Google Cloud — Shared foundation; ADK — MCP tools)
That distinction affects how a system is designed. An inventory lookup can be exposed as a narrowly scoped tool. A remote procurement agent may make several decisions and call multiple tools before returning a result. Treating the latter as a simple database function can hide latency, permission boundaries and the possibility of partial completion.
A shared wire protocol creates an interoperability opportunity, not automatic trust. Authentication, authorization, version negotiation, error handling and the schema of a result still need to be tested between the actual implementations in use.
Five SDKs, different engineering trade-offs
Google describes Python as its reference implementation, with broad integrations and evaluation tooling. Its Go SDK uses typed tool definitions and includes a graph workflow runtime. The TypeScript SDK uses schema definitions and can also run in a browser context. For Java, Google highlights JVM ecosystem integration; Kotlin uses build-time tooling and supports mobile-oriented use cases. These are product descriptions, not an independent comparison of throughput or maturity. (Source : Google Cloud — Hands-on view of each ADK)
A choice should reflect the workload. A server team may value existing deployment and tracing infrastructure over a language-level benchmark. A mobile team needs to examine model availability, local data handling, battery constraints and the actions available on the device. A browser agent also inherits the security boundaries of its runtime.
There is an organizational trade-off: language diversity can reduce the cost of fitting an agent into an existing application, but maintaining several SDKs increases the number of versions, dependencies and operational paths to support. Interoperability moves some complexity from language bridges to protocol and contract testing; it does not make complexity disappear.
The Kotlin A2A caveat
The ADK Kotlin quickstart states that Kotlin can consume a remote agent via A2A, but cannot yet expose its own agent over A2A. The Kotlin client reads A2A 1.0 agent cards and rejects cards in the older 0.3 format. The guide notes that its sample Python server can convert a 0.3-style card to the 1.0 format at startup when using a2a-sdk 1.x. (Source : ADK — Kotlin A2A quickstart)
This is exactly the kind of nuance that a statement such as “all languages speak A2A” can obscure. A client-only implementation can be useful, but it is not interchangeable with a server implementation. Even two components that claim to support the same protocol may fail to interoperate if they target incompatible versions.
A production test should therefore record the SDK versions and agent-card formats as well as whether each component can initiate a request, expose an endpoint, authenticate, stream responses and handle a failed or interrupted task.
A practical adoption checklist
Start with one low-risk use case and define a contract for inputs, outputs and errors. Test each language against the same MCP server, using the actual authentication and tool permissions intended for deployment. For A2A, test each direction separately: an agent that can call a remote peer is not necessarily able to serve as one.
Track end-to-end latency and total cost for the complete task, including network hops and retries. Inspect traces across service boundaries and ensure that task identifiers survive delegation. Finally, test revocation: when a tool or remote agent loses access, the system should fail safely rather than silently continue with stale credentials.
The result is a more realistic interpretation of the announcement. Teams have more implementation choices; parity and reliable cross-language operation remain engineering work to verify.
FAQ
Is ADK available only in Python?
No. Google lists Python, Go, TypeScript, Java and Kotlin implementations.
Are MCP and A2A interchangeable?
No. MCP connects to tools and data; A2A supports communication with remote agents.
Can the Kotlin SDK expose an A2A agent?
The cited Kotlin quickstart currently documents the consuming side only, with no support yet for exposing a Kotlin agent over A2A.
Further Reading
— The Agent Report