Skip to main content
Glama
Joseph19820124

Make.com MCP Server

by Joseph19820124
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Hybrid

Make.com到MCP Server集成Playbook

概述

本playbook将指导你如何将Make.com scenario转换为MCP (Model Context Protocol) server，并与Claude Desktop集成，实现自动化工作流。

Related MCP server: Make MCP Server

前置条件

  • Make.com账户（免费版即可开始）

  • Node.js 18+ 环境

  • Claude Desktop应用

  • 基础的JavaScript/TypeScript知识

步骤1：在Make.com创建基础Scenario

1.1 登录Make.com并创建新scenario

1. 访问 make.com 并登录
2. 点击 "Create a new scenario"
3. 选择 "Webhooks" 作为触发器
4. 配置 "Custom Webhook"

1.2 配置Webhook触发器

1. 点击webhook模块
2. 点击 "Add" 创建新webhook
3. 复制生成的webhook URL（稍后需要）
4. 设置webhook名称，如 "MCP-Trigger"

1.3 添加处理模块

根据你的需求添加处理模块，例如：

  • 数据处理：Filter, Router, Data store操作

  • 外部服务：Google Sheets, Notion, Slack等

  • HTTP请求：调用其他API

  • 响应格式化：Webhook Response模块

示例scenario结构：

Webhook → Filter → HTTP Request → Webhook Response

步骤2：创建MCP Server

2.1 初始化项目

mkdir make-mcp-server
cd make-mcp-server
npm init -y
npm install @modelcontextprotocol/sdk axios dotenv
npm install -D typescript @types/node

2.2 创建TypeScript配置

参见 tsconfig.json 文件

2.3 创建MCP Server代码

参见 src/server.ts 文件

2.4 创建环境配置

复制 .env.example 为 .env 并填入你的配置：

MAKE_WEBHOOK_URL=你的Make.com_webhook_URL
MAKE_API_TOKEN=你的Make.com_API_token（可选）

2.5 构建和运行

npm run build
npm start

步骤3：配置Claude Desktop

3.1 编译并测试MCP Server

npm run build
chmod +x dist/server.js

3.2 配置Claude Desktop MCP

打开Claude Desktop配置文件：

  • macOS: ~/Library/Application\ Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

添加MCP server配置：

{
  "mcpServers": {
    "make-automation": {
      "command": "node",
      "args": ["/path/to/your/make-mcp-server/dist/server.js"],
      "env": {
        "MAKE_WEBHOOK_URL": "你的webhook_URL"
      }
    }
  }
}

3.3 重启Claude Desktop

重启Claude Desktop应用以加载新的MCP server配置。

步骤4：测试集成

4.1 在Claude Desktop中测试

你好Claude，请帮我触发Make scenario来创建一个任务，数据是：
{
  "title": "测试任务",
  "priority": "high",
  "due_date": "2025-01-15"
}

4.2 验证Make.com执行

  1. 检查Make.com dashboard中的执行历史

  2. 确认数据已正确传递

  3. 验证后续处理模块是否正常工作

高级配置

错误处理和重试机制

参见 src/server.ts 中的实现示例

数据验证

参见 src/server.ts 中的 validatePayload 方法

日志记录

可以集成 winston 或其他日志库来记录详细的执行日志

常见用例示例

用例1：自动化数据处理

Make.com流程: Webhook → 数据验证 → Google Sheets更新 → Slack通知

用例2：任务管理集成

Make.com流程: Webhook → Notion数据库创建 → 团队成员邮件通知

用例3：内容发布工作流

Make.com流程: Webhook → 内容格式化 → 多平台发布 → 分析报告

故障排除

常见问题

  1. MCP Server连接失败

    • 检查文件路径和权限

    • 确认Node.js版本兼容性

  2. Webhook调用失败

    • 验证webhook URL正确性

    • 检查Make.com scenario状态

  3. 数据传递问题

    • 确认JSON格式正确

    • 检查Make.com数据映射

调试技巧

# 启用详细日志
DEBUG=* node dist/server.js

# 测试webhook连通性
curl -X POST -H "Content-Type: application/json" -d '{"test":true}' YOUR_WEBHOOK_URL

项目结构

make-mcp-server/
├── src/
│   └── server.ts          # MCP服务器主代码
├── dist/                  # 编译输出目录
├── package.json           # 项目配置
├── tsconfig.json         # TypeScript配置
├── .env.example          # 环境变量示例
├── .gitignore            # Git忽略文件
└── README.md             # 项目文档

扩展功能

  • 添加更多Make.com API集成

  • 实现batch操作支持

  • 添加webhook验证机制

  • 集成更多第三方服务

贡献

欢迎提交Issue和Pull Request来改进这个项目！

许可证

MIT License

通过这个playbook，你现在可以将Make.com的强大自动化能力直接整合到Claude Desktop的工作流中，实现seamless的AI驱动自动化！

Available Tools

3 tools
get_scenario_statusC

获取Make.com scenario的执行状态

ParametersJSON Schema
NameRequiredDescriptionDefault
execution_idYesscenario执行ID

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It states the tool 'gets' status, implying a read-only operation, but doesn't disclose behavioral traits like error handling, rate limits, authentication needs, or what the status output entails. This is a significant gap 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 a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.

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

Completeness2/5

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

