# dart_mcp_server 1.2.2

An MCP server for Dart projects, exposing various developer tools to AI models.




## Installing
```
export PUB_HOSTED_URL=https://pub.mirror.p-hatan.ir
flutter pub add dart_mcp_server
```
Published: 2026-10-27T21:04:59.171631Z
Expected archive SHA-256: 7d2d81addad52e7d66e9566ae4294c0ceed256761f6f5709fc9a1c6014c266e2

Available in cache; verification: upstream_checksum
## Direct dependencies
- args: ^2.7.0
- async: ^2.13.0
- cli_util: ^0.5.0
- collection: ^1.19.1
- dart_mcp: ^0.5.0
- dds_service_extensions: ^2.0.1
- devtools_shared: ^13.0.0
- dtd: ^4.0.0
- file: ^7.0.1
- http: ^1.3.0
- json_rpc_2: ^4.0.0
- lints: ^6.1.0
- meta: ^1.16.0
- mime: ^2.0.0
- package_config: ^2.2.0
- path: ^1.9.1
- pool: ^1.5.1
- process: ^5.0.3
- stream_channel: ^2.1.4
- unified_analytics: ^8.1.0
- vm_service: ^15.0.0
- web_socket: ^1.0.1
- yaml: ^3.1.3

## Package README (untrusted upstream documentation)
The Dart Tooling MCP Server exposes Dart and Flutter development tool actions to compatible AI-assistant clients.

## Status

WIP. This package is still experimental and is likely to evolve quickly.

## Set up your MCP client

> Note: all of the following set up instructions require Dart 3.9.0-163.0.dev or later.

<!-- Note: since many of our tools require access to the Dart Tooling Daemon, we may want
to be cautious about recommending tools where access to the Dart Tooling Daemon does not exist. -->

