Skip to main content
Glama

mcp-flowise

MCP server that exposes the chatflows of your local Flowise as tools for Claude, Cursor, free-code, or any MCP client.

PyPI npm

Tools

Simple mode (default):

  • list_chatflows() — lists available chatflows (id + name).

  • create_prediction(chatflow_id, question) — runs a Chat/Form-trigger chatflow and returns its response.

  • trigger_webhook(chatflow_id, payload) — runs a Webhook-trigger chatflow via POST /api/v1/webhook/{id}.

Dynamic mode (FLOWISE_DYNAMIC=true):

  • Registers one tool per chatflow at startup, e.g. flowise_support_bot(question).

Related MCP server: Langflow MCP Server

Requirements

  • A running Flowise instance (default http://localhost:3000)

  • Node.js 18+ or Python 3.10+ with uv


Installation

One-command install (any client)

npx -y -p @suamkf08/mcp-flowise mcp-flowise-install --client claude
npx -y -p @suamkf08/mcp-flowise mcp-flowise-install --client cursor
npx -y -p @suamkf08/mcp-flowise mcp-flowise-install --client free-code
npx -y -p @suamkf08/mcp-flowise mcp-flowise-install --client vscode
npx -y -p @suamkf08/mcp-flowise mcp-flowise-install --client windsurf

-p @suamkf08/mcp-flowise pulls the published package that ships the mcp-flowise-install binary; npx then runs that binary. (There is no separate @suamkf08/mcp-flowise-install package on npm — the installer lives inside @suamkf08/mcp-flowise.)

The script asks for your FLOWISE_API_ENDPOINT and FLOWISE_API_KEY, writes the config automatically, and tells you where it was saved. Restart your client after running it.


Manual install

Claude Desktop

Add this to your claude_desktop_config.json (~/Library/Application Support/Claude/claude_desktop_config.json on macOS, %APPDATA%\Claude\claude_desktop_config.json on Windows):

Option A — via npm (Node.js required):

{
  "mcpServers": {
    "mcp-flowise": {
      "command": "npx",
      "args": ["-y", "@suamkf08/mcp-flowise"],
      "env": {
        "FLOWISE_API_ENDPOINT": "http://localhost:3000",
        "FLOWISE_API_KEY": ""
      }
    }
  }
}

Option B — via uvx (uv required):

Install uv first if you don't have it:

# macOS / Linux
curl -LsSf https://astral.sh/uv/install.sh | sh

# Windows
powershell -c "irm https://astral.sh/uv/install.ps1 | iex"

Then add to claude_desktop_config.json:

{
  "mcpServers": {
    "mcp-flowise": {
      "command": "uvx",
      "args": ["mcp-flowise"],
      "env": {
        "FLOWISE_API_ENDPOINT": "http://localhost:3000",
        "FLOWISE_API_KEY": ""
      }
    }
  }
}

Cursor

Add to .cursor/mcp.json in your project (or ~/.cursor/mcp.json globally):

{
  "mcpServers": {
    "mcp-flowise": {
      "command": "npx",
      "args": ["-y", "@suamkf08/mcp-flowise"],
      "env": {
        "FLOWISE_API_ENDPOINT": "http://localhost:3000",
        "FLOWISE_API_KEY": ""
      }
    }
  }
}

free-code

Add to ~/.free-code/agent/mcp.json (or import with /mcp-import):

{
  "mcpServers": {
    "mcp-flowise": {
      "command": "npx",
      "args": ["-y", "@suamkf08/mcp-flowise"],
      "env": {
        "FLOWISE_API_ENDPOINT": "http://localhost:3000",
        "FLOWISE_API_KEY": ""
      }
    }
  }
}

Then enable it in free-code:

/mcp enable mcp-flowise
/reload

Configuration

Environment variable

Default

Description

FLOWISE_API_ENDPOINT

http://localhost:3000

Base URL of your Flowise instance

FLOWISE_API_KEY

(empty)

Bearer token (Flowise → Settings → API Keys)

FLOWISE_DYNAMIC

false

Set to true to register one tool per chatflow

FLOWISE_WHITELIST_ID

(empty)

Comma-separated chatflow IDs to include

FLOWISE_BLACKLIST_ID

(empty)

Comma-separated chatflow IDs to exclude

FLOWISE_WHITELIST_NAME_REGEX

(empty)

Only include chatflows whose name matches

FLOWISE_BLACKLIST_NAME_REGEX

(empty)

Exclude chatflows whose name matches


Development

git clone https://github.com/suamkf08/mcp-flowise
cd mcp-flowise
uv run mcp-flowise        # starts over stdio; Ctrl+C to quit

Inspect with MCP Inspector:

uv run mcp dev mcp_flowise/server.py

Flowise API reference

  • List chatflows: GET {endpoint}/api/v1/chatflows

  • Run chatflow: POST {endpoint}/api/v1/prediction/{chatflowId} with {"question": "..."}

  • Auth header: Authorization: Bearer <FLOWISE_API_KEY>

Available Tools

2 tools
create_predictionA

Run a Flowise chatflow and return its response.

Args: chatflow_id: Id of the chatflow to run (see list_chatflows). question: User input / prompt to send to the chatflow.

ParametersJSON Schema
NameRequiredDescriptionDefault
questionYes
chatflow_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior2/5

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

No annotations are provided, so the description must disclose behavior. It mentions running and returning a response but omits crucial details like idempotency, authentication requirements, error handling, or side effects.

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 concise (3 sentences) and front-loaded, with no unnecessary information. Every sentence serves a purpose.

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

Completeness3/5

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

Given two required parameters and no annotations, the description is adequate but lacks details on return format (though output schema exists), timeouts, or async behavior. It minimally meets the needs for a run tool.

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

Parameters3/5

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

Schema coverage is 0%, so the description must compensate. It explains chatflow_id as 'Id of the chatflow to run (see list_chatflows)' and question as 'User input / prompt,' adding value beyond schema titles, though not deeply detailed.

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 'Run a Flowise chatflow and return its response,' specifying verb and resource. It distinguishes from sibling 'list_chatflows' by focusing on execution rather than listing.

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 references 'list_chatflows' to obtain chatflow_id, which implies a sequence, but does not explicitly state when to use this tool vs alternatives or provide exclusions.

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

list_chatflowsA

List the Flowise chatflows available on the configured instance.

Returns a JSON array of {"id", "name"} objects for each chatflow that passes the configured whitelist/blacklist filters.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

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

Mentions whitelist/blacklist filtering and return format, but lacks details on side-effects (likely none) or access requirements. With no annotations, description could be more explicit about being read-only.

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?

Two sentences cover purpose and return format. No extraneous text, front-loaded.

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 no parameters and an output schema, description sufficiently explains the tool. Could mention any limitations or pagination, but overall adequate.

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?

No parameters exist, baseline score of 4. Description adds value by explaining return format, but doesn't add parameter-specific semantics.

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?

Describes listing chatflows on the configured instance with specific verb and resource. Distinguishes from sibling 'create_prediction' which is for creation.

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?

Implied usage for retrieving available chatflows, but no explicit mention of when to use versus alternatives. No 'when not to use' or context for filtering.

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

TDQS

A3.7/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: one lists available chatflows, the other runs a specific chatflow. There is no overlap or ambiguity.

Naming Consistency5/5

Both tools follow the verb_noun pattern with consistent snake_case naming (list_chatflows, create_prediction), making them predictable and easy to understand.

Tool Count3/5

With only two tools, the server feels thin for a typical chatflow interaction; while the set covers listing and running, it is on the low end of reasonable scope.

Completeness2/5

The server lacks essential CRUD operations like creating, deleting, or updating chatflows, which are significant gaps for managing chatflows effectively.

Maintenance

ActivitySlowing
ResponsivenessNo issues

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

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/EnmaSuamkf/mcp-flowise'

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