When submitting an updated version of my ChatGPT app, I encountered some confusion while filling out the MCP Server section.
What should be entered for the MCP Server URL? Should it be the same as my current ChatGPT app URL?
If it is the same, does that mean I need to upgrade my backend MCP Server to the new version at the time of submitting the update?
If I do not upgrade the MCP Server in advance, then the content I provide in the “Tool Justification” section will not match what reviewers actually see, since the server would still be running the old version.
However, if I upgrade the MCP Server when submitting the new version, that effectively means the new version is already live before approval is completed.
Could you please advise on the correct approach in this situation?
Hi! You’re free to use whatever versioning strategy you’d like, and the URL doesn’t have to stay the same across versions to my knowledge.
Generally, though, I see teams adopt a versionless policy–new endpoints tools can be added, but old ones not removed for some time (usually 2-3 submission versions back) to allow for transition. The URL does not change across versions in this scheme.
Your MCP server tool schema is snapshotted at the time of submission, but is not served until publication. That’s to say, your tools/list response is locked at time of submission, but all actual tool calls still make their way to your live server.
Hi case, I’m working on this very issue. We’ve already published our app and it’s available on ChatGPT. Now we want to make changes to our tools, just the descriptions, to improve the hook and make them easier for ChatGPT to recognize. But I’m not sure if I should create a new branch and submit it as version 1.1 to the app submission for review, or if I can publish directly to production? What happens if I have an updated version in production without having yet confirmed changes in a submit within the OpenAI panel and had the changes validated?
If you’re just changing tool descriptions, make the changes in prod and submit the new version. We continue serving the old tool descriptions until the new version is released.
Sorry, what is the expected behavior regarding resource versioning?
We noticed that resources were initially cached very aggressively (we actually thought they were simply stored as is), so we implemented a cache-busting mechanism by versioning resources (for example, by including a hash in the resource identifier).
This approach worked well in the past: after submitting an app update, ChatGPT would eventually refresh the resource and start using the new version. Recently, however, we’re seeing resources being invalidated before the app submission is approved and rolled out. As a result, ChatGPT attempts to load a resource that is no longer available.
Should we assume that tool descriptions are persisted once fetched, while resources are only cached temporarily and may be revalidated or refreshed independently of the app submission lifecycle?
What I am observing now is that even though I have submitted a new version, updated the input_schema, added new tools, and updated the MCP Server, the new functionality has not taken effect and the new tools cannot be triggered.
This suggests that the system is still using the old cached version and is not parsing or invoking the newly added tools. My assumption is that the new tools will not become available until the new version has been approved.
Fortunately, we made the schema forward-compatible; otherwise, users invoking the old tools would also run into errors.
Our app has now been under review for two weeks and has still not been approved. It is possible that the review timeline has become longer again.
I’m looking into this and will get back to you when I find something!
Unfortunately yes, app submission volume has increased greatly in the past couple weeks and we are spinning up resources to handle it, but it will take 2-3 more weeks for them to come fully online sadly.
Sorry Casey, I didnt get it.
Which one is the correct behavior moving forward?
a) Resources are part of the tools descriptions and therefor “stored” as part of a version
or b) Resources can be fetched at any time
Is there a way to get the draft version in advanced (corresponding to pre-release version) via ‘client version’? We have breaking change in the same tool input/output schema which need reliable version to route to the correct mcp server upstream.
Currently we use URI Path-Based Versioning but the submission page is having a bug on oauth which don’t allow us to change the URI path.
We also try to get the clientInfo.version but it seems “Scan tools” at draft time always send the previous version (1.0.0 for our case). Is it possible to create version for draft to make it more reliable to detect clientInfo.version prelease?
Hi Casey, what I mean is when user create a new draft, would be great to have a form to declare the version in advance (similar to Apple Appstore). You can also pump the version automatically as a fallback when user create new draft. Then that version would be sent to the mcp server when initialize connection.
The reason I’m asking this is because of the cache you have for resource and tool definitions. If a tool input/output schema is updated; it’s not easy to safely write backward compatible code without storing a flag somewhere. The same thing happen when a tool is removed (deprecation can works but will be additional tool in the tool list).
Any suggestion on how to safely rollout without breaking the existing app would be appreciated.
Hi Casey, do we have any updates on when this fix will be available?
We want to send a new version to review but we are waiting on this input to plan it properly. Thanks
We currently have version 1.0.0 of an app published. We recently submitted a new version of the MCP for publication, and we’ve noticed that the resources from this new version are being downloaded instead of the resources from the currently published version, 1.0.0.
To clarify: in the new version of the app, we updated a resource that is also used by version 1.0.0. However, the updated resource from the new version is now being used, rather than the resource from the published 1.0.0 app.
Could you also clarify how resources are fetched? Based on our testing in developer mode, resources are downloaded only when a new app is created or when the app is manually refreshed. In our case, each resource is an HTML file. However, perhaps production mode works differently, and resources are downloaded when the user requests them. That would explain the behavior we are currently seeing.
