Which integrations are available for this server?

Offers Dart language documentation, enabling AI to generate accurate Dart code with proper syntax and current API methods Provides real-time Flutter documentation and API information to AI assistants, ensuring accurate code generation with up-to-date widget information, constructor parameters, and API methods Fetches package information from pub.dev, the Dart and Flutter package repository, providing README files and documentation for over 50,000 packages on demand

Flutter MCP

Q: How do I use Flutter MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Flutter MCP show me the latest Riverpod syntax for state management" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

by adamsmaka

Overview Schema Related Servers Score Discussions

Python

Local

Flutter MCP: Give Your AI Real-Time Flutter Superpowers 🚀

A real-time MCP server providing Flutter/Dart documentation and pub.dev package info to AI assistants — supports ALL 50,000+ packages on demand.

Stop fighting with hallucinated widgets and deprecated APIs. Flutter MCP connects your AI assistant to real-time documentation, ensuring the Flutter code it generates actually works.

🎬 Demo

See it in action: From npx flutter-mcp to getting real-time Flutter documentation in 20 seconds.

Related MCP server: RTFD (Read The F*****g Docs)

The Problem: Your AI is Stuck in 2021

😡 Without Flutter MCP

// User: "How do I use Riverpod to watch a future?"

// AI generates (outdated):
final userProvider = FutureProvider((ref) async {
  return fetchUser();
});

// WRONG! Missing autoDispose, family, etc.

Result: Deprecation warnings, confused debugging, time wasted on Google

✅ With Flutter MCP

// User: "How do I use @flutter_mcp riverpod:^2.5.0 to watch a future?"

// AI generates (using v2.5.1 docs):
final userProvider = FutureProvider.autoDispose
  .family<User, String>((ref, userId) async {
    return ref.watch(apiProvider).fetchUser(userId);
});

// Correct, version-specific, actually works!

Result: Code works immediately, you ship faster

🚀 Quick Start

Installation

Get started in seconds with npm:

# One-line usage (no installation required)
npx flutter-mcp

# Or install globally
npm install -g flutter-mcp
flutter-mcp

That's it! No Python setup, no configuration, no complexity. The server automatically installs dependencies and starts running.

📢 For MCP SuperAssistant Users: Use npx flutter-mcp --transport http --port 8000 to enable HTTP transport!

Alternative Installation Methods

If you prefer using Python directly:

# Install from GitHub (PyPI package coming soon)
pip install git+https://github.com/adamsmaka/flutter-mcp.git

# Run the server
flutter-mcp-server start

For development or customization:

# Clone the repository
git clone https://github.com/adamsmaka/flutter-mcp.git
cd flutter-mcp

# Create virtual environment
python3 -m venv venv
source venv/bin/activate  # On Windows: venv\Scripts\activate

# Install in development mode
pip install -e .

# Run the server
flutter-mcp-server start

For containerized deployments:

# Docker image coming soon
# Run with Docker (once published)
# docker run -d -p 8000:8000 ghcr.io/adamsmaka/flutter-mcp:latest

# For now, use local development setup instead
pip install git+https://github.com/adamsmaka/flutter-mcp.git

# Download for your platform
curl -L https://github.com/flutter-mcp/flutter-mcp/releases/latest/flutter-mcp-macos -o flutter-mcp
chmod +x flutter-mcp
./flutter-mcp

No Python, no pip, just download and run!

Requirements

Node.js 16+ (for npm/npx)
Python 3.10+ is auto-detected and used by the npm package
That's it! Built-in SQLite caching means no external dependencies

2. Add to Your AI Assistant

Edit ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "flutter-docs": {
      "command": "npx",
      "args": ["flutter-mcp"]
    }
  }
}

Or if you installed globally:

{
  "mcpServers": {
    "flutter-docs": {
      "command": "flutter-mcp"
    }
  }
}

Restart Claude Desktop after saving. The server will automatically install dependencies on first run.

Create a .mcp.json file in your Flutter project root:

{
  "mcpServers": {
    "flutter-docs": {
      "command": "npx",
      "args": ["flutter-mcp"]
    }
  }
}

Then run Claude Code in your project directory:

cd your-flutter-project
claude

Flutter MCP will automatically provide documentation for all packages in your pubspec.yaml.

Alternative: Global npm install

If you installed globally with npm install -g flutter-mcp:

{
  "mcpServers": {
    "flutter-docs": {
      "command": "flutter-mcp"
    }
  }
}

Important: Don't use the --dangerously-skip-permissions flag when running Claude Code, as it prevents MCP servers from being loaded.

In Settings → MCP Servers, add:

{
  "flutter-docs": {
    "command": "npx",
    "args": ["flutter-mcp"]
  }
}

MCP SuperAssistant requires HTTP transport. Configure it with:

Start the server with HTTP transport:

npx flutter-mcp --transport http --port 8000

In MCP SuperAssistant, add a new server:
- Name: Flutter MCP
- URL: http://localhost:8000
- Type: HTTP MCP Server
The server will now be available in your MCP SuperAssistant client.

