Dart developers do not need a Python or Node.js service just to experiment with agents and Model Context Protocol (MCP) tools. This project uses adkdart for the agent and shelf for a small HTTP server that exposes an MCP-compatible greeting tool over Server-Sent Events (SSE).
Note- the Dart library is not an official ADK. An official Dart ADK has not been released as of July 2026. This approach provides an alternative to start working with agents in Dart without waiting for an official SDK.
The repository has two related examples: bin/main.dart creates an LlmAgent and registers an ADK FunctionTool. bin/server.dart starts a Shelf server with an SSE endpoint and a JSON-RPC message endpoint.
The server implements the MCP methods needed by this demo: initialize, notifications/initialized, ping, tools/list, and tools/call. The transport and JSON-RPC routing are deliberately small and live in SessionService; they are not a general-purpose MCP server implementation. Add the dependencies
adkdart is used directly by the sample agent. The repository also tracks adkmcp, while the current server keeps its MCP transport explicit in SessionService so the protocol flow is easy to inspect. Define the greeting tool
Tools also exposes an MCP tool definition with a JSON Schema input named param. Keeping formatGreeting as a plain Dart function makes the domain behavior easy to unit test. Create the ADK agent
This command initializes the agent and prints a sample tool result. It does not call a hosted model. Expose the MCP endpoints
When a client opens GET /sse, SessionService creates an in-memory session and sends an endpoint event containing a URL such as:
The client posts JSON-RPC requests to that URL. Responses arrive as message events on the original SSE connection.
It listens on port 8080 by default. Set the PORT environment variable to use another port. Connect an MCP client
Configuration keys differ between MCP clients, so check the documentation for the client you use. Once connected, call the greet tool with:
The repository includes unit tests for the greeting behavior and endpoint tests for the Shelf server:
You can run the complete build, analysis, and test sequence with: Build the container
The included multi-stage Dockerfile compiles the server to a native executable and copies it into a small scratch image:
Check the running container at http://localhost:8080/health. Deploy to Cloud Run
cloudbuild.yaml builds the image, pushes it to Container Registry, and deploys the service in us-central1:
That instance limit matters here. Active SSE transports are stored in a process-local map, so a POST request routed to another instance would not find its session. A production service should move session state to shared storage or use a transport and deployment design that does not depend on process-local routing. Authentication, origin restrictions, request validation, timeouts, and rate limiting would also need attention before exposing the service publicly.
This sample is intentionally narrow: one agent, one deterministic tool, and enough MCP handling to show the request flow. Useful next steps include replacing the greeting with real domain logic, using adkmcp transport primitives as the Dart package evolves, adding model configuration to execute the agent, and moving session state out of memory before scaling the service.