Make MCP Server is Make-hosted infrastructure that lets a compatible AI client discover and call permitted Make tools, including eligible scenarios. The client discovers a tool description and input schema, submits arguments, Make runs the permitted scenario, and configured outputs return to the client.
That connection is not a complete automation design. Scenario inputs, outputs, permissions, validation rules, destination-system behavior, and exception ownership determine whether the call is useful and safe. Make documents scenario-run tools on all plans, while management tools for Make resources require a paid plan. MCP provides a standardized way to discover and call tools, but it does not guarantee accurate AI decisions or standardize every detail of an underlying app API.
Make currently documents stateless Streamable HTTP as the default transport. Exact connection steps still depend on the client’s supported authentication, transport, and MCP behavior. Use the current Make MCP Server documentation as the technical starting point.
MCP exposes a way to call a workflow. The scenario’s inputs, outputs, permissions, and decision rules determine whether that call is operationally useful and safe.
What Make MCP Server does
There are three different operating models to distinguish before building anything:
- Scenario tools: An external AI client calls an active, on-demand Make scenario with defined inputs and receives its configured outputs.
- Management tools: A permitted client can work with Make resources such as scenarios and related account resources, subject to plan and access conditions. Management access is broader than permission to run one workflow.
- Make AI Agent tools: A Make AI Agent can use scenarios internally. This is not the same connection model as an external client connecting to Make MCP Server.
For scenario tools, Make says the scenario must be active and configured for on-demand scheduling to be discoverable. Define the values the AI must provide, write a detailed scenario description, and configure the outputs the AI should use. A useful structured result depends on those output choices. It is not guaranteed merely because a scenario is exposed through MCP.
Choose OAuth or an MCP token
Make supports OAuth and MCP-token connections. Prefer OAuth when the client supports it and interactive consent suits the deployment. Use a token when a token-based integration is required, but treat it as a secret API key rather than a harmless share link.
- OAuth: Make documents
https://mcp.make.comas the universal connection URL. During setup, select an organization and scope. The Run your scenarios scope provides access to active, on-demand scenarios in the selected organization. Make documents more granular team-based control for Teams plans or higher. See the OAuth setup guide. - MCP token: A token connection uses a Make-zone URL and a token. Make documents the default
mcp:usescope as permitting access to active, on-demand scenarios across the user’s Make organizations unless access is restricted. See the token guide.
For token access, Make documents organization-, team-, and scenario-level restrictions for scenario tools. Those restrictions do not apply to management tools. Review the scenario access-control guide before deciding that a token has sufficiently narrow reach.
Start by listing the exact scenarios the client needs. Select the organization, scope, and connection method that expose no more than that operational job requires. Store tokens in a secrets system, keep them out of prompts, tickets, source code, and shared documents, and review access when ownership or client requirements change.
Prepare scenarios before connecting a client
Prepare and test the scenario before configuring the external client. Define inputs for values the AI must supply, explain the scenario’s purpose in plain language, and configure explicit outputs. Validate missing, malformed, ambiguous, and out-of-range values inside the scenario before any destination write.
For a Make AI Agent, scenarios can instead be added as internal tools. Make’s AI Agent guidance says to define inputs and outputs and use a Return outputs module when the scenario needs to return data to the agent. Make also recommends limiting the MCP servers and tools supplied to an agent because additional tools may increase token usage.
These are separate operating models: an external client connects to Make MCP Server, while a Make AI Agent uses scenarios within its agent workflow. Do not copy a client-specific procedure, such as a Claude Code command, into instructions for every Claude product or every MCP client.
Make documents a default maximum generated tool-name length of 56 characters and a configurable maxToolNameLength range of 32 to 160. This may matter when scenario names are long or a client imposes its own naming limit. Check the selected client’s current requirements instead of assuming one product’s setup applies to another.
Design the tool contract and operating workflow
Let the AI interpret a request and fill defined fields. Let deterministic workflow logic decide whether the record exists, the action is permitted, values are allowed, a transition is valid, an approval is present, or a duplicate already exists. Required-field checks, authorization, status transitions, and duplicate detection should not depend on an unverified AI interpretation.
The following is a proposed CRM-update contract, not a Make-generated schema or reusable template. The CRM remains the system of record. The AI proposes fields for a stable customer ID; the scenario validates the request and writes only an allowed change.
{
"input": {
"request_id": "req_8b10",
"source_event_id": "ticket_55019",
"customer_id": "cus_10482",
"requested_action": "update_lifecycle_stage",
"fields_to_change": {
"lifecycle_stage": "qualified"
},
"approval_status": "approved",
"dry_run": false
},
"output": {
"status": "succeeded | rejected | needs_review | failed",
"destination_record_id": "cus_10482",
"changed_fields": ["lifecycle_stage"],
"retryable": false
}
}A practical sequence is: the client submits defined fields; the scenario validates the identifier, allowed fields, current CRM state, and approval status; only then does it write to the CRM and return a status and destination record ID. An ambiguous identifier, forbidden transition, unknown field, or missing approval should produce rejected or needs_review, not a guess. A named CRM operations owner handles review cases, while the integration owner investigates failed writes.
Read-only lookup pattern
Keep lookup tools separate from write tools. A proposed lookup scenario might accept request_id, a stable customer_id, and a list of permitted fields. It validates the identifier, confirms that the record exists, checks that each requested field is allowed, and returns only selected data.
A useful output could distinguish succeeded, not_found, rejected, and failed. The CRM or data-system owner handles missing records, access denials, and repeated lookup failures. A client that only needs information should not receive a broad mutation tool.
Controlled write pattern
For writes, use a stable business identifier and an explicit action. A proposed side-effect key is source_system + source_event_id + action_type + destination_record_id. This is an implementation recommendation, not a built-in Make MCP feature.
Keep identifiers at their actual grain. A prompt, tool call, Make execution, source event, destination write, and returned citation are different records. An execution log might use request_id + execution_id, while a destination-write record uses the source event and action identity. If concurrent calls could create duplicates, enforce uniqueness in the destination and use a transactional upsert where supported. A lookup followed by a create is not race-safe by itself.
Handle timeouts, retries, and permissions deliberately
Make documents output-return limits of 25 seconds for the OAuth URL and 40 seconds for the MCP-token URL. A response timeout does not necessarily stop the scenario. Make says the scenario may continue running for up to 40 minutes. When an executionId is returned, retain it and retrieve the result using that ID and the corresponding tool.
Treat an unresolved call as pending, not failed. Retrieve an available execution result before retrying. If a write’s completion remains unknown, check the destination or its idempotency record before sending another side-effecting call.
An AI client may retry after a delay, and that retry can send a second message or create a second record. Retry only when the failure is understood and the operation is idempotent. If the execution cannot be retrieved or the destination state remains ambiguous, the integration owner investigates and the business owner decides how to resolve the work.
Where auditability matters, record a request ID, execution ID, source-event ID, action status, and destination record ID. Do not collapse these into one universal identifier. A raw execution record describes one Make execution; a destination-write record describes one attempted or completed business write.
- Restrict scenario visibility by organization, team, or scenario where the connection method supports it.
- Review whether the client actually needs management tools.
- Store MCP tokens as secrets and limit who can retrieve them.
- Return only the customer data required for the task.
- Assign owners for rejected, pending, failed, and high-impact requests.
- Limit tools supplied to an AI Agent to those required for its current job.
Questions to settle before launch
Confirm that the client supports the selected authentication and transport. Check which organization and scenarios it can see, whether inputs and outputs are explicit, and how it handles execution-result retrieval. Decide who owns pending or rejected calls, how duplicate side effects are prevented, and which actions require human approval.
Measure outcomes that fit the deployment, such as valid-call rate, validation rejections, pending-call resolution, duplicate side effects, and human-review volume. These are suggested operational measures, not vendor-reported results.
Use the current Developer Hub documentation rather than copying the former Make Cloud MCP Server page, which Make identifies as outdated. Make’s customer-feedback, capacity-check, reminder, email, and CRM examples are illustrative use cases, not complete independently verified templates.
Start with tool discovery and a read-only scenario. Then test a reversible write, including duplicate-call and timeout cases, before exposing higher-impact actions. If you need help designing permissions, scenario contracts, and exception ownership, see Make automation services.