Given no annotations, no output schema, and a simple input schema, the description is incomplete. It doesn't explain what the status return values might be, error conditions, or operational context, which is inadequate for a tool that likely returns varied status information.

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 description coverage is 100%, with the parameter 'execution_id' documented as 'scenario执行ID'. The description adds no additional meaning beyond this, such as format examples or sourcing details, so it meets the baseline for high schema coverage without compensating value.

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 verb '获取' (get) and resource 'Make.com scenario的执行状态' (execution status of Make.com scenario), making the purpose specific. However, it doesn't distinguish this tool from its siblings (test_webhook_connection, trigger_make_scenario), which are clearly different operations, so it doesn't reach the highest score.

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 or in what context. It lacks any mention of prerequisites, dependencies, or comparisons to sibling tools, leaving usage entirely implicit.

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

test_webhook_connectionC

测试与Make.com webhook的连接

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

C2.9/5.0
Behavior2/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 only states the purpose without detailing what the tool actually does (e.g., sends a test request, verifies endpoints, returns status codes) or any behavioral traits like error handling, side effects, or output format. This leaves the agent guessing about the tool's operation.

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 a single, efficient sentence in Chinese that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., success/failure status, error messages) or how it behaves, which is crucial for a connection-testing tool. With sibling tools and no structured data to fill gaps, the description should provide more context about the tool's operation and results.

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 no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. A baseline of 4 is applied since the schema fully covers the lack of parameters, and the description doesn't need to compensate.

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

Purpose3/5

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

The description states the tool's purpose as '测试与Make.com webhook的连接' (Test connection with Make.com webhook), which is a clear verb+resource combination. However, it doesn't differentiate from sibling tools like get_scenario_status or trigger_make_scenario, leaving ambiguity about when to use this specific connection test versus other webhook-related operations.

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?

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions, such as whether this should be used before configuring webhooks or as a diagnostic tool. With sibling tools present, this lack of differentiation is a significant gap.

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

trigger_make_scenarioC

触发Make.com scenario执行指定任务

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYes要执行的动作类型
dataNo传递给scenario的数据

TDQS

C2.6/5.0
Behavior2/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. While '触发' (trigger) implies an action that initiates something, the description doesn't reveal whether this is a read-only or destructive operation, what permissions are required, whether it's idempotent, rate limits, error handling, or what happens after triggering. For a tool that likely performs external API calls with no annotation coverage, this is inadequate.

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 a single, efficient sentence in Chinese that directly states the tool's function without unnecessary words. It's appropriately sized for a simple tool, though it could be slightly more specific to improve clarity without losing conciseness.

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

Completeness2/5

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

Given the tool likely interacts with an external service (Make.com) to trigger scenarios, has no annotations, no output schema, and involves parameters that could have complex implications (like the data object), the description is incomplete. It doesn't cover what happens after triggering, potential side effects, error cases, or how to interpret results, leaving significant gaps for an AI agent to use it correctly.

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 description coverage is 100%, so the schema already documents both parameters (action with enum values and data object). The description doesn't add any meaningful parameter semantics beyond what's in the schema—it doesn't explain what '要执行的动作类型' (action type to execute) means in practice or how the data object should be structured for different actions. Baseline 3 is appropriate when schema does the heavy lifting.

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

Purpose3/5

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

The description states the tool '触发Make.com scenario执行指定任务' (triggers Make.com scenario to execute specified tasks), which provides a basic verb+resource combination. However, it's somewhat vague about what 'specified tasks' means, and while it distinguishes from sibling tools like get_scenario_status and test_webhook_connection by focusing on execution rather than status checking or testing, it doesn't clearly differentiate the scope of triggering versus other potential execution tools.

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 prerequisites, appropriate contexts, or exclusions. Given the sibling tools (get_scenario_status, test_webhook_connection), there's no indication of when triggering execution is preferred over checking status or testing connections.

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.

  1. 3 tool updatesv1.0.0
    • First observedget_scenario_status
    • First observedtest_webhook_connection
    • First observedtrigger_make_scenario
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: get_scenario_status retrieves status, test_webhook_connection checks connectivity, and trigger_make_scenario initiates execution. The descriptions reinforce these distinct functions, making misselection unlikely.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with snake_case: get_scenario_status, test_webhook_connection, and trigger_make_scenario. The naming is predictable and readable throughout the set.

Tool Count3/5

With only 3 tools, the set feels thin for a Make.com integration server, which typically involves more operations like managing scenarios, webhooks, or data. While the tools cover core actions, the count is borderline minimal for the apparent scope.

Completeness2/5

There are significant gaps in the tool surface for a Make.com server. Missing operations include creating, updating, or deleting scenarios, listing scenarios, managing webhooks beyond testing, and handling data flows. This will likely cause agent failures in broader workflows.

Maintenance

ActivityInactive
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

  • Make MCP Server

    3rzy
    A
    license
    Not graded
    quality
    D
    maintenance
    An integration server that allows Claude Desktop to communicate with Make (formerly Integromat) automation platform through the Model Context Protocol, enabling scenario management and execution via natural language.
    110
    MIT

  • Make MCP Server

    integromat
    A
    license
    D
    quality
    F
    maintenance
    Transform your Make scenarios into callable tools for AI assistants. Leverage your existing automation workflows while enabling AI systems to trigger and interact with them seamlessly.
    6
    104
    170
    MIT

Appeared in Searches

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/Joseph19820124/make-mcp-integration-playbook'

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