The MCP Server enables AI assistants to trigger and interact with Make automation workflows, exposing them as callable tools.
Connect to Make: Links to your Make account and identifies on-demand scenarios
Parameter Handling: Parses and resolves input parameters, providing meaningful descriptions
Scenario Invocation: Allows AI assistants to run scenarios with required parameters
Output Interpretation: Returns structured JSON output for AI systems to interpret
Maintains Complex Logic: Keeps intricate automation logic in Make while making it accessible to AI
Bidirectional Communication: Facilitates two-way interaction between AI assistants and workflows
Specific capabilities include executing various scenarios like inventory management, dynamic connections testing, and demonstrations of different input types including arrays of collections.
Allows AI assistants to trigger and interact with Make automation workflows, enabling scenarios configured with On-Demand scheduling to be utilized as tools by AI systems
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., "@Make MCP Server run my 'New Customer Onboarding' scenario for john.doe@example.com"
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.
A modern, cloud-based version of the Make MCP Server is now available. For most use cases, we recommend using this new version.
A Model Context Protocol server that enables Make scenarios to be utilized as tools by AI assistants. This integration allows AI systems to trigger and interact with your Make automation workflows.
The MCP server:
Connects to your Make account and identifies all scenarios configured with "On-Demand" scheduling
Parses and resolves input parameters for each scenario, providing AI assistants with meaningful parameter descriptions
Allows AI assistants to invoke scenarios with appropriate parameters
Returns scenario output as structured JSON, enabling AI assistants to properly interpret the results
Related MCP server: Automatisch MCP Server
Turn your Make scenarios into callable tools for AI assistants
Maintain complex automation logic in Make while exposing functionality to AI systems
Create bidirectional communication between your AI assistants and your existing automation workflows
NodeJS
MCP Client (like Claude Desktop App)
Make API Key with scenarios:read and scenarios:run scopes
To use this server with the Claude Desktop app, add the following configuration to the "mcpServers" section of your claude_desktop_config.json:
{
"mcpServers": {
"make": {
"command": "npx",
"args": ["-y", "@makehq/mcp-server"],
"env": {
"MAKE_API_KEY": "<your-api-key>",
"MAKE_ZONE": "<your-zone>",
"MAKE_TEAM": "<your-team-id>"
}
}
}
}MAKE_API_KEY - You can generate an API key in your Make profile.
MAKE_ZONE - The zone your organization is hosted in (e.g., eu2.make.com).
MAKE_TEAM - You can find the ID in the URL of the Team page.
Tool: List Inventory (Lists items in inventory.)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. The description only states what the tool does ('Lists items in inventory') without mentioning any behavioral traits like whether this is a read-only operation, if it requires authentication, what format the output takes, or any rate limits. For a tool with zero annotation coverage, this is insufficient.
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 extremely concise ('Tool: List Inventory (Lists items in inventory.)') with no wasted words. It's front-loaded with the tool name and purpose. However, the structure is slightly awkward with the parenthetical repetition, and it could be more polished while maintaining brevity.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'inventory' refers to, what format the list takes, or how this tool differs from its siblings. For a tool with no structured metadata, the description should provide more context to be fully usable by an agent.
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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of parameters. The description doesn't need to add parameter semantics, and it correctly doesn't mention any parameters. A baseline of 4 is appropriate for zero-parameter tools when the schema coverage is complete.
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 states the tool's purpose as 'Lists items in inventory', which is a clear verb+resource combination. However, it doesn't distinguish this tool from its siblings (all named 'run_scenario_XXXX'), leaving the agent uncertain about what makes this specific scenario unique. The description is adequate but lacks sibling differentiation.
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?
No guidance is provided about when to use this tool versus the five sibling 'run_scenario' tools. The description doesn't mention any context, prerequisites, or alternatives, leaving the agent with no usage guidelines beyond the basic purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool: Add to Inventory (Add a new item to the inventory.)
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Item name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Add to Inventory' implies a write/mutation operation, the description doesn't specify permissions needed, whether the operation is idempotent, what happens on duplicate items, or what the response contains. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
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 extremely concise - just one sentence that states the tool's core function. While this is efficient, it borders on under-specification given the lack of context about what 'inventory' means in this scenario system. Every word earns its place, but more context would be helpful.
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?
For a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what constitutes a valid 'item', how the inventory is structured, what happens after addition, or any error conditions. The agent lacks crucial context to use this tool effectively in the scenario-based system with multiple sibling tools.
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 100% with the single 'name' parameter well-documented in the schema. The description doesn't add any parameter semantics beyond what the schema already provides (e.g., no format requirements, length limits, or examples). With high schema coverage, the baseline score of 3 is appropriate.
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 states the tool's purpose as 'Add a new item to the inventory', which is a clear verb+resource combination. However, it doesn't distinguish this tool from its siblings (run_scenario_11422, etc.), which all appear to be scenario-based tools with generic names. The description is vague about what 'inventory' refers to in this specific scenario context.
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 provides no guidance on when to use this tool versus its sibling tools. There's no mention of alternative tools, prerequisites, or specific contexts where this inventory addition is appropriate. The agent must infer usage from the generic description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scenario Inputs All Types
| Name | Required | Description | Default |
|---|---|---|---|
| array_of_arrays | No | description | |
| array_of_collections | No | description | |
| boolean | No | ||
| collection | No | description | |
| date | No | description | |
| json | No | description | |
| number | Yes | required + default | |
| primitive_array | No | description | |
| select | No | ||
| text | No |
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 but fails completely. 'Scenario Inputs All Types' doesn't indicate whether this is a read or write operation, what kind of scenario is being run, what effects it has, or any behavioral characteristics like rate limits, authentication needs, or error conditions. This leaves the agent with no understanding of the tool's behavior.
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?
While technically concise (three words), this is a case of harmful under-specification rather than effective brevity. The description fails to convey necessary information and wastes its minimal word count on a tautological phrase. Every sentence should earn its place, but this description doesn't provide a single useful sentence.
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 complexity (10 parameters including nested objects, arrays of arrays, and collections), lack of annotations, absence of output schema, and presence of five sibling tools, the description is completely inadequate. It provides no context about what the tool does, when to use it, what behavior to expect, or how parameters relate to the scenario execution. This leaves the agent unable to properly understand or invoke the 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?
The schema has 10 parameters with 70% description coverage, but the description 'Scenario Inputs All Types' adds zero semantic information about any parameters. It doesn't explain what these inputs represent, how they relate to the scenario, or provide any context beyond what's minimally documented in the schema. For a complex tool with 10 parameters including nested objects, this is completely inadequate.
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 'Scenario Inputs All Types' is a tautology that restates the tool name 'run_scenario_11704' without specifying what the tool actually does. It doesn't identify a specific action (verb) or resource, nor does it distinguish this tool from its five sibling tools (run_scenario_11422, etc.). This provides no meaningful information about the tool's purpose.
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 provides absolutely no guidance on when to use this tool versus its five sibling tools or any alternatives. There's no mention of context, prerequisites, or distinctions between this and other scenario-running tools. The agent would have no basis for selecting this specific tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scenario Inputs: Array of Collections
| Name | Required | Description | Default |
|---|---|---|---|
| array | No |
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 fails to describe any behavioral traits—such as whether it's read-only or destructive, what permissions are needed, or what the tool outputs—making it impossible for an agent to understand how the tool behaves.
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?
While concise with a single phrase, it's under-specified rather than efficiently structured. The description lacks essential information, making it ineffective—conciseness should not come at the cost of clarity, and this text fails to earn its place by adding value.
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 complexity implied by 'run_scenario' and the lack of annotations, output schema, or schema descriptions, the description is completely inadequate. It doesn't explain the tool's purpose, behavior, parameters, or results, leaving critical gaps for agent invocation.
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 schema description coverage is 0%, and the description only vaguely references 'Array of Collections' without explaining what 'Collections' are, what the 'text' property means, or how the array should be structured. It adds no meaningful semantics beyond the bare schema.
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 'Scenario Inputs: Array of Collections' is vague and tautological—it restates the parameter name ('array') without specifying what the tool actually does. It mentions 'Scenario' but doesn't define what a scenario is or what action 'run' entails, failing to distinguish it from sibling tools like run_scenario_11422.
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?
No guidance is provided on when to use this tool versus alternatives. The description offers no context, prerequisites, or exclusions, leaving the agent with no basis to choose between this and sibling tools like run_scenario_11652 or run_scenario_11704.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dynamic Connections Testing
| Name | Required | Description | Default |
|---|---|---|---|
| AirtableConnection | No |
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 but fails completely. 'Dynamic Connections Testing' gives no indication of whether this is a read or write operation, what side effects it might have, what permissions are required, or what the expected behavior is. The agent has no way to understand what actually happens when this tool is invoked.
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 extremely concise (two words) but this brevity comes at the cost of meaningful information. While it's technically 'front-loaded' (there's only one phrase), it's so underspecified that it fails to communicate essential information about the tool's purpose and usage.
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 a tool with 1 undocumented parameter, no annotations, no output schema, and five similar sibling tools, the description is completely inadequate. It provides no meaningful context about what the tool does, how to use it, what parameters mean, or how it differs from alternatives. This leaves the agent unable to make informed decisions about tool selection and invocation.
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 1 parameter (AirtableConnection) with 0% description coverage, meaning the schema provides no documentation about this parameter. The description 'Dynamic Connections Testing' adds absolutely no information about what the AirtableConnection parameter represents, what format it expects, or how it relates to the testing operation.
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 'Dynamic Connections Testing' is vague and tautological - it essentially restates the tool name 'run_scenario_2361' in different words without specifying what action is performed or what resource is affected. It doesn't distinguish this tool from its five sibling 'run_scenario_*' tools, all of which presumably also involve some form of scenario testing.
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 provides absolutely no guidance about when to use this tool versus the five sibling tools (run_scenario_11422, run_scenario_11652, etc.). There's no indication of what makes scenario 2361 different from other scenarios, nor any context about appropriate use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scenario D - Subscenario
| Name | Required | Description | Default |
|---|---|---|---|
| text | No |
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. However, it offers no information about what the tool does (e.g., whether it runs a simulation, processes data, or performs another action), its effects, permissions needed, or any constraints like rate limits.
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?
While concise with only three words, the description is under-specified rather than efficiently informative. It fails to convey essential details, making brevity a detriment rather than a strength in this context.
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 lack of annotations, no output schema, and a parameter with 0% schema coverage, the description is completely inadequate. It does not compensate for these gaps, failing to provide any meaningful context about the tool's purpose, usage, or behavior.
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 one parameter ('text') with 0% description coverage, and the tool description adds no meaning about this parameter. It does not explain what 'text' represents, its format, or how it influences the tool's behavior, leaving the parameter entirely undocumented.
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 'Scenario D - Subscenario' is vague and tautological—it restates the tool name 'run_scenario_8632' without specifying what the tool actually does. It lacks a clear verb and resource, failing to distinguish this tool from its siblings (e.g., run_scenario_11422, run_scenario_11652).
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?
No guidance is provided on when to use this tool versus its sibling tools. The description does not mention any context, prerequisites, or alternatives, leaving the agent with no information to make an informed selection among similar-named tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0run_scenario_11422run_scenario_11652run_scenario_11704run_scenario_11707run_scenario_2361run_scenario_8632The tool names are entirely opaque, consisting only of scenario IDs like 'run_scenario_11422' with no indication of their distinct purposes. From the descriptions, some tools appear to handle inventory operations while others deal with scenario inputs or testing, but the naming provides no disambiguation, making it impossible for an agent to reliably choose between them without guessing.
All tool names follow a perfectly consistent pattern: 'run_scenario_' followed by a numeric ID. While this pattern is uninformative, it is uniformly applied across all six tools, with no deviations in style or structure.
With 6 tools, the count is reasonable and not excessive. However, given the unclear domain inferred from the tool names and descriptions—which suggest a mix of inventory management, scenario testing, and input handling—it's borderline whether this number adequately covers the scope, as the tools seem fragmented rather than cohesive.
Inferred domain includes inventory management and scenario testing, but there are significant gaps. For inventory, only list and add operations are present, missing update and delete. For scenario inputs and testing, the tools are vague and incomplete, lacking clear CRUD or lifecycle coverage, 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.
Give your AI agents the tools to build, manage, and run automation workflows.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
Connect your AI assistants to Keboola and expose your data, transformations, SQL queries, ...
Connect AI agents to Process Street workflows, tasks, runs, data sets, and operational records.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/integromat/make-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
