I am reporting this as a migration problem that needs to be resolved, not as a general question about how to build an MCP server.
I operate a small business and have spent months building a multi-agent system using Custom GPTs. I also teach AI and technology to business owners and have helped other businesses build similar agents.
One of my production agents is an Executive Email Manager called Beacon.
Before migration
Beacon had a working Custom Action that connected to a Make dot com webhook and retrieved email from an IONOS mailbox via IMAP.
The architecture was:
Custom GPT → Custom Action → authenticated Make webhook → IONOS email
The Make webhook uses API-key authentication through the x-make-apikey HTTP header.
This worked.
After the official Custom GPT → Plugin migration
The Custom Action did not migrate.
The migrated Beacon Plugin retained its instructions and Knowledge, but lost the external capability required for its core function: reading the business mailbox.
I therefore attempted to rebuild the integration using the new Plugin/MCP architecture.
Make supports MCP Toolboxes, and I successfully:
-
Created/configured a Make MCP Toolbox.
-
Added the existing email scenario to it.
-
Confirmed the scenario is active and configured for On-demand execution.
-
Created a dedicated MCP Toolbox key.
-
Preserved the existing working IONOS/IMAP connection.
The remaining problem is authentication from the migrated ChatGPT Plugin.
The migration blocker
The Plugin configuration supports an HTTP MCP server and documents bearer_token_env_var for bearer authentication.
However, the current ChatGPT Plugin Creator provides no protected interface for the Plugin owner to supply that environment variable/secret.
Plugin Creator itself confirmed that bearer_token_env_var expects the named environment variable to exist in the session/runtime environment and that there is no protected Beacon interface where I can enter the Make Toolbox key.
Embedding the Toolbox key directly in an MCP URL or Plugin package is not an acceptable solution for a production business integration.
So I am left with this situation:
Before migration:
Custom GPT → authenticated Action → Make → IONOS
WORKING
After migration:
Plugin → MCP → authentication credential required → no supported owner-facing secret-entry mechanism available
NOT WORKING
Why this is a migration issue
This is not simply a request for a new Plugin feature.
The official migration removed an existing, working production capability without providing an equivalent supported method to restore the authenticated connection.
The agent technically “migrated,” but it is no longer functionally equivalent to the Custom GPT it replaced.
This affects more than one experimental GPT. I have built a substantial business agent system and have also helped other businesses create agents that rely on authenticated Actions.
A migration cannot reasonably be considered successful if an agent’s instructions and Knowledge migrate while the external integrations required to perform its actual job are removed.
What is needed from OpenAI
There needs to be a supported migration path for Custom GPT Actions that require API keys or other static credentials.
At minimum, Plugin owners need one of the following:
-
A protected secret/credential interface in Plugin Creator that can populate
bearer_token_env_var. -
A vault-backed credential mechanism accessible to migrated Plugins.
-
A supported equivalent of Custom GPT Action authentication for migrated Plugins.
-
Automatic or guided conversion of existing authenticated Actions into the appropriate Plugin/MCP configuration.
This needs to be addressed as a Custom GPT → Plugin migration compatibility problem.
Builders should not be required to deploy an additional third-party MCP proxy/server solely because the migration removed the secure credential mechanism their existing Action already used.
Questions for OpenAI
What is the supported migration path for an existing Custom GPT Action using API-key authentication when the migrated Plugin requires an MCP bearer token but Plugin Creator provides no protected interface for supplying bearer_token_env_var?
And:
Is OpenAI planning to add a protected credential/secret interface to Plugin Creator before existing Custom GPTs are retired?
This is currently preventing a production business agent from performing a core function that worked before migration.