The Flet MCP Server provides AI agents with tools to explore, search, and retrieve official Flet UI framework documentation, controls, and ecosystem packages.
list_flet_controls: Get a comprehensive list of all available Flet UI controls to discover what UI elements can be built.
search_flet_docs(query): Search the official Flet docs index by keyword (e.g., 'dropdown', 'layout') to find relevant documentation file paths.
get_flet_doc(doc_path): Fetch the full Markdown content of a specific documentation page using a file path.
list_official_packages: Retrieve all official Flet extension packages (e.g., flet-audio, flet-video).
search_flet_ecosystem(query): Search for community-built third-party Flet packages and components (e.g., 'calendar', 'auth').
get_package_details(package_name): Fetch PyPI details including the current version and installation instructions for any Flet-related package.
Flet changes faster than model training data. Controls get renamed, deprecated
and removed (ft.ElevatedButton → ft.Button, and Button(text=...) is now
Button(content=...)), properties change types, icon names get hallucinated.
The only reliable reference is the flet source code actually installed in
your environment — this server ships with flet as a dependency, gives your AI
tools to read it directly, and — uniquely — can run and verify AI-written
Flet code against that installed flet before you ever see it.
Upgrading from v0.2.x? The plain command below works again — no
--with mcp<2 --with typing_extensionsflags needed anymore. v0.2.x broke because the mcp SDK 2.0 removedmcp.server.fastmcp; v1.0.0 is built on the newMCPServerAPI and pinsmcp>=2.
uvx flet-mcp-serververify_flet_code(code) checks AI-generated Flet code against the installed
flet in two passes and reports every problem with line numbers and hints:
Static: unknown controls, properties that don't exist anymore, enum typos, deprecated classes, undefined event handlers.
Dynamic: the code runs in a sandboxed subprocess (app launchers are
neutralized — nothing opens, nothing starts) while flet's own validators
fire on every constructed control, catching errors that normally only appear
at runtime — like Slider(min=10, max=5).
{
"status": "errors",
"flet_version": "0.86.5",
"controls_verified": 6,
"diagnostics": [
{"severity": "warning", "code": "deprecated", "line": 4,
"message": "'ElevatedButton' is deprecated in flet 0.86.5.",
"hint": "Did you mean 'FilledButton'?"},
{"severity": "error", "code": "bad-kwarg", "line": 4,
"message": "'ElevatedButton' has no property 'text' in flet 0.86.5."},
{"severity": "error", "code": "runtime", "line": null,
"message": "ValueError: Slider: min (10) must be less than or equal to max (5)"}
]
}The server's instructions tell AI clients to verify before delivering and
fix-and-reverify until the report is passed — plus three ready-made prompts
(verify_flet_code_prompt, migrate_flet_prompt, build_flet_ui_prompt)
that encode the full workflow.
Related MCP server: MPC Docs Server
Verify (new in v1.0.0) — confidence that AI-written code is actually valid:
verify_flet_code(code) — static + sandboxed dynamic verification against
the installed flet, structured diagnostics with line numbers and hints.
Prompts: verify_flet_code_prompt, migrate_flet_prompt, build_flet_ui_prompt.
Resources: flet://version and flet-source://<module> (browsable installed
source, path-traversal safe).
Source of truth — reads the flet package installed alongside the server, so every answer matches the exact version your app runs:
inspect_flet_control(control_name) — every property with type, default and
origin class (inherited fields marked), on_* events, deprecation warnings,
the class hierarchy, and the full class source with per-property docstrings.
get_flet_version() — which flet version the tools are reading, and from where.
search_flet_source(query) — grep the installed flet sources; definitions
rank first.
read_flet_source(module, symbol?) — numbered source of any module, or a
single class/function extracted by AST.
list_flet_api() — the true flet.__all__ of the installed version, grouped
by category (Material / Cupertino / Core controls, Services, Components & hooks).
search_flet_icons(query, icon_set) — valid ft.Icons.* /
ft.CupertinoIcons.* names, so the AI never invents one again.
search_flet_colors(query) — valid ft.Colors.* constants, including shades
like AMBER_500.
Docs & examples — official guides and runnable apps:
search_flet_docs(query) — smart search (direct > keyword aliases > fuzzy).
get_flet_doc(doc_path, offset?, max_lines?) — Markdown of a doc page, paged
so long pages don't flood the conversation.
list_flet_controls() — every control that has a docs page.
search_flet_examples(query) — official example apps (counter, todo, 7guis,
routing, games…) straight from the flet repo, always current.
get_flet_example(example_id) — full source of an example project.
Ecosystem — packages beyond core flet:
list_official_packages() — official extensions from the monorepo (flet-audio, flet-video, …).
search_flet_ecosystem(query) — verified community packages on GitHub/PyPI.
get_package_details(package_name) — PyPI version, classification, install command.
All 16 tools, three prompts and two resources exposed by the server:
# | Tool | What it does |
1 |
| Verify AI-written Flet code against the installed flet (static + sandboxed execution with flet's own validators); line-numbered diagnostics. |
2 |
| Which flet version the tools read, and from where. |
3 |
| Exact current API of any control: properties, types, defaults, events, deprecations, full class source. |
4 |
| Ranked grep across the installed flet sources. |
5 |
| Numbered source of any flet module or a single class/function. |
6 |
| The installed flet's true |
7 |
| Valid |
8 |
| Valid |
9 |
| Search the official docs index (fuzzy + keyword aliases). |
10 |
| Paged Markdown of a doc page. |
11 |
| Controls that have documentation pages. |
12 |
| Search official example apps by keyword. |
13 |
| Full source of an official example project. |
14 |
| Official flet extension packages. |
15 |
| Verified third-party flet packages on GitHub. |
16 |
| PyPI details + install command for a package. |
Prompts: verify_flet_code_prompt(code), migrate_flet_prompt(project_summary),
build_flet_ui_prompt(spec) — guided workflows that encode the verify-first loop.
Resources: flet://version (static) and flet-source://{module} (template —
installed source, path-traversal safe).
By default the source tools read the latest flet bundled with the server. Two ways to verify against the exact version your project uses:
1. Pin the version at launch (matches uvx-style workflows):
uvx --with flet==0.86.1 flet-mcp-server2. Local Mode — point the tools at your project's virtualenv, so they read its flet (and only its flet) no matter what the server bundles:
{
"mcpServers": {
"flet-mcp-server": {
"command": "uvx",
"args": ["flet-mcp-server"],
"env": { "FLET_MCP_VENV": "/absolute/path/to/your/project/.venv" }
}
}
}Every tool response then reports e.g. [flet 0.86.5 — FLET_MCP_VENV=…/project/.venv],
and inspect_flet_control shows deprecations relative to that version.
Add this to your .vscode/mcp.json:
{
"servers": {
"flet-mcp-server": {
"command": "uvx",
"args": ["flet-mcp-server"]
}
}
}Add this to your mcp_config.json:
{
"mcpServers": {
"flet-mcp-server": {
"command": "uvx",
"args": ["flet-mcp-server"]
}
}
}Add this to your claude_desktop_config.json:
{
"mcpServers": {
"flet-mcp-server": {
"command": "uvx",
"args": ["flet-mcp-server"]
}
}
}In your IDE's MCP settings, add a new server:
Name: Flet MCP
Type: Command
Command: uvx flet-mcp-server
Add this to your settings.json file inside the context_servers object:
{
"flet": {
"command": "uvx",
"args": ["flet-mcp-server"],
"env": {}
}
}Add this to your ~/.config/opencode/opencode.json or project-level .opencode/opencode.json:
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"flet-mcp": {
"type": "local",
"command": ["uvx", "flet-mcp-server"],
"enabled": true
}
}
}Variable | Default | Purpose |
| (unset) | Read flet from this project venv instead of the bundled one (Local Mode). |
|
|
|
|
| Bind host for HTTP transports. |
|
| Bind port for HTTP transports. |
| (unset) | Authenticated GitHub API access — higher rate limits. |
|
| Docs source repo. |
|
| Docs source branch. |
|
| HTTP cache location (XDG-aware). |
Docker / remote deployments: run with FLET_MCP_TRANSPORT=streamable-http FLET_MCP_HOST=0.0.0.0 — a GET /health liveness endpoint is included.
OpenTelemetry traces are emitted automatically by the MCP SDK; configure any
standard OTEL_* environment variables to export them.
git clone https://github.com/Nwokike/flet-mcp-server.git
cd flet-mcp-server
uv sync
uv run pytest # unit tests (75)
uv run ruff check src/ tests/ scripts/ # lint
uv run python scripts/smoke_stdio.py # full MCP handshake from a fresh uvx envThe smoke script is the regression test for the v0.2.0 outage: it installs the server into a clean ephemeral environment (exactly what end users get) and verifies the handshake plus one call per tool group.
See docs/ARCHITECTURE.md for the full architecture and CHANGELOG.md for release history.
MIT
Fetch the Markdown documentation for a specific Flet control or topic, paged
to keep responses small. Long pages are cut off with a hint for the next
offset — page through instead of dumping huge docs into the conversation.
Args: doc_path: The exact path of the doc file, usually obtained from search_flet_docs (e.g., 'website/docs/controls/dropdown/index.md'). offset: Line to start from (default 0; the response tells you the next offset). max_lines: Maximum lines to return per call (default 400).
Inputs: doc_path (required), offset, max_lines. Returns: result
Fetch the full source of an official Flet example app (from search_flet_examples): pyproject.toml plus its Python files, bundled with a character budget so huge examples page gracefully.
Args: example_id: Example id from search_flet_examples (e.g., 'counter' or '7guis/flight_booker'). max_chars: Total character budget for the returned source (default 24000).
Inputs: example_id (required), max_chars. Returns: result
Report which flet version the source tools read, and from where. Call this first when a Flet API question matters — Flet changes faster than model training data, so the installed source is the only truth.
Inputs: no named parameters. Returns: error, source, flet_version, package_path
Fetch PyPI details, current version, and installation instructions for a specific Flet package.
Args: package_name: The exact name of the package on PyPI (e.g., 'flet-audio').
Inputs: package_name (required). Returns: result
Get the exact, current API of any Flet control straight from the installed source: every property with its type and default (inherited ones marked), events (on_*), deprecation warnings, the class hierarchy, and the full class source with per-property docstrings. ALWAYS use this before writing Flet UI code — control APIs in training data are often outdated.
Args: control_name: Public flet class name, e.g. 'Button', 'TextField', 'CupertinoSwitch', 'Page', 'View'.
Inputs: control_name (required). Returns: result
List every public name in the installed flet (the true flet.all), grouped by category: Material/Cupertino/Core controls, Services, Components & hooks, types. Use this to discover what exists in the CURRENT version before guessing control or API names.
Inputs: no named parameters. Returns: object
Get a list of all Flet UI controls that have a documentation page. For the complete programmatic API surface of the installed version (including undocumented controls, services and hooks), use list_flet_api.
Inputs: no named parameters. Returns: result
Get a list of all official Flet extension packages (e.g. flet-audio, flet-video). Use this to see what official extra capabilities Flet supports outside the core library.
Inputs: no named parameters. Returns: result
Read the actual installed source of a flet module (numbered lines). This is the ground truth when docs and training data disagree.
Args: module: Dotted module or path relative to the flet package, e.g. 'controls/material/button.py', 'flet.controls.page', 'controls/types'. symbol: Optional class or function to extract instead of the whole file (e.g. 'Button', 'Page', 'Button.style' or 'app'). max_lines: Line cap when reading a whole file (default 400).
Inputs: module (required), symbol, max_lines. Returns: result
Search valid flet color constants (ft.Colors., incl. shades like AMBER_500, and ft.CupertinoColors.). Use this instead of guessing color names.
Args: query: Color name fragment, e.g. 'amber', 'teal', 'primary', 'error'. max_results: Maximum names to return (default 50).
Inputs: query (required), max_results. Returns: result
Search the official Flet documentation index for a specific topic or control. Always use this first to find the correct file path before calling get_flet_doc. Docs explain intent and cookbook patterns; use the source tools for exact APIs.
Args: query: The keyword to search for (e.g., 'dropdown', 'navigation', 'layout').
Inputs: query (required). Returns: result
Search the open-source community for third-party Flet packages and components. Use this when the user wants to add a feature (e.g., 'calendar', 'table', 'auth') that might not be in the core Flet library.
Args: query: The keyword to search for (e.g., 'calendar').
Inputs: query (required). Returns: result
Search the official Flet example apps in the flet repo (counter, todo, 7guis, routing, games, declarative components, …) by keyword. Each result is a runnable project; fetch its full source with get_flet_example. Reading a real example is the fastest way to learn correct Flet idioms for a pattern.
Args: query: Keywords describing the app or pattern (e.g., 'counter', 'todo', 'routing', 'drag', 'animation', 'form validation'). max_results: Maximum results (default 5).
Inputs: query (required), max_results. Returns: result
Search valid flet icon names for ft.Icons.* / ft.CupertinoIcons.*. NEVER invent icon names — models consistently hallucinate them. This reads the icon database of the installed flet version.
Args: query: Icon name fragment, e.g. 'home', 'arrow_back', 'delete_outline'. icon_set: 'material' (ft.Icons, default) or 'cupertino' (ft.CupertinoIcons). max_results: Maximum names to return (default 50).
Inputs: query (required), icon_set, max_results. Returns: result
Search the installed flet source code (every .py file in the flet package). Class and function definitions rank first, then assignments, then comments. Use this to find where anything is defined, which modules exist, or how a feature is actually implemented in the CURRENT version.
Args: query: Case-insensitive substring, e.g. 'Snackbar', 'on_route_change', 'adaptive', 'cupertino_switch'. max_results: Maximum matches to return (default 25).
Inputs: query (required), max_results. Returns: result
Verify Flet code against the INSTALLED flet — ALWAYS call this before delivering Flet code to the user. Two passes: (1) static analysis for unknown controls, invalid constructor properties, enum typos, deprecated usage and undefined event handlers, each with line numbers and hints; (2) sandboxed execution that constructs the controls (app launchers are neutralized, nothing opens) and fires flet's own validators, catching errors that only appear at runtime (e.g. Slider(min > max)). Fix every diagnostic and re-verify until status == 'passed'.
Args: code: Complete, runnable Flet app code (a main(page) function plus ft.run(main) is ideal — main is invoked against a mock page). timeout_secs: Execution timeout for the sandbox (default 15, max 60).
Inputs: code (required), timeout_secs. Returns: checks, status, diagnostics, duration_ms, +2 more
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 16 tools
Every tool targets a distinct information source or action: verification, version, control API, installed source, docs, examples, icons, colors, packages, and ecosystem search. The search_* family is differentiated by explicit suffixes (source/docs/examples/ecosystem/icons/colors), and the two list tools explicitly state their different scopes.
Tool names consistently follow a snake_case verb_noun pattern such as verify_flet_code, search_flet_docs, get_flet_doc, and list_flet_api. Minor deviations: list_official_packages and get_package_details omit the 'flet' prefix, and get_flet_doc/get_flet_example are singular while their search counterparts are plural.
16 tools is slightly above the ideal 3-15 range, but the count is justified by the server's broad scope: code validation, API introspection, source reading, docs, examples, icons, colors, and package discovery. No tool feels redundant; each covers a distinct Flet knowledge need.
The surface covers the full workflow of writing correct Flet code: discovering controls and APIs, inspecting exact control signatures, verifying code against the installed version, looking up docs and examples, resolving icons and colors, and finding official or third-party packages. Discovery tools feed cleanly into fetch/read tools with no obvious dead ends.
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
MCP server for querying Forkast documentation
