Build a Dart ADK Agent and MCP Server
Dart developers do not need a Python or Node.js service just to experiment with agents and Model C...
For further actions, you may consider blocking this person and/or reporting abuse
The process-local map is also a security boundary, not only a scaling constraint. In this shape,
sessionIdis effectively a bearer capability carried in a URL; URLs are routinely copied into access logs and traces, so randomness alone should not authorize a POST to an existing SSE channel.Before replacing the greeting with a real tool, I would bind each session to an authenticated principal and client identity, apply a short idle and absolute TTL, delete it on disconnect, cap sessions and in-flight calls per principal, and keep the query string out of logs. The POST handler should reject a valid session ID presented by the wrong principal even if the ID leaked.
Useful endpoint tests would cover unknown, expired, foreign, replayed, and concurrently used session IDs, plus container restart between
GET /sseandPOST /messages. Those cases make the demo's boundary explicit:--max-instances 1prevents cross-instance routing, but it does not make process memory durable or a session URL confidential.main caveat is that is not an official ADK library. I have no idea if or when an official Dart ADK will be released. If an official one hits the repos then the plan is to rework the article
Spot on. That sessionId leakage is exactly a Mechanical layer failure. It doesn't matter how good your Semantic LLM reasoning is if the transport layer hands a valid session to the wrong principal. Your suggestion to bind sessions to authenticated identities is the only safe way to cross that boundary.
The useful thing about pairing an agent with MCP is that it forces the integration boundary to become explicit. The server is not just plumbing; it is where permissions, tool shape, failure behavior, and auditability can live outside the agent prompt. That separation pays off quickly.
main caveat is that is not an official ADK library. I have no idea if or when an official Dart ADK will be released.
Good caveat. That is exactly the kind of detail that should be visible in the integration docs: official SDK, community library, or experimental bridge. The architecture can still be useful, but the operational risk is very different if the library is not on the official support path.
This is exactly the part I found interesting about MCP.
One additional lesson from building agent tooling: making the boundary explicit solves where the checks can happen, but not automatically whether the final conclusion is correct.
I tend to separate three layers:
The dangerous failures often happen between the second and third layer. The tool can succeed, the receipt can be valid, and the agent can still draw the wrong conclusion.
For me, MCP is valuable because it gives us a clean place to keep the first two layers deterministic, leaving the model to handle only the part that actually requires reasoning.
I didn't want to dig too deep as the ADK is unofficial. I found it as a Dart library. I don't know the official rollouts so a fully supported version from Google may be in the works.
Totally understandable. The library status aside, the architectural pattern you demonstrated is solid. It’s exactly that clean boundary (that alexshev mentioned above) that makes testing the mechanical vs semantic layers possible. Thanks for putting the sample together, it's a great starting point for the Dart ecosystem.
Nice writeup — the explicit separation between the ADK agent layer and the MCP transport is the part worth paying attention to.
Building on Mikhail's three-layer framing (mechanical / evidence / semantic): one useful extension might be treating tool schema as a first-class contract, not just the tool output. If two agents call the same tool with subtly different input shapes and get silently different results, the mechanical layer says "success" but the semantic layer drifts. MCP's JSON Schema input definitions are already there — surfacing schema diffs in test output could catch a whole class of integration failures before they reach the reasoning layer.
The process-local session limitation is a good design constraint actually — it makes the demo's boundaries honest. Looking forward to seeing how this evolves when session state moves to shared storage.
Any plans to add streamable HTTP? The MCP spec deprecated the SSE transport a while back and newer clients are drifting that way, so the endpoint shape might age faster than the unofficial ADK part does.
so far just basic proof of concept. I don't know official plans but it would seem that dart is a logical path for an official ADK
Nice to see an ADK build in Dart, the SSE plus Cloud Run path is usually where the rough edges show up. One thing I would add before this leaves the toy stage: a check on what the MCP tool actually returns, since a server can change its schema or hand back junk and the agent will keep calling it happily. Did you hit any cold-start weirdness with the MCP connection on Cloud Run?
Not directly on this one - but I have seen it on other projects. if you run with scale to 0 at some point you will get hit with a cold start penalty. Measuring that building that goes beyond just dart/MCP
Great walkthrough. I especially like that the article points out the difference between a working demo and a production-ready MCP service. The process-local session map is easy to understand for a small example, but authentication, session expiration, request validation, and protection against session-ID leakage become important as soon as the server is exposed beyond localhost.
Another useful improvement would be to add structured logging around
[tools/call](yazistil.com.tr/) requests without logging sensitive session information so developers can distinguish transport errors, tool execution failures, and incorrect model reasoning. Keeping the tool layer deterministic while leaving semantic decisions to the agent seems like a solid architecture for experimenting with MCP in Dart.