mcp-flowise是一个 Python 包，实现了与 Flowise API 集成的模型上下文协议 (MCP) 服务器。它提供了一种标准化且灵活的方式来列出聊天流、创建预测，并为 Flowise 聊天流或助手动态注册工具。
它支持两种操作模式：
低级模式（默认） ：动态注册从 Flowise API 检索的所有聊天流的工具。
FastMCP 模式：提供列出聊天流和创建预测的静态工具，适用于更简单的配置。
动态工具暴露：低级模式为每个聊天流或助手动态创建工具。
更简单的配置：FastMCP 模式公开list_chatflows和create_prediction工具以进行最少设置。
灵活过滤：两种模式都支持通过 ID 或名称（正则表达式）通过白名单和黑名单过滤聊天流。
MCP 集成：无缝集成到 MCP 工作流程中。
Related MCP server: n8n-MCP
要通过Smithery自动为 Claude Desktop 安装 mcp-flowise：
npx -y @smithery/cli install @matthewhand/mcp-flowise --client claudePython 3.12 或更高版本
uvx包管理器
uvx安装并运行确认您可以使用uvx直接从 GitHub 存储库运行服务器：
uvx --from git+https://github.com/matthewhand/mcp-flowise mcp-flowisemcpServers配置）您可以将mcp-flowise添加到mcpServers配置中，从而将其集成到您的 MCP 生态系统中。例如：
{
"mcpServers": {
"mcp-flowise": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/matthewhand/mcp-flowise",
"mcp-flowise"
],
"env": {
"FLOWISE_API_KEY": "${FLOWISE_API_KEY}",
"FLOWISE_API_ENDPOINT": "${FLOWISE_API_ENDPOINT}"
}
}
}
}通过设置FLOWISE_SIMPLE_MODE=true启用。此模式：
公开两个工具： list_chatflows和create_prediction 。
允许使用FLOWISE_CHATFLOW_ID或FLOWISE_ASSISTANT_ID进行静态配置。
通过list_chatflows列出所有可用的聊天流。
特征：
将所有聊天流动态注册为单独的工具。
工具以聊天流程名称命名（规范化）。
使用来自FLOWISE_CHATFLOW_DESCRIPTIONS变量的描述，如果没有提供描述，则返回到聊天流名称。
例子：
my_tool(question: str) -> str 。
uvx在 Windows 上运行如果您在 Windows 上使用uvx时遇到--from git+https的问题，建议的解决方案是将仓库克隆到本地，并使用uvx.exe和克隆仓库的完整路径配置mcpServers 。此外，请根据需要添加APPDATA 、 LOGLEVEL和其他环境变量。
mcpServers ）{
"mcpServers": {
"flowise": {
"command": "C:\\Users\\matth\\.local\\bin\\uvx.exe",
"args": [
"--from",
"C:\\Users\\matth\\downloads\\mcp-flowise",
"mcp-flowise"
],
"env": {
"LOGLEVEL": "ERROR",
"APPDATA": "C:\\Users\\matth\\AppData\\Roaming",
"FLOWISE_API_KEY": "your-api-key-goes-here",
"FLOWISE_API_ENDPOINT": "http://localhost:3000/"
}
}
}
}完整路径：对uvx.exe和克隆的存储库使用完整路径。
环境变量：如果需要，将APPDATA指向您的 Windows 用户配置文件（例如， C:\\Users\\<username>\\AppData\\Roaming ）。
日志级别：根据需要调整LOGLEVEL （ ERROR 、 INFO 、 DEBUG等）。
FLOWISE_API_KEY ：您的 Flowise API Bearer 令牌（必需）。
FLOWISE_API_ENDPOINT ：Flowise 的基本 URL（默认值： http://localhost:3000 ）。
FLOWISE_CHATFLOW_DESCRIPTIONS ：以逗号分隔的chatflow_id:description对列表。例如：
FLOWISE_CHATFLOW_DESCRIPTIONS="abc123:Chatflow One,xyz789:Chatflow Two"FLOWISE_SIMPLE_MODE=true ）FLOWISE_CHATFLOW_ID ：单个聊天流 ID（可选）。
FLOWISE_ASSISTANT_ID ：单个助手 ID（可选）。
FLOWISE_CHATFLOW_DESCRIPTION ：针对所公开的单个工具的可选描述。
可以使用以下环境变量在两种模式下应用过滤器：
按 ID 加入白名单：FLOWISE_WHITELIST_ID="id1,id2,id3"
按 ID 加入黑名单：FLOWISE_BLACKLIST_ID="id4,id5"
按名称列入白名单（正则表达式） ：FLOWISE_WHITELIST_NAME_REGEX=".*important.*"
按名称列入黑名单（正则表达式） ：FLOWISE_BLACKLIST_NAME_REGEX=".*deprecated.*"
注意：白名单优先于黑名单。如果同时设置了白名单和黑名单，则采用最严格的规则。
保护您的 API 密钥：确保FLOWISE_API_KEY的安全，不会在日志或存储库中暴露。
环境配置：使用.env文件或环境变量进行敏感配置。
将.env添加到你的.gitignore中：
# .gitignore
.env缺少 API 密钥：确保FLOWISE_API_KEY设置正确。
无效配置：如果同时设置了FLOWISE_CHATFLOW_ID和FLOWISE_ASSISTANT_ID ，服务器将拒绝启动。
连接错误：验证FLOWISE_API_ENDPOINT是否可访问。
本项目遵循 MIT 许可证。详情请参阅LICENSE文件。
[x] Fastmcp 模式
[x] 低级模式
[x] 过滤
[x] Claude 桌面集成
[ ] 助理
Create a prediction by sending a question to a specific chatflow or assistant.
Args:
chatflow_id (str, optional): The ID of the chatflow to use. Defaults to FLOWISE_CHATFLOW_ID.
question (str): The question or prompt to send to the chatflow.
Returns:
str: The raw JSON response from Flowise API or an error message if something goes wrong.
| Name | Required | Description | Default |
|---|---|---|---|
| chatflow_id | No | ||
| question | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that this is a creation/mutation tool ('Create a prediction') and mentions the API source ('Flowise API'), but lacks details about authentication needs, rate limits, error handling beyond 'error message', or whether predictions are stored persistently.
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 appropriately sized with clear sections (purpose, args, returns). The first sentence states the core purpose, and subsequent details are necessary. Minor improvement could be merging the first two sentences for better flow.
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 2 parameters with 0% schema coverage and no output schema, the description provides basic parameter semantics and return type ('raw JSON response' or 'error message'), but lacks details on response structure, error cases, or integration context (e.g., what a 'prediction' entails in this system).
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 description coverage is 0%, so the description must compensate. It adds meaningful context for both parameters: chatflow_id is optional with a default value from environment, and question is the prompt to send. However, it doesn't explain format constraints or provide examples.
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 the tool's purpose: 'Create a prediction by sending a question to a specific chatflow or assistant.' It specifies the verb ('Create a prediction') and resource ('chatflow or assistant'), but doesn't explicitly differentiate from the sibling tool 'list_chatflows' beyond their different functions.
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 implies usage context by mentioning 'chatflow or assistant' and referencing 'FLOWISE_CHATFLOW_ID' as a default, but doesn't provide explicit guidance on when to use this tool versus alternatives or any prerequisites. The sibling tool 'list_chatflows' is mentioned but not compared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available chatflows from the Flowise API.
This function respects optional whitelisting or blacklisting if configured
via FLOWISE_CHATFLOW_WHITELIST or FLOWISE_CHATFLOW_BLACKLIST.
Returns:
str: A JSON-encoded string of filtered chatflows.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 behavioral traits: it's a read operation (implied by 'List'), respects configuration-based filtering, and returns JSON-encoded data. However, it doesn't mention potential rate limits, authentication needs, or error handling, leaving some gaps in behavioral context.
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 perfectly concise and well-structured: three sentences with zero waste. The first sentence states the purpose, the second explains configuration behavior, and the third specifies the return format. Every sentence earns its place and information is appropriately 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 the tool's simplicity (0 parameters, no output schema, no annotations), the description provides good contextual completeness. It covers purpose, behavioral constraints (filtering), and return format. However, without annotations or output schema, it could benefit from more detail about the structure of returned JSON or error conditions for a fully complete picture.
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?
The input schema has 0 parameters with 100% coverage, so the description doesn't need to compensate for parameter documentation. The description appropriately focuses on behavioral aspects rather than parameter semantics, which is correct for a parameterless tool. It adds value by explaining the filtering behavior beyond what the empty schema provides.
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 the tool's purpose: 'List all available chatflows from the Flowise API.' This specifies the verb ('List') and resource ('chatflows'), though it doesn't explicitly differentiate from its sibling tool 'create_prediction' beyond the obvious action difference. The purpose is clear but lacks explicit sibling comparison.
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 implies usage context by mentioning whitelisting/blacklisting configuration, but it doesn't provide explicit guidance on when to use this tool versus alternatives. There's no mention of when not to use it or direct comparison to 'create_prediction', leaving usage context somewhat implied rather than clearly articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools have completely distinct purposes: one lists available chatflows, and the other creates predictions using a specific chatflow. There is no overlap in functionality or ambiguity between them.
Both tools follow a consistent verb_noun pattern (list_chatflows, create_prediction) with clear, descriptive names that align with their functions. No deviations or mixed conventions are present.
With only 2 tools, the server feels thin for its apparent domain of interacting with Flowise chatflows. While the tools cover basic operations, the lack of tools for updating, deleting, or managing chatflows suggests an incomplete surface that may limit agent workflows.
The toolset is severely incomplete for a chatflow management domain. It provides listing and prediction creation but lacks essential CRUD operations like creating, updating, or deleting chatflows, as well as tools for managing predictions (e.g., retrieving or canceling them), which will likely cause agent failures in complex tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
Self-hosted MCP gateway: turn any API, database or MCP server into AI connectors — no code.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/matthewhand/mcp-flowise'
If you have feedback or need assistance with the MCP directory API, please join our Discord server