In your .continuerc.json:

{
  "models": [
    {
      "provider": "claude",
      "mcp_servers": {
        "flutter-docs": {
          "command": "npx",
          "args": ["flutter-mcp"]
        }
      }
    }
  ]
}

3. Start the Server (Optional for Testing)

# Default STDIO mode (for Claude Desktop)
npx flutter-mcp

# HTTP transport (for MCP SuperAssistant)
npx flutter-mcp --transport http --port 8000

# SSE transport
npx flutter-mcp --transport sse --port 8080

# Custom host binding
npx flutter-mcp --transport http --host 0.0.0.0 --port 3000

# If installed globally
flutter-mcp-server --transport http --port 8000

Transport Options:

Default (no flag) - STDIO for Claude Desktop and most MCP clients
--transport http - For HTTP-based clients like MCP SuperAssistant
--transport sse - For Server-Sent Events based clients
--port PORT - Port for HTTP/SSE transport (default: 8000)
--host HOST - Host to bind to (default: 127.0.0.1)

Note: When configured in Claude Desktop, the server starts automatically using STDIO transport.

3. Use It!

Flutter MCP now features simplified tools following Context7's successful pattern - just 2 main tools instead of 5!

🎯 New Simplified Usage (Recommended)

The AI assistant can now use Flutter MCP more intelligently:

# Universal search
"Search for Flutter animation widgets"
"Find state management packages" 
"Look for HTTP clients in pub.dev"

# Smart documentation fetching
"Show me Container widget documentation"
"Get the docs for provider package"
"Explain dart:async Future class"

💫 Natural Language Support

Your AI will automatically detect Flutter/Dart content and fetch relevant docs:

"How do I implement infinite scroll with infinite_scroll_pagination?"
"Show me dio interceptors for auth tokens"
"What's the difference between bloc and riverpod?"

🔧 Legacy Support

The @flutter_mcp mentions still work for backward compatibility:

"Explain @flutter_mcp freezed code generation"
"Show me all @flutter_mcp get_it service locator patterns"

🎯 Version-Specific Documentation (NEW!)

Get documentation for specific package versions using familiar pub.dev syntax:

# Exact versions
"Show me @flutter_mcp provider:6.0.5 breaking changes"
"How does @flutter_mcp riverpod:2.5.1 AsyncNotifier work?"

# Version ranges
"Compare @flutter_mcp dio:^5.0.0 vs @flutter_mcp dio:^4.0.0"
"What's new in @flutter_mcp bloc:>=8.0.0?"

# Special keywords
"Try @flutter_mcp get:latest experimental features"
"Is @flutter_mcp provider:stable production ready?"

See Version Specification Guide for details.

📚 Available Tools

🎯 NEW: Simplified Tools (Context7-style)

Flutter MCP now provides just 2 main tools, making it easier for AI assistants to use:

1. `flutter_search` - Universal Search

Search across Flutter/Dart documentation and pub.dev packages with intelligent ranking.

{
  "tool": "flutter_search",
  "arguments": {
    "query": "state management",
    "limit": 10  // Optional: max results (default: 10)
  }
}

Returns multiple options for the AI to choose from, including Flutter classes, Dart libraries, pub packages, and concepts.

2. `flutter_docs` - Smart Documentation Fetcher

Get documentation for any Flutter/Dart identifier with automatic type detection.

{
  "tool": "flutter_docs",
  "arguments": {
    "identifier": "Container",              // Auto-detects as Flutter widget
    "topic": "examples",                    // Optional: filter content
    "max_tokens": 10000                     // Optional: limit response size
  }
}

Supports various formats:

"Container" - Flutter widget
"material.AppBar" - Library-qualified class
"provider" - pub.dev package
"dart:async.Future" - Dart core library

3. `flutter_status` - Health Check (Optional)

Monitor service health and cache statistics.

{
  "tool": "flutter_status",
  "arguments": {}
}

📦 Legacy Tools (Deprecated but still functional)

The following tools are maintained for backward compatibility but internally use the new simplified tools:

`get_flutter_docs` (Use `flutter_docs` instead)

{
  "tool": "get_flutter_docs",
  "arguments": {
    "class_name": "Container",
    "library": "widgets"
  }
}

`get_pub_package_info` (Use `flutter_docs` instead)

{
  "tool": "get_pub_package_info",
  "arguments": {
    "package_name": "provider",
    "version": "6.0.5"
  }
}

`search_flutter_docs` (Use `flutter_search` instead)

{
  "tool": "search_flutter_docs",
  "arguments": {
    "query": "material.AppBar"
  }
}

`process_flutter_mentions` (Still functional)

{
  "tool": "process_flutter_mentions",
  "arguments": {
    "text": "I need help with @flutter_mcp riverpod state management"
  }
}

`health_check` (Use `flutter_status` instead)

{
  "tool": "health_check",
  "arguments": {}
}

