Ship the Dart MCP server in the Dart SDK as non-experimental

[kenzieschmoll]

This work should include any polish we believe needs to land before removing the --experimental-mcp-server flag (@jakemac53 please cross-reference any issues that you think should be addressed for this), as well as determining which tools to keep and / or remove for the non-experimental offering.

[jakemac53]

We should also decide what our strategy is going to be in terms of what we consider breaking here.

I would love to just say that we are allowed to make any change we want at any time, because in practice that should be fine. This server isn't intended to have people hard coding any calls against it, they should be dynamically created by an LLM.

But, inevitably some people might try and hard code calls to it, and then get broken if we change tool names or available tools etc.

[DanTup]

Is it possible we could leave the --experimental-mcp-server flag (and just hide it and change the default) for a little while? It'll simplify things for Dart-Code if it doesn't have to know exact versions when it can/cannot pass this flag and we can just remove it later instead.

(right now, the flag is coded into Dart-Code so it's just a single experimental bool flag in settings to enable it)

[jakemac53]

Yes, when it goes stable that flag will just be hidden, potentially forever.

[natebosch]

I would love to just say that we are allowed to make any change we want at any time, because in practice that should be fine.

We might want to promise that we won't entirely remove some high level capability of the server, anything beyond that would slow us down for no customer benefit. We should certainly not promise to maintain backwards compatibility for the specific API signatures.