Make MCP Client lets Make scenarios and AI Agents call tools hosted by a compatible external MCP server. A workflow might pass a CRM record ID to an agent, let it use an external read tool to retrieve relevant information, then validate the proposed fields before a configured CRM action writes them. Make does not host that external service for you, and compatibility depends on the specific server, authentication method, transport, and tool schema.
MCP, or Model Context Protocol, provides a standard way for AI systems to access tools. The client direction means Make calls a remote MCP server. The most clearly documented Make setup is adding a third-party MCP connection to the Make AI Agent (New) > Run an agent module. Make’s product article also describes a generic MCP Client module, but its overview does not establish every field or behavior for every server and module version.
Use MCP when a workflow needs a capability exposed by a reachable external MCP server and that capability is not conveniently available through a native Make module or direct API. Start with the business process, system of record, required fields, and exception owner. Add MCP only when it supplies a capability the process actually needs.
What Make MCP Client does
Make MCP Client connects a Make scenario or agent to tools exposed by an external MCP server. Depending on the server, a tool may retrieve information, transform data, or perform an action. The remote provider remains responsible for operating a reachable and compatible server.
Make’s MCP Client overview describes visual tool configuration and external connections. The current AI Agent guide separately documents adding third-party MCP servers as agent tools. These sources support the product direction and the AI Agent setup path, but they are not a complete technical specification for every generic MCP Client behavior.
Make’s product material names GitHub, Webflow, PayPal, Asana, and LangChain-hosted tools as examples. Treat those as examples rather than verified universal integrations. Before deployment, test the actual remote server, endpoint, credentials, transport, available tools, limits, and returned data.
MCP Client versus MCP Server: which direction does data travel?
Make MCP Client and Make MCP Server describe opposite connection directions. MCP Client lets Make call tools outside Make. MCP Server lets an external MCP client call eligible Make scenarios and, where permitted, other Make tools.
| Capability | Caller | Tool location |
|---|---|---|
| Make MCP Client | Make scenario or agent | External MCP server |
| Make MCP Server | External MCP client | Make scenario or eligible Make tools |
For the reverse direction, Make requires a callable scenario to define inputs and outputs, be active, and use on-demand scheduling. Make documents scenario-run scopes on all plans and management scopes on paid plans. See the MCP Server setup guidance and Developer Hub reference for those requirements.
Choose the direction by asking who calls the tool: Make calling a remote tool is the Client direction; an external client calling a Make scenario is the Server direction.
These are separate configurations, not a guarantee of a fully bidirectional connection. Combine them only when both directions are required and each side has been configured and tested independently.
Add an external MCP server to a Make AI Agent
The current documented AI Agent flow is:
Make’s product article says the MCP Client discovers tools and presents their inputs visually. Confirm the exact behavior for the selected server and current module version rather than assuming that every server exposes compatible schemas. Authentication also depends on the external server. Make describes OAuth and token-based authentication for MCP connections, but the available method is determined by the server and its supported transport.
Design the action before connecting the tool
Define the workflow before giving an agent access to an action: trigger or source, necessary input fields, bounded AI responsibility, structured result, deterministic validation, destination action, and named exception owner. Use a Make filter or router when the decision is explicit, stable, and auditable. AI is more suitable for unstructured extraction, classification, summarization, or ambiguous matching.
Treat an agent result as a proposal, not authorization. Let deterministic rules decide whether the target, fields, state transition, and permission are valid before a write-capable Make action runs.
For a write operation, an implementation may record request_id, source_system, source_record_id, target_system, target_record_id, tool_name, tool_arguments, authorization_state, validation_state, approval_state, idempotency_key, provenance_url, timestamps, outcome, and error details. This is a proposed application record, not a Make-prescribed schema. Store large or sensitive raw responses separately with appropriate redaction and retention controls.
Require explicit review for refunds, payments, deletion, external communications, regulated fields, customer-visible status changes, and uncertain entity matches. The reviewed Make documentation does not establish a universal built-in approval gate for MCP actions. The scenario or destination system must provide that control.
For AI agent design and implementation, the agent’s permitted tools, output contract, validation rules, and exception owner should be part of the design before connection setup.
Hypothetical pattern: enrich a CRM record from an external tool
This is an illustrative architecture, not an official Make template or a verified GitHub-to-CRM integration. A CRM record needs enrichment. A Make scenario supplies a stable source record ID and only the lookup context required by the selected external read tool. The agent retrieves candidate information and returns structured fields. Make validates the proposal, then either invokes an explicitly configured CRM action or routes the case to a review queue.
- Input: a CRM source record ID and minimal lookup key. The CRM is the system of record, and its process owner handles write-back and exceptions.
- AI task: use the selected external read tool and return candidate values, source information, and a review state. The agent does not independently authorize the CRM write.
- Validation: match first on a stable external ID, validate required fields and allowed values, verify source freshness, and check that the CRM record has not changed since retrieval.
- Destination: a configured Make CRM action writes an approved result, or the scenario sends ambiguity, rejected values, and failed reconciliation to a named human owner.
One JSON object below represents one proposed enrichment operation for one CRM source record. It is not an agent-run summary, daily report, or aggregate. The fields are illustrative application fields, not vendor-required MCP fields.
{
"operation_id": "crm-enrichment-illustrative-1042-run-01",
"source_system": "crm",
"source_record_id": "crm-record-illustrative-1042",
"retrieved_object_id": "external-object-illustrative-88",
"tool_name": "external-read-tool",
"retrieved_at": "2026-01-15T10:30:00Z",
"proposed_fields": {
"company_type": "Illustrative candidate value"
},
"provenance_url": "https://example.invalid/source-record",
"review_state": "review_required"
}The operation_id identifies one operation row. A separate per-tool-call row should identify each request and response, while an agent-run row identifies the overall execution and an aggregate row reports a defined period or grouping. Do not use date plus tool name as a unique ID when multiple runs, model variants, or citations can occur on the same day.
For concurrent processing, generate an idempotency key from the correct business grain, such as source_system + source_record_id + action_type. Enforce uniqueness in the destination or durable store, or use a transactional upsert where available. A lookup followed by create is not sufficient because two workers can both observe that a record is absent and then create duplicates. A uniqueness conflict should enter an existing-success or reconciliation path rather than automatically becoming a new operation.
A CRM systems design may benefit from CRM systems consulting when the source identity, destination ownership, and write-back rules cross system boundaries.
Choose MCP, a native Make module, or a direct API
Choose the simplest mechanism that meets the requirement.
- Prefer a native Make module or direct API when the endpoint and payload are stable, the workflow is deterministic, the operation is high volume, latency matters, or strongly typed validation is required.
- Consider MCP when an agent needs to select among described tools or when the required capability is exposed by an external MCP server rather than a standard Make app.
- Use a controlled hybrid when an agent interprets unstructured input but a native module, filter, router, or direct API performs the final deterministic action.
Make has announced an Execute an action with AI feature in the MCP Client app. The announcement supports the feature’s existence and describes AI selecting an MCP action, but it does not establish exact inputs, outputs, confidence scores, approval controls, retries, or idempotency. Treat the selected action as a proposed operation until the surrounding workflow supplies those controls.
Make advertises thousands of integrations, but promotional counts vary. Use the current integrations directory for a live count rather than repeating an outdated fixed number. An app count does not establish compatibility with a particular MCP server or action.
Operational controls: retries, duplicates, access, and ownership
Before production, minimize selected tools and supplied data, identify the system of record, and retain enough redacted detail to reconstruct each operation. Useful fields include the server and tool, request or run ID when available, redacted arguments, source and target identifiers, validation and approval states, timestamps, response status, and error details. Assign an exception owner who can reconcile an uncertain outcome.
Make documents asynchronous timeout behavior for calls into Make MCP Server. Under the documented conditions, a timed-out scenario-run call can continue and return an execution ID for later retrieval. Do not generalize those Server details to external servers called through MCP Client. Check the external server’s behavior and the destination state before retrying a write.
- The selected server, tool, credentials, and supplied data are limited to the task.
- A named system of record and exception owner are documented.
- Stable identifiers, required fields, allowed values, and authorization checks are enforced.
- Concurrent duplicate handling uses destination uniqueness or a transactional upsert where available.
- Consequential or ambiguous actions have an explicit approval route.
- Per-tool-call, per-agent-run, and aggregate records use separate grains.
- Logs retain redacted arguments, provenance, result status, and timestamps.
- Timeout reconciliation checks execution or destination state before a retry.
For teams connecting tool configuration to process ownership, validation, and exception handling, Make automation consulting is an optional implementation resource.
Availability and claims to verify before rollout
Make’s product overview and Help Center serve different purposes. The overview describes general MCP Client behavior, while the Help Center provides a documented external-tool setup path for AI Agents. Publish the AI Agent sequence as the verified procedure. Qualify broader claims about generic tool discovery, schema rendering, authentication, security, reliability, and compatibility.
A newer Make editorial article states that MCP Client and MCP Server are included on every plan, including Free. The reviewed Help Center material does not provide a complete MCP Client plan-and-limits matrix, so check the current account interface and plan terms before rollout. Standard scenario execution usage may still apply.
For a specific external server, verify its endpoint, transport, authentication method, reachability, available tools, rate limits, data handling, and error behavior. Test with non-production data where possible. Do not assume that an example named in Make’s product material is a verified end-to-end integration or template.
In short: Make MCP Client is a route for Make workflows and agents to use compatible external MCP tools. The documented AI Agent path provides a practical starting point, while dependable operations require limited tool access, structured outputs, deterministic validation, durable deduplication, timeout reconciliation, and a clear owner for exceptions.