🎯 Features

✨ NEW: Simplified Tools: Just 2 main tools instead of 5 - following Context7's successful pattern
📦 Real-Time Documentation: Fetches the latest docs for any pub.dev package on-demand
🎯 Version-Specific Docs: Request exact versions, ranges, or use keywords like latest/stable
🚀 Zero Configuration: Automatically detects packages from your pubspec.yaml
⚡ Lightning Fast: Intelligent caching means instant responses after first fetch
🔒 100% Private: Runs locally - your code never leaves your machine
🎨 Smart Context: Provides constructors, methods, examples, and migration guides
♾️ Unlimited Packages: Works with all 50,000+ packages on pub.dev
🤖 AI-Optimized: Token limiting and smart truncation for efficient LLM usage

💡 How It Works

Flutter MCP is a local MCP server (think of it as a "RAG sidecar" for Flutter) built on the battle-tested Python MCP SDK. It enhances your AI with real-time documentation:

graph LR
    A[Your Prompt] --> B[AI Assistant]
    B --> C{Flutter/Dart Content?}
    C -->|Yes| D[Query Flutter MCP]
    D --> E[Check Local Cache]
    E -->|Hit| F[Return Cached Docs]
    E -->|Miss| G[Fetch from pub.dev]
    G --> H[Process & Cache]
    H --> F
    F --> I[Enhanced Context]
    I --> J[AI Generates Accurate Code]
    C -->|No| J

The Magic Behind the Scenes

MCP Integration: Your AI assistant automatically detects when you're asking about Flutter/Dart packages
Smart Detection: No special syntax required - just mention package names naturally
Lightning Cache: First request fetches from pub.dev (1-2 seconds), subsequent requests are instant
Context Injection: Documentation is seamlessly added to your AI's knowledge before it responds
Privacy First: Everything runs locally - your code and queries never leave your machine

Performance Notes

⚡ First Query: 1-2 seconds (fetching from pub.dev)
🚀 Cached Queries: <50ms (from local SQLite cache)
💾 Cache Duration: 24 hours for API docs, 12 hours for packages
🧹 Auto-Cleanup: Expired entries cleaned on access

Error Handling

If documentation isn't available or a fetch fails, Flutter MCP gracefully informs your AI, preventing it from generating incorrect or hallucinated code based on missing information. Your AI will let you know it couldn't find the docs rather than guessing.

📊 What Gets Indexed

When you request a package, Flutter MCP extracts:

✅ API Documentation: Classes, methods, properties with full signatures
✅ Constructors: All parameters, named arguments, defaults
✅ Code Examples: From official docs and README files
✅ Migration Guides: Breaking changes and upgrade paths
✅ Package Metadata: Dependencies, platform support, versions

🛠️ Advanced Usage

# Run with debug logging
DEBUG=true npx flutter-mcp

# Check server status and cache info
flutter-mcp-server --help

Note: Cache is automatically managed by the server. Cached documentation expires after 24 hours (API docs) or 12 hours (packages).

For production or team use:

# Run the server (Docker image coming soon)
# docker run -d -p 8000:8000 --name flutter-mcp ghcr.io/adamsmaka/flutter-mcp:latest

# Check logs
docker logs -f flutter-mcp

🛠️ Troubleshooting

This error means the system cannot find the flutter-mcp command. Solutions:

Use npx (recommended):

{
  "mcpServers": {
    "flutter-docs": {
      "command": "npx",
      "args": ["flutter-mcp"]
    }
  }
}

Install globally first:

npm install -g flutter-mcp
# Then use:
{
  "mcpServers": {
    "flutter-docs": {
      "command": "flutter-mcp"
    }
  }
}

Check Node.js installation:

node --version  # Should be 16+
npm --version   # Should be installed

Check if Node.js 16+ is installed: node --version
Try running manually to see errors: npx flutter-mcp
The npm package will auto-install Python dependencies on first run
Check if Python 3.8+ is available: python3 --version
View detailed logs: DEBUG=true npx flutter-mcp

Some very new packages might not have documentation yet
Private packages are not supported
Try using the package name exactly as it appears on pub.dev

Different MCP clients require different transport protocols:

Claude Desktop: Uses STDIO transport (default)
- No port/URL needed
- Just use: npx flutter-mcp
MCP SuperAssistant: Requires HTTP transport
- Start with: npx flutter-mcp --transport http --port 8000
- Connect to: http://localhost:8000
Custom clients: May need SSE transport
- Start with: npx flutter-mcp --transport sse --port 8080
- SSE endpoint: http://localhost:8080/sse

If connection fails:

Verify the correct transport mode for your client
Check if the port is already in use
Try binding to all interfaces: --host 0.0.0.0
Ensure Node.js and npm are properly installed

📱 Client Configurations

Need help configuring your MCP client? We have detailed guides for:

Claude Desktop
MCP SuperAssistant
Claude Code
VS Code + Continue
Custom HTTP/SSE clients
Docker configurations

→ View all client configuration examples

