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).
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | ||
| doc_path | Yes | ||
| max_lines | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, so safety is clear. The description adds paging behavior: 'Long pages are cut off with a hint for the next offset' and that the response tells the next offset. This goes beyond annotations and informs the agent of a critical non-obvious behavior (incremental fetching).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise opening sentences that immediately convey purpose and paging hint, followed by a tightly formatted Args block. Every sentence contributes value; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (context shows output schema: true), the description covers the tool's core behavior, parameter usage, and paging workflow. An agent has everything needed to call it correctly: how to obtain the path, how to page, and what each parameter means.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. It explains doc_path with an explicit example and source ('usually obtained from search_flet_docs'), explains offset as 'Line to start from' with default and response-provided next offset, and explains max_lines as 'Maximum lines to return per call' with default. All three parameters are unambiguously documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'Fetch the Markdown documentation for a specific Flet control or topic'. Differentiates from siblings by mentioning doc_path is 'usually obtained from search_flet_docs', which implies a distinct workflow from searching. The paging mention also separates it from a one-shot fetch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends obtaining doc_path from search_flet_docs first, and instructs to 'page through' rather than request everything, which guides usage. It does not enumerate alternative tools (e.g., get_flet_example or read_flet_source), but the context is clear enough for an agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| max_chars | No | ||
| example_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, so the safety profile is covered. The description adds behavioral value beyond annotations by disclosing that the returned source is bundled with a character budget so large examples 'page gracefully', which hints at truncation or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence immediately states the tool's purpose and contents, and the Args section is compact and information-dense. Every sentence earns its place without unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists and the tool has only two simple parameters, the description covers everything needed to call it correctly: what is fetched, where the id comes from, and how the character budget behaves. No critical operational detail is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates well: example_id is explained as coming from search_flet_examples with concrete format examples, and max_chars is clarified as a total character budget for the returned source. This adds real meaning beyond the bare schema properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Fetch'), a precise resource ('full source of an official Flet example app'), and the expected contents (pyproject.toml plus Python files). It also anchors the tool to 'search_flet_examples', which distinguishes it from generic source readers and doc lookup tools among the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a workflow by saying example_id comes from search_flet_examples, but it never explicitly tells an agent when to choose this tool over alternatives like get_flet_doc or read_flet_source. There is clear use context, but no exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| error | No | |
| source | Yes | |
| flet_version | Yes | |
| package_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains that the tool reports both the version and the source location, and gives the important rationale that Flet changes faster than training data so the installed source is the only truth. This adds meaningful context beyond the readOnlyHint and destructiveHint annotations, and there is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. The core purpose is front-loaded, and the usage guidance follows immediately with a clear rationale.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only tool with an output schema, the description fully covers what the tool does, when to use it, and why it matters. Nothing essential is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is trivially complete and the description does not need to explain parameter behavior. The baseline for parameter-free tools is 4, and the description adds no unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Report which flet version the source tools read, and from where.' This clearly identifies the tool's exact function and is distinct from sibling tools that inspect, search, or verify Flet code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this first when a Flet API question matters', giving clear guidance on when to invoke it. It does not enumerate when-not-to-use conditions or alternatives, but the 'first' instruction provides strong contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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').
| Name | Required | Description | Default |
|---|---|---|---|
| package_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description adds that the tool fetches PyPI details and installation instructions, which is a useful behavioral scope but does not go beyond that. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the main purpose appears in the first sentence, and the parameter explanation follows directly. There is no fluff or redundant restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one well-documented parameter, this description covers all necessary invocation context. An output schema exists, so return-value details are already provided externally, and annotations cover the safety profile. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the full burden of explaining the sole parameter. It does so clearly: 'package_name' is the exact PyPI name, with a concrete example 'flet-audio'. This adds meaning far beyond the bare string type in the schema and is sufficient for an agent to call the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Fetch'), a specific resource (PyPI details for a Flet package), and the scope of the result ('current version, and installation instructions'). This is clearly distinct from sibling tools like list_official_packages or search_flet_ecosystem, which cover broader discovery rather than single-package details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the right usage context: call this for a specific named package, not for browsing or searching. 'The exact name of the package on PyPI' tells an agent when it has sufficient information to invoke it. However, there is no explicit mention of alternatives or when NOT to use this tool, so the guidance is implicit rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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'.
| Name | Required | Description | Default |
|---|---|---|---|
| control_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, and the description adds meaningful behavioral detail: it reads installed source, marks inherited properties, surfaces deprecation warnings, and returns full class source. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The main purpose and output contents are front-loaded, and the usage rule is embedded naturally. The Args section is minimal and directly useful. There is no filler, tautology, or restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only tool with an output schema, the description supplies all essential invocation context: what to pass, why to use it, and what the result will contain. Nothing critical is missing for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description carries the full burden for parameter understanding and succeeds. The Args block defines control_name as a public Flet class name and gives five realistic examples such as 'Button', 'TextField', and 'Page', making the schema's bare 'Control Name' title far more actionable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get the exact, current API of any Flet control straight from the installed source.' It lists concrete outputs like properties, types, defaults, events, deprecation warnings, class hierarchy, and source, which clearly separates it from sibling source-reading and documentation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit when-to-use instruction: 'ALWAYS use this before writing Flet UI code — control APIs in training data are often outdated.' This is strong contextual guidance, though it does not name alternatives or state when to prefer sibling tools like get_flet_doc or list_flet_api.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context beyond the readOnlyHint and destructiveHint annotations by clarifying that results reflect the local installed package's true flet.__all__ and that it is version-sensitive. This helps an agent trust the output as authoritative for the current environment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences: the first delivers the core scope and grouping, the second gives an actionable use case. No filler or repetition of structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, read-only annotations, and an output schema present, this description fully equips an agent to decide when to call the tool and what it will return. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so parameter semantics carry no burden. The description's category list helps set expectations for the output instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifically names the resource ('every public name in the installed flet' / 'true flet.__all__') and the grouping behavior by category. This clearly distinguishes it from narrower sibling tools like list_flet_controls or search_flet_docs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete trigger: use this tool to discover what exists in the CURRENT version before guessing control or API names. It does not explicitly name alternatives or exclusions, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is clear. The description adds useful behavioral scope by stating that this tool returns only documented controls and not the full API surface, which shapes expectations about the result set beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the core action and scope, then adds a concise pointer to the relevant sibling tool. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool with an output schema and a clear alternative named, this description is complete. It provides enough context for an agent to invoke the tool correctly and know exactly what result category to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema already covers everything. The description does not need to explain parameter semantics, and the baseline of 4 applies because there are no parameters to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Get a list of all Flet UI controls that have a documentation page.' It also distinguishes this tool from list_flet_api by explicitly contrasting documented controls with the complete programmatic API surface, so an agent can tell them apart without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use the alternative: for the complete API surface including undocumented controls, services and hooks, use list_flet_api. This gives a clear exclusion condition and names the sibling tool, leaving no ambiguity about which one to select.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is fully covered. The description adds the official-extension scope and examples, but no extra behavioral traits such as response format, pagination, or potential limitations. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences deliver the operation, examples, and usage guidance without filler. The main action is front-loaded and the supporting scope note is short and useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only listing tool with an output schema available, the description fully covers what the agent needs to decide whether to call it. The examples clarify the output style and the 'outside the core library' phrase resolves scope relative to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics for the description to explain. With no params, the baseline of 4 applies; the description cannot meaningfully add parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get a list of all official Flet extension packages.' It also gives concrete examples and explicitly scopes the tool to capabilities 'outside the core library,' which differentiates it from sibling tools targeting the core Flet API and controls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly says 'Use this to see what official extra capabilities Flet supports outside the core library,' providing explicit when-to-use context. It does not mention when not to use it or name alternative sibling tools, which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| module | Yes | ||
| symbol | No | ||
| max_lines | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and destructiveHint=false. The description adds useful behavioral detail beyond that: the tool returns actual installed source, includes numbered lines, and can extract a specific symbol. This gives the agent a clear idea of what to expect, without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded in the first sentence, followed by a compact Args section. Every element earns its place: purpose, trust level, and parameter explanations are all included without redundancy or unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and annotations cover safety, the description provides everything needed to invoke the tool correctly. It explains module addressing, optional symbol extraction, line cap behavior, and the semantic role of the tool as source-of-truth, making it effectively complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden of explaining parameters. It does so excellently: module is explained with dotted-path and relative-path examples, symbol is described as an optional class/function extraction with nested examples, and max_lines is documented with its default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Read the actual installed source of a flet module'. It also sets this tool apart from documentation retrieval by explicitly stating it is 'the ground truth when docs and training data disagree', which distinguishes it from siblings like search_flet_source and get_flet_doc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly provides a usage context: use this when docs and training data disagree, because it reads installed source rather than curated summaries. It does not explicitly name sibling alternatives or state when not to use them, but the 'ground truth' framing gives good contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| max_results | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful scope context beyond annotations: which namespaces are covered (ft.Colors.* and ft.CupertinoColors.*) and that results are guaranteed valid constants. However, it does not disclose matching behavior (e.g., substring vs exact, case sensitivity).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose and usage guidance occupy two tight, front-loaded sentences, followed by a compact Args block. The block slightly echoes the schema's default value, but since schema descriptions are empty, every line earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only search tool with an output schema present and safety carried by annotations, the description is largely complete: it defines the search scope, gives param semantics, and advises when to use it. The only notable gap is unspecified match semantics (case-insensitivity, substring behavior), which is minor for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does: 'query' is explained as 'Color name fragment' with concrete examples ('amber', 'teal', 'primary', 'error'), and 'max_results' is given as 'Maximum names to return (default 50)'. Both parameters gain meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Search valid flet color constants (ft.Colors.*, incl. shades like AMBER_500, and ft.CupertinoColors.*)'. It clearly scopes what is searched and naturally distinguishes itself from siblings like search_flet_icons, search_flet_source, and search_flet_docs without needing to name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The directive 'Use this instead of guessing color names' gives clear context for when the tool is the right choice. It does not name explicit alternatives or exclusion conditions, but the tight scope in the purpose sentence makes routing straightforward given the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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').
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds behavioral context beyond that: the tool returns the correct file path to feed into get_flet_doc, and it surfaces intent/cookbook content rather than exact API details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short, purposeful sentences plus a one-line parameter definition. The primary purpose is stated first, and the workflow guidance and source-tool distinction are both delivered without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only search tool with an output schema, the description is complete. It names the intended workflow (search first, then get_flet_doc), clarifies what docs offer versus source tools, and provides parameter guidance plus examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a 'query' property with the title 'Query' and no description, so schema coverage is effectively 0%. The description compensates by defining the parameter as 'The keyword to search for' and supplying concrete examples like 'dropdown', 'navigation', and 'layout'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search the official Flet documentation index for a specific topic or control.' It clearly states what the tool does and how it differs from source tools by saying 'Docs explain intent and cookbook patterns; use the source tools for exact APIs.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: 'Always use this first to find the correct file path before calling get_flet_doc.' It also tells the agent when not to rely on this tool—when exact APIs are needed, use source tools—so routing between siblings is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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').
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds the scope of the search (third-party, open-source community) but does not describe result format or pagination. Given the annotation coverage, the description meets a baseline but adds limited behavioral depth beyond purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus an inline parameter definition. The purpose is front-loaded, and every sentence adds value. No repetition or fluff. The Args section is efficient and directly tied to the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with one parameter and an output schema (per context signals), the description covers the core: what it does, when to use, and the parameter meaning. It does not mention any limitations (e.g., result count, network dependency), but such details are less critical given the presence of an output schema and harmless annotations. It is nearly complete for its scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It states 'query: The keyword to search for (e.g., 'calendar')', which adds a basic meaning and example. However, it does not clarify nuances like case sensitivity, wildcard support, or search syntax. For a single string parameter, this is adequate but not rich.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-resource pair: 'Search the open-source community for third-party Flet packages and components.' It explicitly differentiates from the core Flet library and implies distinction from sibling tools like search_flet_source (focused on source code) and list_official_packages (official packages). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit trigger: 'Use this when the user wants to add a feature that might not be in the core Flet library.' This gives clear contextual guidance. However, it does not name alternatives or mention when not to use it (e.g., for source search or official packages), which prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| max_results | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds beyond that: results are runnable projects (not just snippets or file paths), each result requires a follow-up fetch for full source, and it searches the official repo only. No contradiction with annotations and no dangerous hidden behavior left undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the core search action appears in the first sentence, scoping details and workflow guidance follow, and the structured Args block cleanly documents parameters. Every sentence earns its place; the example list and the learning rationale both add real signal rather than padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter, read-only search tool with an output schema, this is complete. Both parameters are documented with defaults and examples, result semantics are explained, the follow-up workflow is specified, and the return structure is left to the existing output schema. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden — and it delivers. It documents both parameters with concrete guidance: query gets keyword semantics plus five illustrative examples ('counter', 'todo', 'routing', 'drag', 'animation', 'form validation'), and max_results gets its default value stated. This fully compensates for the empty schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Search the official Flet example apps in the flet repo... by keyword.' It clearly scopes what is searched (runnable example projects, not API docs or internal source), and explicitly names the sibling follow-up (get_flet_example), distinguishing it from the other search and read siblings. The example list (counter, todo, 7guis, routing) further pins down the resource domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: 'Reading a real example is the fastest way to learn correct Flet idioms for a pattern,' and it explicitly routes the agent to the next step, 'fetch its full source with get_flet_example.' It stops short of explicitly stating when NOT to use this tool versus alternatives like search_flet_docs or search_flet_source, but the learning-idioms rationale implies the selection condition well enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| icon_set | No | material | |
| max_results | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and destructiveHint annotations, the description discloses that the tool queries the installed flet version's icon database and warns against hallucinated names. This adds useful behavior context, though it doesn't detail return formatting (output schema likely covers that).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the most critical warning ('NEVER invent icon names'), then follows with a clear Args block. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with an output schema and complete parameter documentation, this description is fully sufficient. It covers the core purpose, the critical failure mode to avoid, the data source, and all parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining each argument: query with examples, icon_set with its allowed values and default, and max_results with its default. This is exactly what the agent needs to call the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for valid flet icon names for ft.Icons.* / ft.CupertinoIcons.*, with specific examples. It also differentiates itself by noting it reads the installed flet version's icon database, making its scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong usage guidance: never invent icon names because models hallucinate them, and instead query the database. It does not explicitly name sibling alternatives, but the context makes it clear this is the authoritative tool for icon name lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| max_results | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful behavioral detail: scope is every .py file in the package, matching is case-insensitive, and results are ranked by type. This goes beyond the structured annotations and helps the agent predict behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the scope and ranking appear first, followed by use cases, then parameter details. Every sentence adds value, and there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and only two parameters, the description covers everything an agent needs to select and call it correctly: the search scope, ranking rules, parameter semantics, and intended use. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description fully carries parameter meaning. It explains the query is a case-insensitive substring with concrete examples, and it clarifies max_results as the maximum match count with default 25. This is strong compensation for the empty schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: search the installed flet source code across every .py file. It also defines the ranking (definitions first, then assignments, comments) and names the intended use (find where things are defined, which modules exist, or how a feature is implemented), clearly distinguishing it from docs/examples/icon searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly says when to use this tool: to find definitions, modules, or actual implementation details in the current version. It does not explicitly list when-not-to-use or name alternative sibling tools, but the context is sufficiently clear to route an agent appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.app(main) is ideal — main is invoked against a mock page). timeout_secs: Execution timeout for the sandbox (default 15, max 60).
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| timeout_secs | No |
| Name | Required | Description |
|---|---|---|
| checks | Yes | |
| status | Yes | |
| diagnostics | Yes | |
| duration_ms | Yes | |
| flet_version | Yes | |
| controls_verified | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the sandbox ('app launchers are neutralized, nothing opens') and the two passes, including runtime-only error examples. This meaningfully supplements the sparse readOnlyHint/destructiveHint annotations, and nothing contradicts them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The main paragraph front-loads the trigger condition and then organizes the mechanics as two numbered passes; Args are bulleted. Despite covering a nuanced tool, no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two parameters and an output schema present, the description covers the necessary invocation pattern, default timeout, and success criterion ('status == passed'). The sandboxing detail is especially important for an agent deciding whether it is safe to run arbitrary code.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description compensates by defining 'code' as complete runnable Flet app with an ideal main(page)+ft.app(main) shape and explaining how main is invoked against a mock page. It also gives timeout_secs default and max, so an agent can choose sensible values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a concrete verb and target: 'Verify Flet code against the INSTALLED flet.' Names the two-pass verification mechanism, making it unambiguous among sibling search/inspection tools. The 'ALWAYS call' phrasing reinforces its specialized role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the main use condition: 'ALWAYS call this before delivering Flet code to the user.' It goes on to instruct the agent to fix diagnostics and re-verify until passed, which is clear operational guidance. It does not mention alternatives or exclusions, but the directive is strong and sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have clearly distinct targets: source introspection, icons, colors, docs, examples, packages, and verification. The search/get/list families are well separated by their object type, though inspect_flet_control and read_flet_source both expose source-level detail and could cause minor misselection.
All tools follow a consistent snake_case verb_noun pattern (search_, get_, list_, inspect_, verify_, read_). The only minor deviation is singular/plural pairs like get_flet_doc vs search_flet_docs, but the pattern is otherwise uniform and predictable.
16 tools is slightly above the ideal 3-15 range, but the breadth matches the server's ambitious scope: source truth, docs, examples, icons/colors, package ecosystem, and code verification. Each tool has a distinct role, so the count feels justified rather than bloated.
The toolset covers the full Flet development workflow: discovering APIs (list_flet_api, list_flet_controls), inspecting exact signatures (inspect_flet_control), checking source truth (read_flet_source, search_flet_source), finding docs and examples (search_flet_docs, get_flet_doc, search_flet_examples, get_flet_example), avoiding hallucinated constants (search_flet_icons, search_flet_colors), validating code (verify_flet_code), and exploring packages (list_official_packages, search_flet_ecosystem, get_package_details). No obvious dead ends or missing operations.
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
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Nwokike/flet-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
