Automatic scans fail for app with OAuth connection

Our functioning published app (submitted by form in April & live since June) has been failing daily plugin scans. It appears scan is trying to do open discovery on our MCP server even though it is OAuth only. Are other early app owners experiencing this?

From email: “We couldn’t scan asdk_app_699f1bb1c5ac819182dfee0b2d2ed99f because its MCP server authorization is missing or no longer works.”

The MCPs entry for our app on the new plugins view looks weird… “MCP configuration incomplete”, “Untitled app” instead of proper name, etc. Maybe a problem with migration of older apps? I downloaded the zip from the “…” at top of page and it only contains plugin.json, no mcp.json. Not sure what’s expected. I do not see anywhere to update the MCP configuration it indicates is incomplete.

From View Plugin, I confirmed my app is connected (I’ve reconnected multiple times to different accounts here) & attempted rescans which fail. I’ve also uninstalled/installed app with same results. This correctly shows we use OAuth, not mixed:

What we see in our logs on scan:

  1. Connect succeeds: authorize, login, POST /oauth/token (authorization_code, PKCE verified, refresh_token returned), then /oauth/userinfo called once or twice, all 200.
  2. On scan, the scanner sends a tokenless server/discover. We answer 400 with a non-modern body (the spec’s legacy fallback). It then sends a tokenless initialize, gets our 401 with a WWW-Authenticate: Bearer resource_metadata=… challenge, sends a second tokenless initialize, and stops.
  3. Every scan request has no Authorization header. It never calls tools/list, never refreshes a token, and never retries with a credential.
  4. For ordinary connected users, a tokenless 401 is followed within seconds by a refresh_token grant and an authenticated call. The scanner never does that.

As an experiment, is it worth opening up unauthenticated discovery on our server to see if scan passes? It’s not our attention to stay that way, but maybe we’d learn something?

At the moment, I can’t tell if we have an actual problem with our server or if there is a problem with how the scan is being performed.

Same here: a published app, “MCP configuration incomplete”, and Rescan fails at once with “Authorization for scanning is missing or no longer works”. Our server logs show what triggers it:

  • The daily scan (openai-mcp/1.0.0, from 104.210.139.x) ran fine every night with an authenticated POST /mcp returning 200.
  • On 24 Oct we moved our OAuth endpoints to a new path, as advertised in our discovery metadata. ChatGPT doesn’t re-read discovery; it keeps the token URL stored when the app was published. So the scanner’s background token refresh went to the old path and got a single 401 invalid_client.
  • Within hours we added an alias so the old token URL works again. Since then the scanner has sent nothing to our server: no nightly scan, no refresh, no discovery. Every Rescan fails without reaching us.
  • Reconnecting in the plugin editor works (token 200 from ChatGPT’s connector IPs, and tools work in ChatGPT), but it doesn’t revive the scanner’s login.

So a single refused refresh seems to leave the scan’s login marked as dead for good, with no way for the developer to reset it.

Probably in response to my support ticket which is now in progress, I saw today that the MCP card, while still oddly shows “Untitled app” for me, now has a “…” menu next to the download icon. The one action presented is “Reconnect”!

Doing that allowed me to authenticate via OAuth and triggered a scan that passed. It’s no longer telling me MCP configuration is incomplete and I suspect daily scans will now pass.

Same thing happened for me but I never raised a support ticket, so it might be just a case of their scanner taking a while to sort itself out. Glad its resolved for you too.