The Dart MCP server can work with any MCP client that supports standard I/O (stdio) as the
transport medium. To access all the features of the Dart MCP server, an MCP client must support
[Tools](https://modelcontextprotocol.io/docs/concepts/tools) and
[Resources](https://modelcontextprotocol.io/docs/concepts/resources). For the best development
experience with the Dart MCP server, an MCP client should also support
[Roots](https://modelcontextprotocol.io/docs/concepts/roots).

Here are specific instructions for some popular tools:

### Gemini CLI

To configure the [Gemini CLI](https://github.com/google-gemini/gemini-cli) to use the Dart MCP
server, edit the `.gemini/settings.json` file in your local project (configuration will only
apply to this project) or edit the global `~/.gemini/settings.json` file in your home directory
(configuration will apply for all projects).

```json
{
  "mcpServers": {
    "dart": {
      "command": "dart",
      "args": [
        "mcp-server"
      ]
    }
  }
}
```

For more information, see the official Gemini CLI documentation for
[setting up MCP servers](https://github.com/google-gemini/gemini-cli/blob/main/docs/tools/mcp-server.md#how-to-set-up-your-mcp-server).

### Gemini Code Assist in VS Code

> Note: this currently requires the "Insiders" channel. Follow
[instructions](https://developers.google.com/gemini-code-assist/docs/use-agentic-chat-pair-programmer#before-you-begin)
to enable this build.

[Gemini Code Assist](https://codeassist.google/)'s
[Agent mode](https://developers.google.com/gemini-code-assist/docs/use-agentic-chat-pair-programmer) integrates the Gemini CLI to provide a powerful
AI agent directly in your IDE. To configure Gemini Code Assist to use the Dart MCP
server, follow the instructions to [configure the Gemini](#gemini-cli) CLI above.

You can verify the MCP server has been configured properly by typing `/mcp` in the chat window in Agent mode.

![Gemini Code Assist list mcp tools](_docs/gca_mcp_list_tools.png "Gemini Code Assist list MCP tools")

For more information see the official Gemini Code Assist documentation for
[using agent mode](https://developers.google.com/gemini-code-assist/docs/use-agentic-chat-pair-programmer#before-you-begin).

<!-- ### Android Studio -->
<!-- TODO(https://github.com/dart-lang/ai/issues/199): once we are confident that the
Dart MCP server will work well with Android Studio's MCP support, add documentation here
for configuring the server in Android Studio. -->

### Cursor

[![Add to Cursor](https://cursor.com/deeplink/mcp-install-dark.svg)](cursor://anysphere.cursor-deeplink/mcp/install?name=dart&config=eyJ0eXBlIjoic3RkaW8iLCJjb21tYW5kIjoiZGFydCBtY3Atc2VydmVyIC0tZXhwZXJpbWVudGFsLW1jcC1zZXJ2ZXIgLS1mb3JjZS1yb290cy1mYWxsYmFjayJ9)

The easiest way to configure the Dart MCP server with Cursor is by clicking the "Add to Cursor"
button above.

Alternatively, you can configure the server manually. Go to **Cursor -> Settings -> Cursor Settings > Tools & Integrations**, and then click **"Add Custom MCP"** or **"New MCP Server"**
depending on whether you already have other MCP servers configured. Edit the `.cursor/mcp.json` file in your local project (configuration will only apply to this project) or
edit the global `~/.cursor/mcp.json` file in your home directory (configuration will apply for
all projects) to configure the Dart MCP server:

```json
{
  "mcpServers": {
    "dart": {
      "command": "dart",
      "args": [
        "mcp-server",
        "--experimental-mcp-server" // Can be removed for Dart 3.9.0 or later
      ]
    }
  }
}
```

For more information, see the official Cursor documentation for
[installing MCP servers](https://docs.cursor.com/context/model-context-protocol#installing-mcp-servers).

### GitHub Copilot in VS Code

<!-- TODO: once the dart.mcpServer setting is not hidden, we may be able
to provide a deep link to the Dart Extension Settings UI for users to
enable the server. See docs: https://code.visualstudio.com/docs/configure/settings#_settings-editor.
This may be preferable to adding the deep link button to VS Code's mcp settings. -->

> Note: requires Dart-Code VS Code extension v3.114 or later.

To configure the Dart MCP server with Copilot or any other AI agent that supports the
[VS Code MCP API](https://code.visualstudio.com/api/extension-guides/mcp), add the following
to your VS Code user settings (Command Palette > **Preferences: Open User Settings (JSON)**):
```json
"dart.mcpServer": true
```

By adding this setting, the Dart VS Code extension will register the Dart MCP Server
configuration with VS Code so that you don't have to manually configure the server.
Copilot will then automatically configure the Dart MCP server on your behalf. This is
a global setting. If you'd like the setting to apply only to a specific workspace, add
the entry to your workspace settings (Command Palette > **Preferences: Open Workspace Settings (JSON)**)
instead.

For more information, see the official VS Code documentation for
[enabling MCP support](https://code.visualstudio.com/docs/copilot/chat/mcp-servers#_enable-mcp-support-in-vs-code).

### Connecting to Applications

Often, connecting to your running application is as simple as asking your agent
to do it, you can say "connect to my flutter web app" or "connect to my web
server".

This works by discovering Dart Tooling Daemon instances on your machine, and
then discovering dart and flutter applications that are registered with those
instances. 

See the sections below for specific hints and details for flutter versus dart
apps, as well as hints about how to make this work better in multi-app
scenarios, or use fewer tokens.

#### Flutter Applications

Flutter applications are automatically registered with the Dart Tooling Daemon
when running in debug/profile mode, unless `--no-dds` is passed (the Dart
Development Service is actually what spawns DTD, so disabling that disables
DTD).

#### Dart Applications

To connect to a pure Dart application, you need to run the application with the
`--observe` flag. This will start the Dart Tooling Daemon (DTD) and register the
application with it.

#### Pass --print-dtd

Both `dart` and `flutter` support the `--print-dtd` flag to get an explicit
reference to the DTD URI for that application. This is especially useful when the
agent is spawning the process, because it can avoid having to list all available
DTD URIs and trying to pick the right one.

It is recommended to put this instruction in a RULES file so that it is always
available to the agent. For example, in a GEMINI.md file in your project:

```md
## Launching Dart and Flutter Applications

- Always pass the `--print-dtd` flag to `dart` or `flutter` when spawning an
  application.
- For `dart` applications, always pass the `--observe` flag to enable the app to
  be connected to.
- Both `--print-dtd` and `--observe` must come before the script name or path
  when spawning `dart` applications: `dart --observe --print-dtd bin/main.dart`.
```

## Tools

Not all tools are enabled by default. Use the `--enable` and `--disable` flags
to control which tools are available, by tool name or by category. For example,
to enable the tools for launching and managing Flutter apps (the
`flutter_app_lifecycle` category):

```json
{
  "mcpServers": {
    "dart": {
      "command": "dart",
      "args": [
        "mcp-server",
        "--enable",
        "flutter_app_lifecycle"
      ]
    }
  }
}
```

Enabling a category also enables any tools in that category which are disabled
by default. Disabling takes precedence over enabling at the same level, and
names take precedence over categories. Run `dart mcp-server --help` for the
full list of tool and category names.

<!-- run 'dart tool/update_readme.dart' to update -->

<!-- generated -->

| Tool Name | Title | Description | Categories | Enabled by default |
| --- | --- | --- | --- | --- |
| `analyze_files` | Analyze projects | Analyzes specific paths, or the entire project, for errors. | analysis | Yes |
| `create_project` | Create project | Creates a new Dart or Flutter project. | cli | No |
| `dart_fix` | Dart fix | Runs `dart fix --apply` for the given project roots. | cli | No |
| `dart_format` | Dart format | Runs `dart format .` for the given project roots. | cli | No |
| `dtd` | Dart Tooling Daemon | Manage live app connections to running Dart and Flutter apps using the Dart Tooling Daemon (DTD). A DTD connection is REQUIRED before listing apps or using any tool that interacts with a running app (hot reload/restart, runtime errors, widget inspector, flutter driver, vm service, etc). Workflow:<br>1. `listDtdUris`: find available DTD instances and their URIs. If you see DTD instances with a working dir that looks like a home directory, these are likely connected to an IDE and you should connect to those to find IDE launched apps.<br>2. `connect` with the chosen `uri`. All apps registered with that DTD instance are connected to automatically.<br>3. `listConnectedApps` (optional): list the apps on all connected DTD instances. This only returns apps after step 2.<br>Use `disconnect` to disconnect from a DTD instance. | dart_tooling_daemon | Yes |
| `flutter_driver_command` | Flutter Driver | Run a flutter driver command | flutter_driver | Yes |
| `get_active_location` | Get Active Editor Location | Retrieves the current active location (e.g., cursor position) in the connected editor. Requires an active DTD connection. | dart_tooling_daemon | No |
| `get_app_logs` |  | Returns the collected logs for a given flutter run process id. Can only retrieve logs started by the launch_app tool. | flutter, flutter_app_lifecycle | No |
| `get_runtime_errors` | Get runtime errors | Retrieves the most recent runtime errors that have occurred in the active Dart or Flutter application. Requires an active DTD connection. | dart_tooling_daemon | Yes |
| `hot_reload` | Hot reload | Performs a hot reload of the active Flutter application. Requires an active DTD connection, use the `dtd` tool to discover and connect to an app pro-actively (don't wait for the user to instruct you, this is a safe operation with minimal bad consequences). | flutter | Yes |
| `hot_restart` | Hot restart | Performs a hot restart of the active Flutter application. This applies the latest code changes to the running application, including changes to global const values, while resetting application state. Requires an active DTD connection. Doesn't work for Non-Flutter Dart CLI programs. | flutter | Yes |
| `launch_app` |  | Launches a Flutter application and returns its DTD URI. | flutter, flutter_app_lifecycle | No |
| `list_devices` |  | Lists available Flutter devices. | flutter, flutter_app_lifecycle, cli | No |
| `list_running_apps` |  | Returns the list of running app process IDs and associated DTD URIs for apps started by the launch_app tool. | flutter, flutter_app_lifecycle | No |
| `lsp` | Language Server Protocol | Interacts with the Dart Language Server Protocol (LSP) to provide code intelligence features like hover, signature help, and symbol resolution.<br>Commands:<br>- hover: Get hover information (docs, types) at a position. Requires: uri, line, column.<br>- signatureHelp: Get signature help at a position. Requires: uri, line, column.<br>- resolveWorkspaceSymbol: Fuzzy search for symbols by name. Requires: query. | analysis | Yes |
| `pub` | pub | Runs a pub command for the given project roots, like `dart pub get` or `flutter pub add`. | cli, package_deps | Yes |
| `pub_dev_search` | pub.dev search | Searches pub.dev for packages relevant to a given search query. The response will describe each result with its download count, package description, topics, license, and publisher. | package_deps | Yes |
| `read_package_uris` |  | Reads "package" and "package-root" scheme URIs which represent paths under Dart package dependencies. "package" URIs are always relative to the "lib" directory and "package-root" URIs are relative to the true root directory of the package. For example, the URI "package:test/test.dart" represents the path "lib/test.dart" under the "test" package. "package-root:test/example/test.dart" represents the path "example/test.dart". This API supports both reading files and listing directories. | package_deps | Yes |
| `rip_grep_packages` |  | Uses ripgrep to find patterns in package dependencies. Note that ripgrep must be installed already, see https://github.com/BurntSushi/ripgrep for instructions. | package_deps | Yes |
| `roots` |  | Manage project roots. | None | Yes |
| `run_tests` | Run tests | Run Dart or Flutter tests with an agent centric UX. ALWAYS use instead of `dart test` or `flutter test` shell commands. | cli | No |
| `stop_app` |  | Kills a running Flutter process started by the launch_app tool. | flutter, flutter_app_lifecycle | No |
| `vm_service` | VM Service | Manage and interact with VM service connections. This tool allows you to connect to an app using its VM service URI, disconnect from it, invoke VM service methods directly, or list the services that VM service clients registered on it. Connecting allows features like hot reload to work on apps not launched via DTD. | dart_tooling_daemon | Yes |
| `widget_inspector` | Widget Inspector | Interact with the Flutter widget inspector in the active Flutter application. Requires an active DTD connection. | flutter | Yes |

<!-- generated -->

## Changelog
## 1.2.2

- The `dtd` tool's `listConnectedApps` command no longer returns an error when
  connected to a DTD instance that has no running apps. It now always refreshes
  the app list from DTD and explains how to find the right app or DTD instance.
- When an app tool is called before connecting to DTD, the error now includes
  the available DTD instances and the exact `connect` call to make, and reports
  the `dtdNotConnected` failure reason instead of `noActiveDebugSession`.
- Clarify the `dtd` tool description and server instructions to make it clear
  that `listDtdUris` and `connect` must be called before other app tools.
- Connecting to a DTD instance that is already connected now succeeds and
  returns its current apps instead of returning a `dtdAlreadyConnected` error,
  and `listDtdUris` indicates which instances are already connected. This is
  common when the server is shared across multiple agent sessions.

## 1.2.1

- When the Flutter SDK cannot be found, the error now says which Dart SDK the
  server is using and where that path came from (an explicit path such as
  `--dart-sdk`, `DART_ROOT`, `DART_SDK`, or the running executable), and
  mentions `--flutter-sdk`.
- Fix the `--enable` help text, which incorrectly said that all features are
  enabled by default. Document how to enable tools that are disabled by default
  in the README.
- Require `package:unified_analytics` `^8.1.0`.

## 1.2.0

- Add a `listRegisteredServices` command to the `vm_service` tool, which lists
  the services that VM service clients registered on a running app, with their
  human readable aliases.
- The `vm_service` tool's `callMethod` command now accepts the name a service
  was registered with, and calls the namespaced method (e.g. `s1.myService`)
  for it. If more than one client registered the service, it returns an error
  listing the method names and aliases to choose from.

## 1.1.3

- Only include the `command` argument in the tool name sent to analytics when it
  is one of the commands the tool supports, and report unsupported commands as
  `noSuchCommand` failures.
- Only send the names of this server's own prompts to analytics, and report
  requests for any other prompt as `noSuchPrompt` failures.
- Sanitize the client name, client version, and agent plugin before sending them
  to analytics.

## 1.1.2

- Let the `create` tool pass the project root to the underlying CLI, and reject
  an empty `directory`.
- Reject a `create` template carrying whitespace, a non-breaking space
  included.
- Track `AGENT_PLUGIN` environment variable in analytics events.
- Add missing license headers.

## 1.1.1

- Improve server instructions and error messages to encourage agents to
  proactively connect to running applications and hot reload after changes.

## 1.1.0

- Build against the published `dart_mcp` package instead of a local path
  override.
- Create vm_service meta tool, which allows direct connections to apps via vm
  service URIs, and also handles the direct vm service method calls.
- Add additional failure reasons to tool call analytics.
- Move `SdkSupport` to `implements` instead of `on` in
  `DartToolingDaemonSupport`.
- Harden various tools against compromised agents.
- Use new analysis request that blocks until analysis is complete, instead of
  waiting for notifications, which may never come.
- Use shared logic from unified_analytics to parse the Dart version.
- Log error types for uncaught errors.

## 1.0.2

- Send a SIGKILL to the analysis server if it doesn't respond to a SIGTERM in
  time.

## 1.0.1

- Minor changes to improve pub score.

## 1.0.0

- Package is now shipped on pub instead of through the SDK. The
  `dart mcp-server` command will continue to work as an alias for
  `dart run dart_mcp_server@`.
- Support reading `DART_ROOT` environment variable to set the Dart SDK root.
- Always enable roots fallback, and merge them with client roots that are set
  (if any).
- Add a tool for making arbitrary vm service method calls to connected apps.
- Move binary to `bin/dart_mcp_server.dart` to be compatible with dart run.
- Add support for enabling analytics when running as a package based on the
  `DASH__TOOL` environment variable. Analytics will not be tracked if this is
  not set.

## 0.1.3 (Dart SDK 3.12.0)

- Add additional analytics for initialization events, and various list\* method
  calls. This will help understand how the server is being used by different
  clients, and what features clients support.
- Add a tool for running ripgrep on package dependencies.
- Add `categories` for MCP features, allowing enabling/disabling tools by
  category or name.
  - This replaces the now deprecated `--tools` and `--exclude-tool` flags, but
    both are still supported for backward compatibility. `--tools=dart` now
    becomes `--disable=flutter` and `--exclude-tool` is just an alias for
    `--disable`.
- Add `timeout` option to `launch_app`.
- Add `args` parameter to `launch_app` to support passing additional flags to
  `flutter run` (e.g. `--flavor`, `--dart-define`, `--dart-define-from-file`).
  Managed flags (`--print-dtd`, `--machine`, `--device-id`, `--target`, `-d`,
  `-t`) are blocked and must be passed via their dedicated parameters instead.
- The `read_package_uris` tool now supports resolving the `package-root:` scheme
  to read package structure beyond the `lib/` directory.
- The `read_package_uris` tool now returns flattened text and image `Content`
  payloads when traversing directories and symlinks rather than `ResourceLink`s
  or embedded resources. This has better support across all clients.
- Expose `set_frame_sync` command in the `flutter_driver` tool, allowing agents
  to disable frame synchronization for apps with continuous animations (Rive,
  Lottie, etc.) that cause `tap`/`waitFor` to time out
  ([issue #391](https://github.com/dart-lang/ai/issues/391)).
- Fix nested finder JSON serialization for Ancestor/Descendant finders in the
  `flutter_driver` tool ([issue #345](https://github.com/dart-lang/ai/issues/345)).
- Fix `analyze_files` returning false "No errors" when `paths` parameter is specified.
- Merge `get_selected_widget`, `get_widget_tree`, `set_widget_selection_mode` into `widget_inspector` tool.
- Merge `hover`, `signatureHelp`, `resolveWorkspaceSymbol` into `lsp` tool.
- Disable all tools that can easily be done on the CLI by default, as well as
  `get_active_location`. These can be re-enabled by passing `--enable cli` or
  `--enable <tool-name>`.
- Add support for auto-fixing diagnostics returned by `analyze_files`.
- Updated server instructions to encourage listing resources, using the tools to
  read and grep package contents, and to explain `package-root:` URIs.
- Disable by default the `launch_app`, and associated tools (`list_running_apps`,
  `get_app_logs`, `list_devices`, `stop_app`). These can be re-enabled by
  passing `--enable flutter_app_lifecycle` (to enable all of them) or
  `--enable <tool-name>` (to enable specific ones). Agents tend to do better just
  using the CLI to manage the app lifecycle, and it is more flexible.
- Fixed the `web_server` device for `launch_app` to return just the URI that should
  be opened in a browser, we do not get a DTD or Vm Service URI until the app is
  actually connected, which was causing timeouts.
- Compact the output of the `analyze_files` tool to reduce token usage.
- Start analysis server instances lazily, and time them out after 10 minutes of
  inactivity.
- Enable `set_semantics` command for flutter_driver.
- Add `listDtdUris` subcommand for the `dtd` tool.

## 0.1.2 (Dart SDK 3.11.0)

- Add `--tools=dart|all` argument to allow enabling only vanilla Dart tools for
  non-flutter projects.
- Include the device name and target platform in the list_devices tool.
- Fix analyze tool handling of invalid roots.
- Fix erroneous SDK version error messages when connecting to a VM Service
  instead of DTD URI.
- Add a tool for reading package: URIs. Results are returned as embedded
  resources or resource links (when reading a directory).
- Add `additionalProperties: false` to most schemas so they provide better
  errors when invoked with incorrect arguments.
- Add `DartMcpServer.samplingRequest` service extension method to send a sampling
  request over DTD.
- Fix the `timeout` parameter for the flutter_driver tool to be a String,
  matching the underlying expected type (issue #330).

## 0.1.1 (Dart SDK 3.10.0)

- Change tools that accept multiple roots to not return immediately on the first
  failure.
- Add failure reason field to analytics events so we can know why tool calls are
  failing.
- Add a flutter_driver command for executing flutter driver commands on a device.
- Allow for multiple package arguments to `pub add` and `pub remove`.
- Require dart_mcp version 0.3.1.
- Add support for the flutter_driver screenshot command.
- Change the widget tree to the full version instead of the summary. The summary
  tends to hide nested text widgets which makes it difficult to find widgets
  based on their text values.
- Add an `--exclude-tool` command line flag to exclude tools by name.
- Add the abillity to limit the output of `analyze_files` to a set of paths.
- Stop reporting non-zero exit codes from command line tools as tool errors.
- Add descriptions for pub tools, add support for `pub deps` and `pub outdated`.
- Fix a bug in hot_reload ([#290](https://github.com/dart-lang/ai/issues/290)).
- Add the `list_devices`, `launch_app`, `get_app_logs`, and `list_running_apps`
  tools for running Flutter apps.
- Add the `hot_restart` tool for restarting running Flutter apps.
- Add extra log output to failed launches, and allow AI to specify the maxLines
  of log output.
- Convert `launch_app` to use `--machine` output to capture the DTD URI.
- Remove a reference to "screenshot" for a generic error that occurs for more
  than just screenshots.
- Mark the "root" parameter for `create_project` required.

## 0.1.0 (Dart SDK 3.9.0)

- Add documentation/homepage/repository links to pub results.
- Handle relative paths under roots without trailing slashes.
- Fix executable paths for dart/flutter on windows.
- Pass the provided root instead of the resolved root for project type detection.
- Be more flexible about roots by comparing canonicalized paths.
- Create the working dir if it doesn't exist.
- Add the --platform and --empty arguments to the flutter create tool.
- Invoke dart/flutter in a more robust way.
- Remove qualifiedNames from the pub dev api search.
- Flutter/Dart create tool.
- Limit the tokens returned by the runtime errors tool/resource.
- Add RootsFallbackSupport mixin.
- Fix error handling around stream listeners.
- Add a 'pub-dev-search' mcp tool.
- Drop pubspec-parse, use yaml instead.
- Handle failing to listen to vm service streams during startup.
- Add tool for enabling/disabling the widget selector.
- Add a tool to get the active cursor location.
- Add hover tool support.
- Add a test command and project detection.
- Add signature_help tool.
- Add runtime errors resource and tool to clear errors.
- Require roots for all CLI tools.
- Require roots to be set for analyzer tools.
- Add debug logs for when DTD sees Editor.getDebugSessions get registered.
- Add tool annotations to tools.
- Implement a tool to resolve workspace symbols based on a query.
- Add a dart pub tool.
- Update analyze tool to use LSP, simplify tool.
- Add tool for getting the selected widget.
- Handle missing roots capability better.
- Add `get_widget_tree` tool.
- Add a tool for getting runtime errors.
- Add Dart CLI tool support.
- Add a hot reload tool.
- Add basic analysis support.
- Add the beginnings of a Dart tooling MCP server.
- Instruct clients to prefer MCP tools over running tools in the shell.
- Reduce output size of `run_tests` tool to save on input tokens.
- Add `--log-file` argument to log all protocol traffic to a file.
- Improve error text for failed DTD connections as well as the tool description.
- Add support for injecting an `Analytics` instance to track usage.
- Listen to the new DTD `ConnectedApp` service instead of the `Editor.DebugSessions`
  service, when available.
- Screenshot tool disabled until
  https://github.com/flutter/flutter/issues/170357 is resolved.
- Add `arg_parser.dart` public library with minimal deps to be used by the dart tool.







 
