Skip to main content

Dart MCP: what it actually gives a coding agent

· 3 min read
Founder, DartWay

An MCP server has been built into the Dart SDK since July 2025, and only recently have people started actually using it. MCP is the protocol that lets a coding agent call a server for information or actions. For Dart that means the agent is no longer limited to the terminal — it can reach into your running app.

We connected it to Claude Code on a demo app and checked what it gives in practice.

Connecting it​

One command:

claude mcp add --transport stdio dart -- dart mcp-server --enable all

Without --enable all, half of the tools are switched off. Under the hood it goes through the Dart Tooling Daemon — the same thing DevTools uses for debugging. The next agent session starts the server and receives the list of tools.

What the agent could already do​

The analyzer, tests, dart fix, formatting, searching pub.dev. All useful, and all things an agent does without the server — through the terminal and the web. In the demo it went to search pub.dev through the tool; it would have found the package just as well without it.

What is actually new: the running app​

This is the part worth having:

  • runtime errors from the live app, straight to the agent;
  • the widget tree, as the app has it right now;
  • taps and text input through Flutter Driver — tap, enter text, wait, get an offset, take a screenshot;
  • evaluating an expression inside the running app — the agent can print a value on the spot instead of finding the place in the code and adding a print;
  • hot reload after a fix.

In the demo the agent pulled the runtime errors, found a layout overflow, fixed it and hot-reloaded — without being shown where the problem was. Without MCP it could not have seen those offsets and would have been guessing.

The obvious use is the one that scales. You have built a large app and want every screen checked. Normally you find each overflow by eye, then describe it: "in this widget, overflow". With the server the agent walks the screens itself and collects the layout errors. Or you click through yourself and the agent gathers the errors through MCP.

What it costs​

The descriptions of all 24 tools land in the context of every session and are reread on every step of the agent. A task takes anywhere from twenty to a few hundred steps, and every one of them carries the whole list — cached, but still read, and still sitting in the context the agent has to reason within.

Verdict​

For a tool that matters on the occasional layout bug, that price is paid all the time. So in DartWay it will not be on by default. We will add it to the framework as an on-demand tool — connected for a run of visual scenarios or for fixing layout bugs, and not present in everyday development sessions. Keeping it in every session is overkill.


The video version, in Russian, is on YouTube.