mcp-flowise
The mcp-flowise server connects MCP clients (Claude, Cursor, etc.) to a local Flowise instance, exposing chatflows as callable tools.
list_chatflows()– Retrieve all available chatflows (id + name), filterable via whitelist/blacklist rules by ID or name regex.create_prediction(chatflow_id, question)– Execute a specific chatflow with a user question and return its response.trigger_webhook(chatflow_id, payload)– Trigger webhook-based chatflows with a custom JSON payload.Dynamic mode (
FLOWISE_DYNAMIC=true) – Automatically registers one tool per chatflow at startup (e.g.,flowise_support_bot(question)), enabling direct invocation by name.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@mcp-flowiselist available chatflows"
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.
mcp-flowise
MCP server that exposes the chatflows of your local Flowise as tools for Claude, Cursor, free-code, or any MCP client.
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 viaPOST /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
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
/reloadConfiguration
Environment variable | Default | Description |
|
| Base URL of your Flowise instance |
| (empty) | Bearer token (Flowise → Settings → API Keys) |
|
| Set to |
| (empty) | Comma-separated chatflow IDs to include |
| (empty) | Comma-separated chatflow IDs to exclude |
| (empty) | Only include chatflows whose name matches |
| (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 quitInspect with MCP Inspector:
uv run mcp dev mcp_flowise/server.pyFlowise API reference
List chatflows:
GET {endpoint}/api/v1/chatflowsRun chatflow:
POST {endpoint}/api/v1/prediction/{chatflowId}with{"question": "..."}Auth header:
Authorization: Bearer <FLOWISE_API_KEY>
Available Tools
2 toolscreate_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.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | ||
| chatflow_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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
The two tools have clearly distinct purposes: one lists available chatflows, the other runs a specific chatflow. There is no overlap or ambiguity.
Both tools follow the verb_noun pattern with consistent snake_case naming (list_chatflows, create_prediction), making them predictable and easy to understand.
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.
The server lacks essential CRUD operations like creating, deleting, or updating chatflows, which are significant gaps for managing chatflows effectively.
Maintenance
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
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
MCP server exposing the Backtest360 engine API as tools for AI agents.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
Related MCP Servers
- AlicenseAqualityDmaintenanceThe Flowise MCP Server enables clients to list chatflows and call predictions, integrating seamlessly with DIY Flowise or Flowise Cloud accounts. It provides a simple interface for executing chatflows/assistants predictions with existing Flowise configurations.254MIT
- AlicenseNot gradedqualityDmaintenanceMCP Server for interacting with the Langflow API via a natural language interface. It exposes Langflow functionalities as tools for LLMs.MIT
- AlicenseNot gradedqualityAmaintenanceExposes Agentweaver runs and outcomes as MCP tools for Claude Desktop and compatible clients.55MIT
- AlicenseNot gradedqualityBmaintenanceExposes Node-RED flows as MCP tools for AI assistants, with OAuth protection and optional admin tools for flow management.3651ISC
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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