Multiple DTD tools fail with misleading SDK version error

[goodbbai]

When using the dart_mcp, several tools that interact with a running application fail with the following error message:

A Dart SDK of version 3.9.0-163.0.dev or greater is required to connect to Dart and Flutter applications.

This error is misleading, as the Dart SDK version being used is higher than the required version.

Affected Tools

The following tools have been confirmed to be affected by this issue:

• get_widget_tree
• get_runtime_errors
• hot_reload
• get_selected_widget
• set_widget_selection_mode

Root Cause Analysis

The root cause of this issue appears to be a bug in the _listenForServices function in pkgs/dart_mcp_server/lib/src/mixins/dtd.dart. The code that checks for the ConnectedApp service is wrapped in a try-catch block that silently ignores any errors:

    try {
      final registeredServices = await dtd.getRegisteredServices();
      if (registeredServices.dtdServices.contains(
        '${ConnectedAppServiceConstants.serviceName}.${ConnectedAppServiceConstants.getVmServices}',
      )) {
        _connectedAppServiceIsSupported = true;
      }
    } catch (_) {}

If dtd.getRegisteredServices() throws an exception, it is caught silently, and the _connectedAppServiceIsSupported flag is not set to true. This leads to the misleading error message about the SDK version for all tools that rely on this flag.

Steps to Reproduce

1. Connect to the Dart Tooling Daemon using the connect_dart_tooling_daemon tool.
2. Call any of the affected tools listed above.

Expected Behavior

The tools should execute successfully.

Actual Behavior

The tools fail with a misleading error message about the SDK version.

Environment

• Flutter Version: Flutter 3.35.0-0.1.pre
• Dart Version: Dart 3.9.0 (build 3.9.0-333.2.beta)
• Operating System: macOS 15.5 24F74 darwin-arm64

[goodbbai]

someone who has the same issue.

flutter/flutter#173041

[lukemmtt]

someone who has the same issue: flutter/flutter#173041

The OP of that issue (@theniceboy) ended up filing an issue in this repo as well: #255.

I've observed this same problem.

As for the 'root cause' assessment here, while I agree that the error message is misleading and should be fixed (i.e. to use more generic language and suggest multiple possible causes rather than blaming the SDK version), I don't agree that the error message or its handling are the root cause here, nor would I expect resolving the error message logic to help us get to the bottom of it.

Rather, it would seem that something is causing a genuine DTD registration pr communication error of some kind.

[lukemmtt]

Update: After rebooting, I no longer get the version-related error message.

Instead, now I'm getting a different error message that says No active debug session to take a screenshot.

Environment:

• MacBook Pro M4
• Flutter Version: Flutter 3.35.0-0.1.pre AND Flutter 3.35.0-0.0.pre
• Dart Version: Dart 3.9.0 (build 3.9.0-333.2.beta)
• To be clear, I am new to the dart mcp server—I set it up yesterday, and I have not gotten the DTD tools to work at all.

Repro steps:

1. Run app, in debug mode, on either macOS or iPhone simulator, from Android Studio or terminal.
2. Get the DTD URI one of the following ways (all yield the same URI):

• Go to Android Studio and go to Help > Find Action... > Dart: Copy DTD Uri to Clipboard
• Run ps aux | grep "dtd-uri=" | grep -o 'ws://[^[:space:]]*' | head -1
• Or pass the --print-dtd flag when running from the terminal

3. Start a new Claude Code or Cursor session, and connect to the DTD using the DTD URI:

• No issues here; Connection succeeded.

4. Try to use any of the DTD tools like get_runtime_errors

• Before, I was seeing: A Dart SDK of version 3.9.0-163.0.dev or greater is required to connect to Dart and Flutter applications.
• Now, I see: Error: No active debug session to take a screenshot

[goodbbai]

Update: After rebooting, I no longer get the version-related error message.

Instead, now I'm getting a different error message that says No active debug session to take a screenshot.

In my case, the issue persists even after rebooting and reinstalling Flutter and Dart.

> can you list the widget tree only using "dart" mcp? you can connect to it via ws://127.0.0.1:52334/9AbtiopPJhk=/ws

⏺ I'll connect to the Dart Tooling Daemon and retrieve the widget tree for you.

⏺ dart - Connect to DTD (MCP)(uri: "ws://127.0.0.1:52334/9AbtiopPJhk=/ws")
  ⎿  Connection succeeded

⏺ Now let me get the widget tree:
  ⎿  Error: A Dart SDK of version 3.9.0-163.0.dev or greater is required to connect to Dart and Flutter applications.

