Make’s legacy plugin for ChatGPT should not be assumed available. Make’s September 16, 2026 article said the plugin was temporarily unavailable and directed readers toward MCP-based connections. Make now documents several MCP routes, but the reviewed evidence does not independently establish whether the legacy plugin listing is currently installable or when it might return. Check the live instructions for the specific ChatGPT account, workspace, and connection method you intend to use.
This guide separates the former plugin from current MCP options and focuses on the part that still matters after connection: turning a conversational request into a controlled, testable Make workflow. A chat request can describe a weekly report, for example, without proving that a recurring scenario exists or is active. The scenario, schedule, permissions, data contract, and execution state must be verified in Make.
The examples below are proposed workflow designs, not verified Make templates or guaranteed combinations of app modules. They show how to define the trigger, inputs, bounded AI task, validation gate, destination, and human exception path before implementation.
ChatGPT can be a control surface, but Make remains the place to verify the active scenario, schedule, permissions, and execution state.
Is the Make plugin for ChatGPT currently available?
Make’s article reports that OpenAI temporarily disabled the plugin while updating automation-tool support and points readers toward MCP setup. That is Make’s statement, not an independent OpenAI confirmation. Make’s current documentation explains MCP connectivity, but the sources reviewed do not establish the legacy plugin’s present marketplace status or a restoration date.
Before following any setup instructions, check the live Make documentation and the intended ChatGPT account or workspace. Do not rely on old plugin-directory steps, an @ mention, or a plus-menu instruction unless the corresponding listing and interface are actually available. If the legacy listing is unavailable, choose a documented MCP method supported by the client and workspace.
Useful starting points are Make’s article about the ChatGPT plugin, the Make MCP Server documentation, and Make Community’s supplementary connection guide for ChatGPT and Codex. Use the Developer Hub for authoritative details about MCP capabilities and scopes. Product availability, workspace controls, and write capabilities can change, so verify the target account immediately before setup.
Plugin, MCP server, and MCP toolbox are different setups
The legacy plugin was a particular product interface described in Make’s article. MCP, or Model Context Protocol, is a protocol through which a compatible AI client can call authorized tools. The terms are related, but they do not describe one interchangeable installation.
- Make MCP Server: Make documents tools for running scenarios and tools for managing account contents. The available actions depend on authorization scopes. Scenario-running access is documented for all Make plans, while management tools may require a paid Make plan.
- MCP toolbox connection: Make’s ChatGPT toolbox guide describes a separate connection flow using a toolbox URL, key, transport path, and no-auth setting. It should not be treated as installation of the former plugin.
- MCP-token connection: Make’s token-based ChatGPT instructions describe another setup using a Make MCP token and ChatGPT Developer Mode. That guide lists a paid ChatGPT subscription prerequisite, which should not be generalized to every MCP route.
ChatGPT-side support also varies. OpenAI documents MCP read, write, and modify capabilities as dependent on rollout status, plan, app, account, workspace controls, and permissions. A client that can read results may not be able to perform the management action you want. Confirm the required capability before promising that ChatGPT can create, modify, or delete Make configuration.
Also distinguish a ChatGPT confirmation from a workflow approval. OpenAI may require confirmation for some write actions, but that does not replace validation, approval states, or exception ownership inside Make.
Prepare the Make connection before asking AI to build
Start by deciding what kind of operation you need:
- Scenario run: invoke an existing scenario with defined inputs.
- Scenario management: inspect or change Make configuration, depending on the connection’s scopes and plan.
- Recurring automation: run independently on a time schedule, webhook, or other trigger.
Record the target Make organization, the source and destination accounts, the required actions, and the permissions or scopes involved. This matters especially when a user belongs to more than one Make organization. The connected AI client may receive data returned by authorized tool calls, so review both what the scenario writes and what it returns.
For a scenario exposed as an MCP tool, Make documents requirements including an active scenario, on-demand scheduling, and defined scenario inputs and outputs. On-demand scheduling means that the scenario waits for an API call or a manual Run once action. It is not the same as a weekly or daily time schedule. If the workflow must run every Friday, configure and verify that recurring schedule separately. See Make’s guidance on using scenarios as MCP tools and scheduling scenarios.
Turn a plain-language request into a testable workflow contract
Describe the operating sequence, not only the desired outcome:
Trigger and source → received fields → bounded AI task → structured output → deterministic validation → destination action → exception owner.
AI is useful for summarizing updates, extracting intent, classifying text within an allowlist, or drafting a response. Use explicit rules for required fields, permissions, duplicate detection, destination IDs, opt-outs, allowed categories, and irreversible actions. Treat AI output as an intermediate result that must be checked before it reaches a customer record, task system, email platform, or database.
Make documents typed scenario inputs and outputs, including fields such as text, numbers, dates, email addresses, collections, and arrays. The following is an editorial example of an input contract, not a Make-published schema or template:
{
"submission_id": "submission-591",
"source_system": "intake-form",
"received_at": "2026-10-09T15:00:00Z",
"request_text": "Please arrange a site visit.",
"customer_email": "[email protected]"
}A corresponding output should make the result explicit. For example, return the source identifier, an allowed category, a review status, and a reason when review is needed. Validate required fields, permitted values, maximum lengths, and destination mappings before a write. Typed input validation does not automatically validate an AI-generated output. See Make’s references for scenario inputs and outputs and using and validating scenario inputs.
Three practical workflow patterns to adapt
These patterns are illustrative architectures. They are not official templates, and the exact app modules, authorization requirements, rate limits, and write behavior must be checked for the selected systems.
| Trigger and source | Bounded AI task | Validation and action | Fallback owner |
|---|---|---|---|
| Weekly status report: Make time schedule, then read authorized project updates for a defined reporting period. | Summarize validated updates into themes and blockers. Do not infer status from missing records. | Check period, project scope, source count, and destination permissions. Save to an authorized reporting destination and return no_updates when the source is empty. |
Project or operations owner reviews missing or out-of-scope data before sharing the report. |
| Lead-response draft: New lead or inbox event, then retrieve approved availability. | Extract intent and draft a response using current approved information. Do not send or promise unsupported times. | Deduplicate the event, check contact fields and sensitive content, and save as a draft or review item rather than sending automatically. | Sales or customer operations reviews ambiguity, missing details, sensitive content, or unavailable calendar data. |
| Form-to-task routing: New form submission or webhook, then check fields and classify only when rules cannot settle the category. | Return an allowed category and short rationale, not an unconstrained destination instruction. | Validate required fields, allowed priority, destination ID, and unique submission key before creating the task. | Intake or operations quarantines malformed submissions, unknown categories, invalid mappings, and repeated events. |
1. Weekly status report
Use a time-based Make schedule to collect source records for an explicit period, normalize project identifiers and dates, check the source count, and then ask the bounded AI step to summarize only the records received. A useful output contract includes report_period_start, report_period_end, source_record_count, summary, blockers, and result_status.
If the source contains no records, return no_updates rather than a polished report that implies activity. If records fall outside the requested project or period, route the result to the project owner instead of silently including them. The report is an aggregate, so do not use its date as the identity of every underlying update. Keep source record IDs available for reconciliation.
2. Inbound lead response draft
Start with a verified lead or inbox event containing a source-system name, source event ID, contact identifier, received timestamp, message body, and permitted availability data. The AI step can extract intent and prepare draft text, but it should not independently promise an appointment or send a message.
Before saving the draft, check whether the source event has already been handled, whether required contact fields exist, whether availability data is current, and whether the message contains sensitive or ambiguous content. Store a review status such as needs_review or ready, the reason for review, the source event ID, and the processing run ID. A human reviewer approves the message before any separately authorized send action.
3. Form submission to task routing
Accept a form or webhook event with a submission ID, form version, timestamp, request text, and requested priority. Use deterministic rules for known categories. If free text requires classification, constrain the AI output to configured category and priority allowlists, then validate the destination project or list ID before creating a task.
Malformed events should be quarantined for an operator rather than forced through the normal route. The task record should retain the submission ID and processing run ID so an operator can distinguish a repeated event from a new request. A destination-side uniqueness rule or equivalent idempotent write should prevent the same submission from creating multiple tasks.
Prevent duplicate writes and make failures diagnosable
Choose an identity key that matches the row grain. For an incoming event, use a source namespace and source event or submission ID. For one Make execution, use the Make execution ID. For a citation observation, use the run ID, prompt ID, citation URL, and citation position if those observations are stored. For a weekly report, use the reporting period, project scope, and report run, because an aggregate report is not the same row as an individual source update.
These are proposed implementation keys, not vendor-published schemas:
source_event: unique onsource_systemplussource_event_id.scenario_run: unique onmake_execution_id.citation_observation: unique onrun_id,prompt_id,citation_url, andcitation_position.reported_summary: unique on the reporting period, scope, and report run or version, rather than on a generic date.
A search-before-create check is not race-safe: two concurrent runs can both find no matching record and then both create one. Use a destination-side unique constraint with an atomic upsert, or another durable idempotency mechanism that serializes the write. A prior lookup alone is not sufficient.
Keep a readable processing state such as received, needs_review, approved, written, retry_pending, or failed. Store the source event ID, processing run ID, and destination record ID where available. This lets an operator distinguish a repeated event from a failed write, a retry, or a result waiting for approval.
Make documents error handlers and automatic retries for selected failure types, including some rate-limit, connection, and module-timeout errors. Retry eligibility, delays, parallel retry limits, and outcomes depend on the failure and scenario configuration. An automatic retry is not manual remediation. Assign an owner for unresolved executions and check the configured path in Make. See the documentation for error handlers and automatic retries of incomplete executions.
Verify the scenario in Make, not just in the conversation
Run at least one representative valid input, one missing-field case, one duplicate event, and one ambiguous AI result. Inspect the actual scenario in Make, including connections, field mappings, inputs, outputs, schedule or on-demand setting, active state, error path, and destination permissions.
Confirm that the test wrote to the intended organization and destination. Then verify the live trigger or recurring schedule separately. A successful tool call proves that a call returned a result; it does not prove that a recurring schedule is enabled or that production exception handling is complete.
Make describes the former plugin as returning reviewable results. Current MCP documentation supports structured scenario inputs and outputs, but the reviewed sources do not independently establish that every current MCP client reproduces the former plugin’s searchable tables, pagination, status badges, or execution-history interface. Use the output and execution information actually exposed by the selected connection method, and inspect the scenario itself in Make.
- The authenticated Make organization and source and destination accounts are correct.
- The trigger, recurring schedule, webhook, or on-demand mode matches the intended operation.
- Inputs and outputs are defined, and AI results are checked against required fields and allowlists.
- Valid, incomplete, duplicate, and ambiguous cases have been tested.
- The destination write uses a durable uniqueness or idempotency strategy when concurrent runs are possible.
- An exception route exists with a named person or team responsible for unresolved cases.
When to get help with a Make workflow
Specialist workflow design is useful when an automation writes customer or operational records, handles concurrent events, crosses several systems, or needs controlled review and an audit trail. Make automation design and implementation can help turn the process into an owned, monitored scenario. Consider AI agent design only when the bounded language task genuinely needs an agent rather than deterministic rules and scenario steps.
The practical answer is to verify the legacy plugin’s live status in the target account, select the documented MCP route that fits the client and workspace, define a testable workflow contract, and verify execution, scheduling, permissions, deduplication, and exception handling in Make.
