Skip to main content
Glama
remonh87

flutter-stripe-mcp

by remonh87
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

flutter-stripe-mcp

An MCP server that diagnoses Flutter + Stripe (flutter_stripe) setup issues — so Claude can check your project automatically.

What it does

Three tools: one diagnoses your local project setup, and two search GitHub for known issues and their fixes.

diagnose_setup takes the path to your Flutter project root and runs every check:

Check

Requirement

kotlin

Kotlin version >= 1.9.0 (read from android/settings.gradle or legacy android/build.gradle)

gradle_wrapper

Gradle wrapper >= 8.0

android_themes

Theme styles derive from Theme.AppCompat.*, Theme.MaterialComponents.*, or Theme.Material3.*

main_activity

MainActivity extends FlutterFragmentActivity (not FlutterActivity)

proguard_rules

proguard-rules.pro contains all required Stripe rules

ios_deployment_target

iOS deployment target >= 13.0 (from Podfile or project.pbxproj)

ios_camera_permission

NSCameraUsageDescription set in Info.plist (suggestion — needed for card scanning)

The result lists passing checks by name and returns a fix instruction for each problem found. Platforms without an android/ or ios/ directory are skipped.

Checking for known issues

Two more tools let Claude check whether a problem is already a documented issue in the flutter_stripe GitHub repo, and read the fix straight from the discussion:

Tool

Purpose

search_flutter_stripe_issues(query, state="all", limit=10)

Search issues by keywords (e.g. an error message); returns titles, state, and short excerpts.

get_flutter_stripe_issue(issue_number)

Fetch one issue's full body and all comments, to find the actual fix.

These use GitHub's public search API, which is limited to 60 requests/hour unauthenticated. If you hit the rate limit, the tool returns a clear error instead of failing silently. Optionally, set a GITHUB_TOKEN (or GH_TOKEN) environment variable to raise this to 5,000 requests/hour — no other configuration needed.

Related MCP server: reforge-mcp

Install

pip install flutter-stripe-mcp

Or with uv:

uv tool install flutter-stripe-mcp

Add to Claude Desktop

Open ~/Library/Application Support/Claude/claude_desktop_config.json and add:

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

Restart Claude Desktop. Claude will now have access to the diagnostic tool.

Add to Claude Code

claude mcp add flutter-stripe-mcp -- flutter-stripe-mcp

Usage

Ask Claude:

"Check if my Flutter project at /path/to/myapp is set up correctly for flutter_stripe."

Claude calls diagnose_setup with the project root and tells you exactly what to fix.

Development

uv sync
uv run pytest

See DEVELOPMENT.md for running the server locally with MCP Inspector.

Available Tools

3 tools
diagnose_setupA
Read-onlyIdempotent

Diagnose a Flutter + Stripe (flutter_stripe) project setup.

Android checks: Kotlin version, Gradle wrapper version, theme parents, MainActivity base class, ProGuard rules. iOS checks: minimum deployment target, camera usage permission.

Args: project_path: Absolute path to the Flutter project root (the directory containing android/ and ios/).

Returns: {"ok": [names of passed checks], "issues": [{"check", "status", "fix", ...} for each problem found]}

ParametersJSON Schema
NameRequiredDescriptionDefault
project_pathYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare readOnlyHint=true and idempotentHint=true. The description adds specific behavioral details: lists exact checks (Kotlin version, Gradle, etc.) and return structure. No contradictions, and it enriches agent understanding of behavior.

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-organized with clear sections (Android checks, iOS checks, Args, Returns). It is concise yet comprehensive, using bullet-like structure and plain text efficiently.

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 multi-platform checks, the description covers all relevant aspects: project path requirement, platform-specific checks, and return format. It provides sufficient detail for an agent to understand the tool's full scope.

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?

The description explains the 'project_path' parameter comprehensively: 'Absolute path to the Flutter project root (the directory containing android/ and ios/).' This adds significant meaning beyond the schema's minimal 'Project Path' title, which had 0% coverage.

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: diagnose Flutter + Stripe project setup. It lists specific checks for Android and iOS, making the scope precise. With no sibling tools, it stands alone effectively.

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 implies usage for diagnosing Flutter+Stripe projects. It does not explicitly state when not to use it or alternatives, but given no siblings, the absence is acceptable. It provides clear context for use.

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

get_flutter_stripe_issueA
Read-onlyIdempotent

Fetch the full body and comments of one flutter_stripe GitHub issue.

Use this after search_flutter_stripe_issues has identified a candidate issue number, to read the complete discussion — maintainer replies and community comments often contain the actual fix, workaround, or root cause that a title/excerpt alone won't reveal.

Args: issue_number: The GitHub issue number (e.g. 1234), not a URL.

