Skip to main content
Glama
KEEPEE

flutter-docs-mcp

by KEEPEE
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

flutter_mentions

Parse @flutter_mcp mentions in text and resolve each to Flutter, Dart SDK, or pub.dev docs, returning one result per mention with version and content.

Instructions

Parse every @flutter_mcp mention in a text and resolve each one to its docs.

Mention grammar (identifier forms are the same flutter_docs accepts):

  • "@flutter_mcp provider" pub.dev package, latest release

  • "@flutter_mcp provider:^6.0.0" caret constraint

  • "@flutter_mcp provider:6.1.5" exact published release

  • "@flutter_mcp dio:>=5.0.0 <6.0.0" range, space separated

  • "@flutter_mcp provider:latest" explicit latest

  • "@flutter_mcp pub:dio" / "pub:dio:5.4.0"

  • "@flutter_mcp material.AppBar" Flutter class, library given

  • "@flutter_mcp dart:async.Future" Dart SDK class

  • "@flutter_mcp Container" plain name

A version constraint is answered from pub.dev's own list of published releases: an exact pin is returned when published, a range resolves to the newest release that satisfies it (pre-releases are excluded unless the constraint asks for one), and the constraint that was requested is always reported next to the version that was resolved. A version that does not exist is reported as missing with the nearest published releases — never replaced by a different version.

Args: text: any text containing zero or more @flutter_mcp mentions. max_tokens: rough token budget for each mention's documentation payload (1 token ≈ 4 chars). Non-positive disables truncation.

Returns {"mentions": n, "max_tokens": ..., "results": [...]} with exactly one entry per mention, in document order. Each entry carries "mention" (as written), "type" (flutter_class | dart_class | pub_package | not_found | error), the resolved "identifier" and "version", and the docs payload ("content", "truncated", "tokens", "source_tokens", "max_tokens", plus "truncation" when something was cut). Failures are per-mention {"type": "not_found" | "error", "error", "suggestion"} — one bad mention never removes or duplicates another mention's entry.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYes
max_tokensNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4.1/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden and does so thoroughly: it states per-mention failure isolation, that one bad mention never removes or duplicates another entry, the version-resolution policy (exact pins honored, ranges resolve to newest satisfying release, pre-releases excluded, nonexistent versions reported as missing with nearest releases rather than substituted), and truncation behavior when max_tokens is non-positive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The response is long but front-loads the purpose, then uses clearly labeled sections (grammar, resolution semantics, args, returns) so nothing is buried. The grammar catalog is verbose yet functional, since each example documents a distinct accepted form; it stops short of padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

In the absence of an output schema, the description fully specifies the return object shape, the enum-like set of entry types, per-mention result fields, and the error/suggestion structure. An agent has everything needed to call it and interpret the result without additional fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 largely does: text is defined as any text with zero or more mentions, and max_tokens is explained as a rough token budget with a concrete conversion (1 token ≈ 4 chars) and the non-positive-disables-truncation rule, which the schema does not convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb and resource: parse every @flutter_mcp mention in text and resolve each to its docs. It is a distinct batch-resolution operation, but it never explicitly distinguishes itself from siblings like flutter_docs or pub_package; it only notes that identifier forms match flutter_docs, which mildly blurs the boundary rather than sharpening it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the extensive mention-grammar catalog, which suggests the tool is for free text containing @-mentions. However, there is no explicit when-to-use versus flutter_docs/flutter_search/pub_package guidance and no stated exclusions, leaving the agent to infer the routing decision.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools