flutter-skill: an MCP server that drives your running app from an AI agent

What flutter-skill replaces, and for whom

The pitch is narrow and specific. Instead of writing Page Objects, XPath selectors and step definitions, you give an AI agent a channel into a running application and describe the flow in plain English. The README's example prompt is "Test the checkout flow with an empty cart, then add 3 items and complete purchase", after which the agent handles screenshots, taps, text entry, assertions and navigation on its own.

The intended user is a developer or QA engineer who already has an MCP-compatible agent open in an editor: Cursor, Claude Desktop, Windsurf, VSCode Copilot, Cline, Continue.dev or OpenClaw. The README lists config file locations for each. If your workflow does not include one of those tools, the MCP path is closed to you and only the HTTP client mode remains.

The scope claim is ten platforms from one binary: Flutter (iOS, Android, Web), React Native, Electron, Tauri, and others listed in the platform table. Each non-Flutter target has its own SDK folder under sdks/, so the "one tool" framing describes one CLI and one MCP server, not one integration artifact.

How the MCP server and the HTTP client differ

There are two distinct execution paths, and the README compares them directly in a table.

In server mode, flutter-skill speaks MCP over stdio (JSON-RPC) and auto-launches Chrome. The README states this mode exposes 253 tools, described as dynamic per page, and is aimed at IDE and agent integration.

In serve mode, flutter-skill starts an HTTP REST server that connects to an existing Chrome instance. The README puts this mode at 246 generic tools and positions it for CLI use, automation and CI/CD pipelines. The CLI client commands, such as nav, snap, tap, type, eval and screenshot, talk to that server.

The tool counts differ between modes, which is worth noticing: the HTTP surface is described as generic rather than page-aware, so an agent working through serve sees a flatter set of capabilities than one working through server. The README does not explain what the seven-tool gap contains.

One design detail stands out. The snap command returns an accessibility tree and the README claims it uses "99% fewer tokens" than a screenshot. That is a token-economy decision, and it matters because an agent that screenshots every step burns context quickly. The claim itself is the project's own and is not backed by a published method in the README.

Installing flutter-skill and running a first check

The npm package is the shortest path. The README gives this as step one of the quick start.

npm install -g flutter-skill

After that, register the MCP server with your agent. The README supplies this JSON block for any MCP-compatible client, with the exact command and argument.

{
  "mcpServers": {
    "flutter-skill": {
      "command": "flutter-skill",
      "args": ["server"]
    }
  }
}

For a Flutter app, the README's step three is two lines in main(): import package:flutter_skill/flutter_skill.dart and call FlutterSkillBinding.ensureInitialized() inside a kDebugMode check before runApp. The README also mentions a zero-config route, flutter-skill init, which it says auto-detects and patches your app.

If you would rather not touch the app, use the HTTP path. The README's example starts a server against a URL, then drives it from the CLI.

flutter-skill serve https://your-app.com
flutter-skill nav https://google.com
flutter-skill snap
flutter-skill screenshot /tmp/ss.jpg
flutter-skill tap "Login"

Run flutter-skill tools to list what the running server exposes. The README documents --port=N and --host=H flags plus the FS_PORT and FS_HOST environment variables for the serve mode. Other install routes in the README include Homebrew, Scoop, a Docker image at ghcr.io/ai-dashboad/flutter-skill, and dart pub global activate flutter_skill.

The Dockerfile shows what a headless deployment looks like

The repository ships a multi-stage Dockerfile, and reading it tells you more about the runtime than the README does. The builder stage uses ghcr.io/cirruslabs/flutter:stable, runs flutter pub get, then compiles bin/flutter_skill.dart with dart compile exe into a self-contained binary. The runtime stage is debian:bookworm-slim with only ca-certificates installed.

The result is small and runs as a non-root user named flutter_skill. The entrypoint is flutter_skill and the default command is server, so a container started with no arguments behaves as an MCP stdio server.