Returns: {"number", "title", "state", "url", "body", "comments": [{"author", "body"}]} (plus "note" if the comment thread was too long to fetch in full), or {"error": "...", "kind": "..."} on failure (e.g. not found).

ParametersJSON Schema
NameRequiredDescriptionDefault
issue_numberYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already indicate readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral details: returns a 'note' if the comment thread was too long, and returns an error object with a 'kind' field on failure. This goes 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.

Conciseness5/5

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

The description is well-structured with a clear summary, usage guidance, parameter description, and return format. It is concise, front-loaded, and every sentence adds value without 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 simplicity (1 parameter, output schema provided), the description covers all necessary aspects: input, output, error handling, and usage context. No missing information for effective agent decision-making.

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%, but the description adds crucial meaning: 'issue_number: The GitHub issue number (e.g. 1234), not a URL.' This clarifies the format and avoids confusion. For a single parameter, this is effective.

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?

Description clearly states 'Fetch the full body and comments of one flutter_stripe GitHub issue.' This is a specific verb+resource pair, and it distinguishes from its sibling search_flutter_stripe_issues by focusing on retrieving full details of a single issue.

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?

Explicitly tells when to use this tool: 'after search_flutter_stripe_issues has identified a candidate issue number.' It also explains why: 'to read the complete discussion — maintainer replies and community comments often contain the actual fix, workaround, or root cause.' This provides clear context and an alternative tool.

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

search_flutter_stripe_issuesA
Read-onlyIdempotent

Search GitHub issues in the flutter_stripe repository (flutter-stripe/flutter_stripe).

Use this to check whether a problem you're debugging (an error message, a crash, an unexpected behavior) is already a known, reported issue — before assuming it's novel or trying to work around it from scratch. Returns short excerpts so you can judge relevance; call get_flutter_stripe_issue with a specific issue number to read the full discussion and find the documented fix or workaround.

If an exact-match search (all words present) finds nothing, this automatically retries with a broader "any of these words" search and marks the result with "broadened_search": true — treat those results as lower-confidence and check relevance via the excerpt before following up with get_flutter_stripe_issue.

Args: query: Free-text search terms (e.g. an error message or symptom). state: "all" (default), "open", or "closed". limit: Max number of results to return (1-30).

Returns: {"total_count": int, "results": [{"number", "title", "state", "url", "excerpt"}]} (plus "broadened_search"/"note" if a broader fallback search was used), or {"error": "...", "kind": "..."} on failure (e.g. rate-limited).

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes
stateNoall

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A5/5.0
Behavior5/5

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

The description discloses key behaviors beyond annotations: automatic retry with broadened search on no exact match, marking results with 'broadened_search', and return format with error handling. This adds value beyond the readOnlyHint, openWorldHint, and idempotentHint 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 well-structured with clear paragraphs for purpose, usage, behavior, and parameters. It is concise without redundancy, front-loading the main goal and effectively using space for each aspect.

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 has 3 parameters (all fully explained), an output schema described in the return format, and error handling notes, the description is complete. It provides all necessary context for correct invocation and interpretation of results.

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 explains all three parameters: query (free-text, example given), state (enum with default), and limit (range and default). It also notes the output includes error on failure, compensating for missing schema descriptions.

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 searches GitHub issues in a specific repository (flutter-stripe/flutter_stripe) and distinguishes it from the sibling tool get_flutter_stripe_issue by mentioning that it returns excerpts for relevance judgment and advises using the sibling for full details.

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 explicitly tells when to use (to check if a problem is already reported) and provides context such as automated broadened search on no exact match. It also mentions the alternative tool for full discussion, giving clear usage guidance.

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

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

TDQS

A4.5/5.0
Disambiguation5/5

Only one tool exists (diagnose_setup), so there is no possibility of confusion with other tools. The tool's purpose is clearly described and unique.

Naming Consistency5/5

With a single tool, naming is trivially consistent. The verb_noun pattern 'diagnose_setup' follows a clear and predictable style.

Tool Count3/5

One tool is acceptable for a narrow diagnostic purpose, but it feels thin for a server branded as 'flutter-stripe-mcp'. Typically, such servers would have 3-15 tools to cover both setup and operations.

Completeness2/5

The tool only diagnoses setup issues. There are no tools for actual Stripe integration, configuration, or operations, creating significant gaps for a server targeting Flutter + Stripe workflows.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • plaid-mcp-server

    lukew0824
    F
    license
    Not graded
    quality
    D
    maintenance
    A self-hosted MCP server that lets Claude query your bank accounts, balances, and transactions through Plaid.
    1

  • devctl-mcp

    adarsh-devappsys
    F
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that lets Claude manage long-running development processes across frameworks like Flutter, Next.js, Spring Boot, and Vite, with lifecycle control, log streaming, and hot reload support.
    1

Latest Blog Posts

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/remonh87/flutter_stripe_mcp'

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