🤝 Contributing

We love contributions! This is an open-source project and we welcome improvements.

→ Read our Contributing Guide

Quick Ways to Contribute

🐛 Report bugs - Open an issue
💡 Suggest features - Start a discussion
📖 Improve docs - Even fixing a typo helps!
🧪 Add tests - Help us reach 100% coverage
🌐 Add translations - Make Flutter MCP accessible globally
⭐ Star the repo - Help others discover Flutter MCP

🚀 What's New & Coming Soon

Recently Released:

✅ Simplified Tools: Reduced from 5 tools to just 2 main tools (Context7-style)
✅ Smart Detection: Auto-detects Flutter widgets, Dart classes, and pub packages
✅ Token Limiting: Default 10,000 tokens with smart truncation
✅ Topic Filtering: Focus on specific sections (examples, constructors, etc.)

On our roadmap:

📚 Stack Overflow integration for common Flutter questions
🎯 Natural language activation: "use flutter docs" pattern
🌍 Offline mode for airplane coding
🚀 Hosted service option for teams

Want to help build these features? Join us!

❤️ Spread the Word

Help other Flutter developers discover AI superpowers:

Add the badge to your project:

[![Flutter MCP](https://img.shields.io/badge/Enhanced%20by-Flutter%20MCP-blue)](https://github.com/flutter-mcp/flutter-mcp)

📄 License

🏗️ Built With

Python MCP SDK - The most popular MCP implementation (14k+ stars)
FastMCP - High-level Python framework for MCP servers
SQLite - Built-in caching with zero configuration
npm/npx - Simple one-line installation and execution
BeautifulSoup - Robust HTML parsing
httpx - Modern async HTTP client

Available Tools

8 tools

flutter_docsA

Unified tool to get Flutter/Dart documentation with smart identifier resolution.

Automatically detects the type of identifier and fetches appropriate documentation. Supports Flutter classes, Dart classes, and pub.dev packages.

Args: identifier: The identifier to look up. Examples: - "Container" (Flutter widget) - "material.AppBar" (library-qualified Flutter class) - "dart:async.Future" (Dart API) - "provider" (pub.dev package) - "pub:dio" (explicit pub.dev package) - "flutter:Container" (explicit Flutter class) topic: Optional topic filter. For classes: "constructors", "methods", "properties", "examples". For packages: "getting-started", "examples", "api", "installation" tokens: Maximum tokens for response (default: 10000, min: 1000)

Returns: Dictionary with documentation content, type, and metadata

ParametersJSON Schema

Name	Required	Description	Default
`identifier`	Yes
`topic`	No
`tokens`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

With no annotations provided, the description carries full burden. It discloses key behavioral traits: 'smart identifier resolution' that automatically detects identifier types, supports multiple documentation sources, and returns structured data. However, it lacks details on error handling, rate limits, authentication needs, or performance characteristics.

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

Conciseness5/5

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

The description is well-structured and appropriately sized. It starts with a clear purpose statement, follows with supporting capabilities, then provides detailed parameter explanations in a logical Args/Returns format. Every sentence adds value with no redundant information.

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

Completeness4/5

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

Given the tool's moderate complexity (3 parameters, smart resolution logic) and the presence of an output schema (which handles return value documentation), the description is nearly complete. It covers purpose, usage context, parameter semantics thoroughly. The main gap is lack of behavioral details like error cases or limitations, but the output schema reduces this burden.

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

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by providing comprehensive parameter semantics. It explains 'identifier' with detailed examples and type detection logic, 'topic' with specific use cases and valid values for different identifier types, and 'tokens' with default and minimum values - adding significant meaning beyond the bare schema.

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

Purpose5/5

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

The description clearly states the tool's purpose as 'get Flutter/Dart documentation with smart identifier resolution' and specifies it supports Flutter classes, Dart classes, and pub.dev packages. It distinguishes from siblings like 'flutter_search' and 'search_flutter_docs' by emphasizing unified resolution rather than search functionality.

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

Usage Guidelines4/5

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

The description provides clear context for when to use this tool (for fetching documentation with identifier resolution) and implies alternatives through sibling tool names like 'search_flutter_docs' for search operations. However, it doesn't explicitly state when not to use this tool or directly compare to alternatives.

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

flutter_searchA

Search across multiple Flutter/Dart documentation sources with unified results.

Searches Flutter classes, Dart classes, pub packages, and concepts in parallel. Returns structured results with relevance scoring and documentation hints.

Args: query: Search query (e.g., "state management", "Container", "http") limit: Maximum number of results to return (default: 10, max: 25) tokens: Maximum token limit for response (default: 5000, min: 500)

Returns: Unified search results with type classification and relevance scores

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`limit`	No
`tokens`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses behavioral traits such as parallel searching, structured results with relevance scoring, and documentation hints, but does not cover aspects like rate limits, authentication needs, or error handling. The description adds useful context but is incomplete for a tool with no annotations.

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

Conciseness5/5

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

The description is appropriately sized and front-loaded, starting with a clear purpose statement followed by details on behavior, parameters, and returns. Each sentence adds value without redundancy, and the structured format with 'Args:' and 'Returns:' sections enhances readability and efficiency.

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

Completeness4/5

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

Given the tool's complexity (search across multiple sources), no annotations, and an output schema present, the description is mostly complete. It covers purpose, behavior, parameters, and return values, but could improve by addressing usage guidelines relative to siblings or more behavioral details like performance or limitations.

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. It adds meaning by explaining each parameter's purpose (e.g., 'query' for search terms, 'limit' for maximum results, 'tokens' for response size) and provides default values and constraints (e.g., 'max: 25', 'min: 500'), which are not in the schema. However, it does not fully detail all semantic nuances, such as query formatting or token usage implications.

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

Purpose5/5

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

The description clearly states the tool's purpose with specific verbs ('Search across multiple Flutter/Dart documentation sources') and resources ('Flutter classes, Dart classes, pub packages, and concepts'), distinguishing it from siblings like 'search_flutter_docs' by emphasizing unified, parallel searching across multiple sources rather than a single documentation set.

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?

The description implies usage for searching Flutter/Dart documentation but does not explicitly state when to use this tool versus alternatives like 'search_flutter_docs' or 'flutter_docs'. It provides context about what it searches but lacks explicit guidance on exclusions or comparisons with sibling tools.

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

flutter_statusB

Check the health status of all Flutter documentation services.

Returns: Health status including individual service checks and cache statistics

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns health status including service checks and cache statistics, which gives some insight into output behavior. However, it doesn't cover important aspects like whether this is a read-only operation, potential rate limits, authentication needs, or error handling. The description adds basic context but leaves gaps for a tool with zero annotation coverage.

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 description is appropriately concise with two sentences that each serve a clear purpose: the first states the tool's function, the second describes the return format. There's no wasted text, though it could be slightly more front-loaded by integrating the return information more seamlessly.

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

Completeness4/5

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

Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description provides adequate context. It explains what the tool does and what information it returns, which complements the structured data. For a health check tool with these characteristics, the description is reasonably complete though could benefit from more behavioral details given the lack of annotations.

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?

The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the input requirements. The description appropriately doesn't discuss parameters since none exist, maintaining focus on the tool's purpose and output. This meets the baseline expectation for parameterless tools.

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 description clearly states the tool's purpose as checking health status of Flutter documentation services with a specific verb ('Check') and resource ('Flutter documentation services'). It distinguishes from some siblings like 'flutter_docs' or 'search_flutter_docs' which are about documentation content rather than health monitoring, though it doesn't explicitly differentiate from 'health_check' which might be a more general sibling.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer this over the 'health_check' sibling or other monitoring tools, nor does it specify prerequisites or exclusions. The usage context is implied as health monitoring but lacks explicit direction.

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

get_flutter_docsA

Get Flutter class documentation on-demand with optional smart truncation.

DEPRECATED: This tool is deprecated. Please use flutter_docs() instead. The new tool provides better query resolution and unified interface.

Args: class_name: Name of the Flutter class (e.g., "Container", "Scaffold") library: Flutter library (e.g., "widgets", "material", "cupertino") tokens: Maximum token limit for truncation (default: 8000, min: 500)

Returns: Dictionary with documentation content or error message

ParametersJSON Schema

Name	Required	Default
`class_name`	Yes
`library`	No	widgets
`tokens`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It mentions 'on-demand' and 'optional smart truncation,' which adds some behavioral context. However, it lacks details on error handling, rate limits, authentication needs, or what 'smart truncation' entails beyond token limits. The description doesn't contradict annotations, but it's incomplete for a tool with no annotation coverage.

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

Conciseness5/5

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

The description is well-structured and front-loaded: it starts with the core purpose, then the deprecation warning with reasoning, followed by parameter and return details in a clear format. Every sentence adds value—no redundancy or fluff—making it efficient for an agent to parse.

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

Completeness4/5

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

Given the tool's complexity (3 parameters, 0% schema coverage, no annotations, but has output schema), the description is fairly complete. It covers purpose, deprecation, parameters, and returns. The output schema handles return values, so the description doesn't need to explain them. However, it could improve by addressing behavioral aspects like error cases or usage constraints more thoroughly.

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. It adds meaningful semantics: it explains that 'class_name' is for Flutter classes like 'Container,' 'library' specifies libraries like 'widgets,' and 'tokens' defines a maximum token limit with default and min values. This goes beyond the bare schema, though it could provide more examples or constraints for parameters like 'library.'

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 description clearly states the tool's purpose: 'Get Flutter class documentation on-demand with optional smart truncation.' It specifies the verb ('Get') and resource ('Flutter class documentation'), and distinguishes it from the deprecated status. However, it doesn't explicitly differentiate from siblings like 'flutter_docs' beyond the deprecation note, which is more about replacement than functional distinction.

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

Usage Guidelines5/5

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

The description provides explicit usage guidance: it states 'DEPRECATED: This tool is deprecated. Please use flutter_docs() instead' and explains why ('better query resolution and unified interface'). This clearly indicates when not to use this tool and names the alternative, which is ideal for agent decision-making.

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

get_pub_package_infoA

Get package information from pub.dev including README content.

DEPRECATED: This tool is deprecated. Please use flutter_docs() instead with the "pub:" prefix (e.g., flutter_docs("pub:provider")).

Args: package_name: Name of the pub.dev package (e.g., "provider", "bloc", "dio") version: Optional specific version to fetch (e.g., "6.0.5", "2.5.1") tokens: Maximum token limit for response (default: 6000, min: 500)

Returns: Package information including version, description, metadata, and README

ParametersJSON Schema

Name	Required	Description	Default
`package_name`	Yes
`version`	No
`tokens`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool does (fetches package info including README), mentions a default value and minimum for the 'tokens' parameter, and specifies the return format. However, it doesn't cover potential error conditions, rate limits, or authentication requirements, which would be helpful for a tool accessing external resources.

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

Conciseness5/5

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

The description is well-structured and appropriately sized. It starts with the core purpose, immediately follows with the critical deprecation notice, then provides clear parameter documentation with examples, and ends with return value information. Every sentence serves a distinct purpose with zero wasted content.

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

Completeness4/5

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

Given that this is a deprecated tool with no annotations but with an output schema, the description provides good contextual completeness. It explains the tool's purpose, provides explicit deprecation guidance with alternatives, documents all parameters with examples, and describes the return format. The main gap is lack of behavioral details like error handling or rate limits, but the deprecation notice reduces the need for comprehensive documentation.

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?

With 0% schema description coverage, the description must compensate for the lack of parameter documentation in the schema. It successfully explains all three parameters: 'package_name' (with examples like 'provider', 'bloc'), 'version' (optional with examples), and 'tokens' (default and minimum values). This adds significant value beyond the bare schema, though it could provide more context about what 'tokens' actually controls in the response.

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

Purpose5/5

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

The description clearly states the tool's purpose: 'Get package information from pub.dev including README content.' This specifies the verb ('Get'), resource ('package information from pub.dev'), and key feature ('including README content'). It effectively distinguishes this tool from its sibling 'flutter_docs' by focusing specifically on pub.dev packages rather than general Flutter documentation.

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

Usage Guidelines5/5

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

The description provides explicit usage guidance with a clear deprecation notice: '**DEPRECATED**: This tool is deprecated. Please use flutter_docs() instead with the "pub:" prefix (e.g., flutter_docs("pub:provider")).' This tells users exactly when NOT to use this tool and provides a specific alternative with usage examples, which is ideal for tool selection.

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

health_checkA

Check the health status of all scrapers and services.

DEPRECATED: This tool is deprecated. Please use flutter_status() instead.

Returns: Health status including individual scraper checks and overall status

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what the tool does (health checks) and what it returns (health status including individual scraper checks and overall status), which adds useful context. However, it doesn't mention other behavioral traits like potential side effects, error handling, or performance characteristics, leaving some gaps.

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

Conciseness5/5

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

The description is appropriately sized and front-loaded. The first sentence states the purpose clearly, followed by a deprecation warning and return value note. Every sentence earns its place by providing essential information without waste, making it efficient for an AI agent to parse.

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

Completeness4/5

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

Given the tool's low complexity (0 parameters, no annotations) and the presence of an output schema (which handles return values), the description is mostly complete. It covers purpose, deprecation, and a high-level overview of returns. However, it could be more complete by explicitly stating that it's a read-only operation or mentioning any dependencies, but this is minor given the context.

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?

The input schema has 0 parameters with 100% coverage, so the schema fully documents that no inputs are required. The description doesn't need to add parameter details, and it appropriately doesn't mention any. Since there are no parameters, the baseline is 4, as the description doesn't contradict or add unnecessary information.

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 description clearly states the tool's purpose: 'Check the health status of all scrapers and services.' It specifies the verb ('Check') and resource ('health status of all scrapers and services'), making the action explicit. However, it doesn't distinguish this from sibling tools beyond the deprecation note, which is why it doesn't reach a 5.

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

Usage Guidelines5/5

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

The description provides explicit usage guidance: '**DEPRECATED**: This tool is deprecated. Please use flutter_status() instead.' It clearly states when not to use this tool (it's deprecated) and names the alternative tool (flutter_status), which is ideal for helping an AI agent select the correct tool.

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

process_flutter_mentionsA

Parse text for @flutter_mcp mentions and return relevant documentation.

NOTE: This tool is maintained for backward compatibility. For new integrations, consider using the unified tools directly:

flutter_docs: For Flutter/Dart classes and pub.dev packages
flutter_search: For searching Flutter/Dart documentation

Supports patterns like:

@flutter_mcp provider (pub.dev package - latest version)
@flutter_mcp provider:^6.0.0 (specific version constraint)
@flutter_mcp riverpod:2.5.1 (exact version)
@flutter_mcp dio:>=5.0.0 <6.0.0 (version range)
@flutter_mcp bloc:latest (latest version keyword)
@flutter_mcp material.AppBar (Flutter class)
@flutter_mcp dart:async.Future (Dart API)
@flutter_mcp Container (widget)

Args: text: Text containing @flutter_mcp mentions tokens: Maximum token limit for each mention's documentation (default: 4000, min: 500)

Returns: Dictionary with parsed mentions and their documentation

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes
`tokens`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool does (parses mentions and returns documentation), provides examples of supported patterns, and specifies default values and constraints (tokens default: 4000, min: 500). However, it doesn't mention potential limitations like rate limits, error handling, or authentication requirements.

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

Conciseness5/5

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

The description is well-structured and appropriately sized. It begins with the core purpose, provides important compatibility notes, lists supported patterns with examples, documents parameters clearly, and specifies the return format. Every sentence serves a distinct purpose with zero redundancy.

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?

Given the tool's complexity (parsing multiple mention patterns, documentation retrieval), the description provides comprehensive context. It covers purpose, usage guidelines, behavioral details, parameter semantics, and return format. With an output schema present, the description appropriately focuses on explaining what the tool does rather than detailing return values.

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

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by providing detailed parameter information. It explains both parameters: 'text: Text containing @flutter_mcp mentions' and 'tokens: Maximum token limit for each mention's documentation (default: 4000, min: 500).' This adds crucial semantic context beyond the bare schema, including purpose, constraints, and default values.

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

Purpose5/5

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

The description clearly states the tool's purpose: 'Parse text for @flutter_mcp mentions and return relevant documentation.' It specifies the verb (parse), resource (text with mentions), and output (documentation). It explicitly distinguishes from siblings by naming flutter_docs and flutter_search as preferred alternatives for new integrations.

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

Usage Guidelines5/5

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

The description provides explicit guidance on when to use this tool versus alternatives. It states: 'This tool is maintained for backward compatibility. For new integrations, consider using the unified tools directly: flutter_docs and flutter_search.' This clearly indicates the tool's legacy status and recommends specific alternatives by name.

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

search_flutter_docsA

Search across Flutter/Dart documentation sources with fuzzy matching.

DEPRECATED: This tool is deprecated. Please use flutter_search() instead. The new tool provides better filtering and more structured results.

Searches Flutter API docs, Dart API docs, and pub.dev packages. Returns top 5-10 most relevant results with brief descriptions.

Args: query: Search query (e.g., "state management", "Container", "navigation", "http requests") tokens: Maximum token limit for response (default: 5000, min: 500)

Returns: Search results with relevance scores and brief descriptions

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`tokens`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the scope of sources searched ('Flutter API docs, Dart API docs, and pub.dev packages'), result limits ('top 5-10 most relevant results'), and output format ('brief descriptions'). However, it lacks details on rate limits, error handling, or authentication needs, which would be beneficial for a search tool.

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

Conciseness5/5

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

The description is well-structured and front-loaded: it starts with the core purpose, immediately highlights deprecation, then details sources, results, and parameters. Every sentence adds value—no redundancy or fluff—making it efficient for an agent to parse and use.

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?

Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is complete enough. It covers purpose, deprecation, sources, result limits, and parameter semantics. The output schema handles return values, so the description doesn't need to detail them, and it addresses key gaps from the lack of annotations.

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. It adds meaningful context for both parameters: 'query' is explained with examples (e.g., 'state management'), and 'tokens' specifies default and minimum values ('default: 5000, min: 500'). This goes beyond the schema's basic types, though it could clarify token usage more (e.g., per result or total).

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

Purpose5/5

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

The description clearly states the tool's purpose: 'Search across Flutter/Dart documentation sources with fuzzy matching.' It specifies the verb ('Search'), resource ('Flutter/Dart documentation sources'), and method ('fuzzy matching'), distinguishing it from siblings like 'get_flutter_docs' (likely retrieval) or 'flutter_search' (its replacement).

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

Usage Guidelines5/5

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

The description provides explicit usage guidance: it marks the tool as 'DEPRECATED' and directs users to 'use flutter_search() instead,' with reasons ('better filtering and more structured results'). This clearly indicates when not to use this tool and names the alternative, helping the agent avoid deprecated functionality.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

8 tool updatesAug 15, 2025
- First observedflutter_docs
- First observedflutter_search
- First observedflutter_status
- First observedget_flutter_docs
- First observedget_pub_package_info
- First observedhealth_check
- First observedprocess_flutter_mentions
- First observedsearch_flutter_docs

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation3/5

The tool set has significant overlap and redundancy, with deprecated tools that duplicate the functionality of newer unified tools. For example, flutter_docs, get_flutter_docs, get_pub_package_info, and process_flutter_mentions all serve similar documentation lookup purposes, which could confuse an agent. However, the descriptions clearly indicate which tools are deprecated, helping to mitigate confusion.

Naming Consistency3/5

The naming is mixed, with some tools using a consistent verb_noun pattern (e.g., flutter_docs, flutter_search, flutter_status) and others using different conventions (e.g., get_flutter_docs, get_pub_package_info, health_check, process_flutter_mentions, search_flutter_docs). This inconsistency makes the set less predictable, though the names are still generally readable.

Tool Count4/5

With 8 tools, the count is reasonable for a documentation-focused server. However, 3 of the tools are deprecated, effectively reducing the active tool set to 5, which feels slightly thin but still adequate for the domain. The number is not excessive, but the inclusion of deprecated tools adds unnecessary bulk.

Completeness4/5

The server covers core documentation needs for Flutter/Dart, including lookup, search, and health checks, with no major gaps in functionality. The unified tools (flutter_docs, flutter_search, flutter_status) provide a complete surface for the domain. The deprecated tools do not create gaps but rather redundancy, which does not hinder coverage.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

llmref A
org.llmref
Versioned documentation registry and semantic search for AI tools and coding assistants.
Documentation Access Search Developer Tools
42
driflyte-mcp-server
com.driflyte
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
Search Web Scraping Knowledge & Memory
211
Tseha AFeatured
io.tseha
Serves your design system and coding standards to coding agents, so they stop guessing.
Developer Tools Documentation Access
93
docfork-mcpOAuth
ai.smithery
@latest documentation and code examples to 9000+ libraries for LLMs and AI code editors in a singl…
Documentation Access Developer Tools Code Analysis
2488

Related MCP Servers

Document Automation MCP Server
Developer Tools Code Analysis Documentation Access
vedantparmar12
A
license
Not graded
quality
D
maintenance
A sophisticated server that enables AI assistants to automatically analyze codebases and generate comprehensive, professional documentation.
Updated 8 months ago (2026-01-19 17:34 UTC)
2
MIT
RTFD (Read The F*****g Docs)
Documentation Access Developer Tools Search
aserper
A
license
A
quality
C
maintenance
Provides LLMs with real-time access to up-to-date documentation from PyPI, npm, crates.io, GoDocs, DockerHub, GitHub, and GCP, preventing outdated code generation and API hallucinations.
Updated 2 months ago (2026-07-16 20:17 UTC)
27
14
MIT
Flutter Package MCP Server
Developer Tools Search Documentation Access
OrtakProje-1
A
license
A
quality
D
maintenance
Integrates the Pub.dev API with AI assistants to provide real-time Flutter package information, documentation, and trend analysis. It enables users to search for packages, compare versions, and evaluate quality scores through natural language commands.
Updated a year ago (2025-06-15 14:27 UTC)
6
MIT
Atlas Docs MCP Server
CartographAI
A
license
A
quality
D
maintenance
Provides AI assistants with up-to-date documentation for popular libraries and frameworks, enabling them to generate more accurate code using less common or newly released libraries.
Updated a year ago (2025-04-22 06:43 UTC)
5
53
36
MIT

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/adamsmaka/flutter-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Flutter MCP: Give Your AI Real-Time Flutter Superpowers 🚀

🎬 Demo

The Problem: Your AI is Stuck in 2021

😡 Without Flutter MCP

✅ With Flutter MCP

🚀 Quick Start

Installation

Alternative Installation Methods

Requirements

2. Add to Your AI Assistant

3. Start the Server (Optional for Testing)

3. Use It!

🎯 New Simplified Usage (Recommended)

💫 Natural Language Support

🔧 Legacy Support

🎯 Version-Specific Documentation (NEW!)

📚 Available Tools

🎯 NEW: Simplified Tools (Context7-style)

1. flutter_search - Universal Search

2. flutter_docs - Smart Documentation Fetcher

3. flutter_status - Health Check (Optional)

📦 Legacy Tools (Deprecated but still functional)

get_flutter_docs (Use flutter_docs instead)

get_pub_package_info (Use flutter_docs instead)

search_flutter_docs (Use flutter_search instead)

process_flutter_mentions (Still functional)

health_check (Use flutter_status instead)

🎯 Features

💡 How It Works

The Magic Behind the Scenes

Performance Notes

Error Handling

📊 What Gets Indexed

🛠️ Advanced Usage

🛠️ Troubleshooting

📱 Client Configurations

🤝 Contributing

Quick Ways to Contribute

🚀 What's New & Coming Soon

❤️ Spread the Word

📄 License

🏗️ Built With

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

1. `flutter_search` - Universal Search

2. `flutter_docs` - Smart Documentation Fetcher

3. `flutter_status` - Health Check (Optional)

`get_flutter_docs` (Use `flutter_docs` instead)

`get_pub_package_info` (Use `flutter_docs` instead)

`search_flutter_docs` (Use `flutter_search` instead)

`process_flutter_mentions` (Still functional)

`health_check` (Use `flutter_status` instead)