This is the clearest signal of intended deployment shape: the compiled binary carries no Dart or Flutter runtime, which the Dockerfile comment states explicitly. It also means the container does not include a browser. Since serve mode connects to an existing Chrome instance, a container running serve mode needs a browser reachable somewhere else, and the README does not describe that topology.

Where flutter-skill is the wrong tool

The README describes no assertion syntax, no test runner and no machine-readable result file. There is an eval command that executes JavaScript and a text command that returns visible text, so an agent can inspect state, but the pass or fail judgement lives in the model's reasoning, not in a file a CI job can gate on. For a team that needs a build to fail on a regression, that is a structural mismatch, not a missing feature.

Determinism is the second issue. An agent that explores a screen can take a different route each run. The README's own demo celebrates this: one prompt producing 28 AI-driven actions across a TikTok clone. That is exactly the behaviour you do not want when reproducing a flaky checkout bug.

The per-platform scores in the platform table, such as 188/195 for Flutter and 75/75 for React Native, Electron and Tauri, come from the project itself. The README does not describe the harness behind them, so treat them as the maintainers' own measurement rather than an independent result.

Finally, the Flutter integration requires a debug-mode binding call inside your app. The README shows it guarded by kDebugMode, which is sensible, but it still means a code change in the application under test. The HTTP mode avoids that and is the better entry point if you cannot modify the app.

flutter-skill against Playwright and Appium

The README frames the comparison as "Why not Playwright / Appium / Detox" and the difference is real. Playwright and Appium are script-driven: you write selectors and assertions, and the runner executes them the same way every time. flutter-skill is agent-driven: the model decides which element to touch next and whether the outcome looks correct.

That changes what each tool is good at. Playwright gives you reproducibility, a trace viewer and a pass/fail exit code. flutter-skill gives you coverage of screens nobody wrote a test for, and it reaches Flutter, React Native, Electron and Tauri through SDKs under sdks/ rather than through a browser-only automation model.

The token economics differ too. Playwright tests cost nothing to run beyond compute. An agent-driven run consumes model context, and the README's emphasis on the accessibility-tree snapshot over screenshots reads as an acknowledgement of that cost.

The honest framing is that these are complementary. A project could keep a Playwright or Appium suite as the gate and point an agent at flutter-skill to explore the parts of the app the suite never touches. The README does not propose that split; it presents flutter-skill as the replacement.

Maintenance, licence and what a version bump costs you

The repository is not archived, and the last push was on 2026-09-01. The most recent release is v0.9.37, published the same day, following v0.9.34 and v0.9.33 in March 2026. The version number is still below 1.0, and the README documents no stability guarantee or deprecation policy for the tool surface, which matters when an agent's prompts are written against specific tool names.

The licence is MIT, stated in the README badge and in the Dockerfile's org.opencontainers.image.licenses label. MIT permits commercial use and modification with the copyright notice retained. That is a permissive arrangement, but it says nothing about the SDKs under sdks/ or the plugins under vscode-extension/ and intellij-plugin/, and the README does not break the licence down by component. Check those directories before shipping a modified build.

Upgrade cost is concentrated in the agent side. Because interactions are natural-language prompts rather than committed test files, there is nothing to migrate when the tool changes, but there is also nothing that fails loudly when a tool is renamed. A prompt that used to work can simply produce a different sequence of actions.

Editorial conclusion

Adopt flutter-skill if your team already works inside an MCP-capable agent and wants exploratory coverage on Flutter, React Native, Electron, Tauri or the web without writing selectors. Do not adopt it as a replacement for a deterministic CI suite: the README describes no assertion language, no test runner and no result file, and the documented per-platform scores are the project's own. Before rolling it out, install it, run flutter-skill init against a throwaway app, and read docs/CLI_CLIENT.md and docs/USAGE_GUIDE.md to confirm the HTTP client commands cover the checks you actually need.

Frequently asked questions

Official sources

1. ai-dashboad/flutter-skill on GitHub
2. License: MIT
3. Project website
4. README
5. Releases