Android ChatGPT app error after before tools/call

I’m debugging a ChatGPT MCP/App SDK app on Android.

On Android, invoking my app shows:

“An error has occurred. Please try again later.”

Server logs show:

  • initialize: 200
  • tools/list: 200
  • resources/list: 200
  • resources/read: 200
  • then generic error
  • no tools/call ever reaches my server

So the failure seems to happen inside ChatGPT Android before my tool handler runs.

Has anyone seen Android fail before tools/call?

This started happening for 2 of my apps, been trying to (vibe)fix it for the past 2 days but nothing.

The app works fine on browser or iOS.

Would greatly appreciate any help with this (I’mgoingabitinsane) :folded_hands:

I don’t use Android myself, but here’s something that I found and that might be worth checking, if you already haven’t that is.

Since the app works on browser/iOS and your server receives initialize, tools/list, resources/list and resources/read, but no tools/call ever reaches your server on Android, this sounds like the failure may be happening inside the ChatGPT Android client before tool invocation.

The Apps SDK docs mention that linked connectors are available on mobile clients too and recommend testing mobile layouts early:

What I’d collect (if you haven’t):

  • Android device/model and OS version
  • ChatGPT Android app version
  • connector/app ID if available
  • exact timestamp/timezone
  • whether this happens on Wi-Fi and mobile data
  • whether refreshing connector metadata changes anything
  • server logs showing the successful initialize/list/read calls and missing tools/call

It may also help to compare the same app through MCP Inspector or API Playground, since those can show raw request/response behavior:

If it only fails on Android after those checks, I’d report it to OpenAI Support.

In addition to @LarisaHaster's great response, can you try a minimal static component resource on the same app/tool first?

No JS bundle, no external assets, no OAuth, no redirects, no custom domain logic, just a tiny inline/static widget and see whether Android reaches tools/call.

Given your logs (initialize, tools/list, resources/list, resources/read all 200), the failure likely happens during widget render/bootstrap inside the Android client before the tool invocation path.

Also useful to inspect:

  • exact resources/read payload + response headers
  • tool descriptor _meta (especially openai/outputTemplate, ui.resourceUri, widget accessibility flags)
  • CSP + widget domain config
  • Android logcat / WebView console errors
  • whether the widget depends on:
    • browser-only APIs
    • third-party cookies/storage
    • redirects
    • cross-origin assets
    • service workers
    • dynamic imports/module loading
    • mixed-content HTTP assets

If the minimal component works, it points more toward CSP, asset loading, Android WebView compatibility, auth/session handling, or frontend JS crashing before the tool call.

If even the minimal widget fails before tools/call, that’s much stronger evidence of an Android ChatGPT client/App SDK regression rather than your server/tool handler.

Feel free to open a support ticket to support@openai.com with request_IDs and any details that would be helpful as mentioned above.

-Mark G.

Hi Mark,

Thanks for the guidance. We followed your suggested path and unfortunately still have not isolated the root cause.

The short version: the problem is not limited to the resume widget JS boot. We tested a minimal static widget resource and Android still showed the same generic error.

What we tested:

  1. Minimal static component/resource on the same app/tool

    • We replaced the build_resume widget resource with a tiny inline/static HTML response.

    • No React.

    • No bundled app JS.

    • No external JS/CSS assets.

    • No OAuth.

    • No redirects.

    • No custom domain logic.

    • No notifyIntrinsicHeight.

    • No dynamic imports.

    • Visible body text only: Resume builder static probe loaded.

Android did reach resources/read.

Example logged sequence:

  • initialize 200

  • notifications/initialized 202

  • tools/list 200

  • resources/list 200

  • resources/read 200 for ui://views/apps-sdk/build_resume.html?..

  • response MIME: text/html+skybridge

  • static HTML size: 1391 bytes

  • response meta keys: openai/widgetCSP, openai/widgetDomain, openai/widgetDescription, openai/widgetPrefersBorder

  • then Android still showed the generic error

So the static resource did not make the resume tool path reliable.

  1. Separate control tool/widget
    We added a separate simple control tool/widget, a smiley-face probe. In some runs this worked: Android invoked the tool and rendered the widget. That suggests the tunnel/server and Android app connection can work in principle.

However, the resume tool continued to fail, especially once resume details were provided.

  1. Tool/schema/descriptor reduction
    We tried reducing the resume tool surface in multiple ways:

    • simpler description

    • simpler schema

    • flat resumeDetails input instead of nested profile

    • renamed tool variants

    • plain tool without widget binding

    • empty resource list

    • cache-busted server/widget versions

    • fresh Android app connections

These did not consistently remove the generic Android error.

What should we do?