When it comes to your mention,

As for the 'root cause' assessment here, while I agree that the error message is misleading and should be fixed (i.e. to use more generic language and suggest multiple possible causes rather than blaming the SDK version), I don't agree that the error message or its handling are the root cause here, nor would I expect resolving the error message logic to help us get to the bottom of it.

I completely agree with you that the error message itself isn't the root cause.
however, wouldn't it be beneficial to expose the specific error that occurs within that try block? That would significantly aid in debugging and pinpointing potential connection issues.

[lukemmtt]

@goodbbai Great thought, and for sure, I don't mean to dismiss how helpful such an error message could be. In fact, after my last message, I spent a ton of time troubleshooting this today, all to reveal.... not a whole lot, unfortunately.

I built the server locally and added debug prints and such to each of these error messages, slowly expanding them and adding more and more prints. What I discovered was a series of progressively more specific errors:

1. First, the misleading SDK version error was indeed masking the real issue
2. After fixing the silent catch block, I found that getRegisteredServices() was actually succeeding—the "ConnectedApp service" was properly registered
3. The real failure was happening in getVmServices() which consistently returns an empty list, despite having a Flutter app running in debug mode

Even with Claude Code helping me dig through the codebase and trace the execution flow, I hit a wall. The DTD connection succeeds, the service detection succeeds, but there are simply no VM services being registered with DTD.

I tested with both Flutter 3.35.0-0.0.pre and 3.35.0-0.1.pre, tried launching from terminal/Android Studio/Cursor, killed and restarted DTD processes, manually specified DTD URIs—nothing worked. The getVmServices() call simply returns an empty array every time.

What's most puzzling is that this tool has presumably been working for many developers over the past weeks/months, so I can only presume that you and I are doing something fundamentally wrong, or there's some configuration/environment factor I'm missing. I hesitated to share this troubleshooting saga because I'm fully expecting one of the maintainers to pop in here and drop a one-liner saying "just enable X" and all this will be moot. But I figured I'd share it since you asked.

All in all, after a full day of debugging, I'm at a loss as to what the root cause is here. You can look at some of my messy commits here if you're curious.

[goodbbai]

Thanks for digging into this! Since I'm pretty new to Flutter and Dart, I figured there must be something I'm missing. And, I actually noticed the same thing you mentioned—no VM services—when I was checking my Claude Code output.

What's most puzzling is that this tool has presumably been working for many developers over the past weeks/months, so I can only presume that you and I are doing something fundamentally wrong, or there's some configuration/environment factor I'm missing. I hesitated to share this troubleshooting saga because I'm fully expecting one of the maintainers to pop in here and drop a one-liner saying "just enable X" and all this will be moot. But I figured I'd share it since you asked.

Yeah, I'm really hoping for that too! It'd be great if a maintainer could just drop in with a quick fix so we don't keep spinning our wheels on this.

[jakemac53]

Thanks for all the work diagnosing this so far all!

Note that the connected app service requires the tools to actually register the connected apps. AFAIK, only the Dart-Code extension actually does this today.

This means that it won't work yet in Android studio, or using --print-dtd from the command line.

Obviously, this is less than ideal, but it is the current state of things.

flutter/flutter-intellij#8261 is the Android Studio/Intellij issue.

cc @bkonyi is this on your radar at all for the command line tools?

[jakemac53]

Also, we certainly should work on better error output.

I can't personally work on this at the moment because I am currently working on a bug bash sprint for Gemini CLI, so contributions would be welcome!

[lukemmtt]

Thanks for the info @jakemac53! I suppose that's the missing piece then...

If this is the case—that the Dart MCP server relies on the Dart-Code extension for DTD-dependent tools—then I feel this is essential to emphasize more strongly in the documentation. That extension is currently mentioned only once in the setup docs, solely in the context of the instructions for GitHub Copilot in VS Code which seemed irrelevant.

To be clear, I tested in Cursor (which of course is a VSCode fork)—but the Cursor instructions make no mention of a Dart-Code extension requirement; is the Dart-Code extension (and the similar VScode directive to add "dart.mcpServer": true to the user settings JSON) required in Cursor as well? I had the Dart-Code extension installed, but it may have been outdated—and I definitely didn't change my user settings json.

All that said, I certainly understand this tool is still pre-release—I don't mean to just come here and complain. I'm excited for what's to come. I just wish to help others avoid the situation I've encountered.

Thanks again for the insights 🙏🏻