MCP service: Flask app context error when running via 'superset mcp run' #38806

Activity

1. dosubot

   added

   validation:requiredA committer should validate the issueA committer should validate the issue

   on Mar 23, 2026
2. dosubot commented on Mar 23, 2026

   

   dosubotBot

   on Mar 23, 2026 – with DosuBot

   Last edited by dosubot

   More actions

   This is a known issue with Docker deployments of the MCP server in 6.1.0rc1. The superset mcp run command doesn't automatically push the Flask app context when running as a standalone process.

   Workaround for ECS Fargate: Use an inline Python command that explicitly pushes the app context before starting the MCP server:

   command: [
     "python", "-c",
     "from superset.app import create_app; app = create_app(); app.app_context().push(); from superset.mcp_service.server import run_server; run_server(host='0.0.0.0', port=5008)"
   ]

   This works because the standard docker-bootstrap.sh script doesn't support "mcp" as an argument — only worker, beat, app, and app-gunicorn.

   Note on --use-factory-config: This flag doesn't exist for superset mcp run. The command only accepts --host, --port, and --debug.

   Several Flask context-related fixes were merged in January 2026 (#37190, #37252, #37309), but manual context initialization is still required for standalone Docker deployments.

   To reply, just mention @dosu.

   ---

   Docs are dead. Just use Dosu.

   
3. howardcho commented on Mar 26, 2026

   

   howardcho

   on Mar 26, 2026

   More actions

   Confirmed seeing the same issue on apache/superset:6.1.0rc1 with Keycloak-backed JWT auth.

   Our staging MCP server is publicly reachable, JWT auth is configured and accepted, and /mcp responds correctly. Real clients (Claude Code and MCP Inspector) reach the server and POST /mcp returns 200 OK, but the server then logs:

   Failed to validate request: No application found. Either work inside a view function or push an application context.

   followed by session termination.

   We also confirmed:

   • fastmcp installed
   • MCP runs as a separate process
   • MCP_AUTH_ENABLED=True
   • MCP_JWT_ALGORITHM=RS256
   • MCP_JWKS_URI configured
   • bearer token audience includes superset-mcp

   This appears provider-agnostic; we are using Keycloak rather than Okta and see the same failure pattern.

   👍React with 👍2Reacted by Romain Robert and Timofei Fursov
4. howardcho commented on Mar 26, 2026

   

   howardcho

   on Mar 26, 2026

   Last edited by howardcho

   More actions

   We also tested a workaround (posted above) where the MCP server is started via an inline Python command that explicitly creates the Flask app and pushes an app context before calling run_server(...).

   That workaround did not resolve the issue.

   Result was unchanged:

   • client reaches /mcp

   • POST /mcp returns 200 OK

   • server still logs:

     • Failed to validate request: No application found. Either work inside a view function or push an application context.
     • Terminating session: None

   So this does not appear to be only a startup-context problem; it still fails during request handling.

   @dosu FYI
5. fowlerp397-tech commented on Mar 27, 2026

   

   fowlerp397-tech

   on Mar 27, 2026 via email

   More actions

   Thanks for the detailed info! It looks like the issue persists even with the workaround. I’ll continue investigating the request handling to see if there’s another underlying problem.

   …

   On Thu, Mar 26, 2026, 12:05 PM Howard Cho ***@***.***> wrote: *howardcho* left a comment (apache/superset#38806) <#38806 (comment)> We also tested a workaround (posted above) where the MCP server is started via an inline Python command that explicitly creates the Flask app and pushes an app context before calling run_server(...). That workaround did *not* resolve the issue. Result was unchanged: - client reaches /mcp - POST /mcp returns 200 OK - server still logs: - Failed to validate request: No application found. Either work inside a view function or push an application context. - Terminating session: None So this does not appear to be only a startup-context problem; it still fails during request handling. — Reply to this email directly, view it on GitHub <#38806?email_source=notifications&email_token=B72HASMKSCMUSXRVLVPET334SVPOHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJTGY3DMNZSGYY2M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-4136667261>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B72HASJAC4LVHGCAKDFXUCD4SVPOHAVCNFSM6AAAAACW4GHAXGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCMZWGY3DOMRWGE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
6. syafiqmuda commented on Apr 6, 2026

   

   syafiqmuda

   on Apr 6, 2026

   More actions

   @dosu how to run the MCP server in docker?
7. himanshupatidar266 commented on Apr 10, 2026

   

   himanshupatidar266

   on Apr 10, 2026

   More actions

   Hi team,

   I’m also facing this same issue in my environment.
   Could you please confirm:
   Whether this issue is already being worked on?
   And in which upcoming Superset release (e.g., 6.1.x or 6.2.0) we can expect a fix?
   This is currently impacting our usage, so any ETA or workaround would be really helpful.

   Thanks!

   👍React with 👍5Reacted by Romain Robert, Timofei Fursov, Andi, Yrlan and Hannes
8. romrob commented on Apr 20, 2026

   

   romrob

   on Apr 20, 2026

   More actions

   Hi everyone,
   Same problem on our side and same question as @himanshupatidar266: @fowlerp397-tech is this issue already worked on ? Can we maybe assist ?
   We'd be very interested to have this new feature working on our setup.

   Thanks

   👍React with 👍2Reacted by himanshupatidar266 and Hannes
9. rusackas commented on Aug 25, 2026

   

   rusackas

   on Aug 25, 2026

   Member

   More actions

   A lot of app-context handling in mcp_service has changed since this was filed — #38747 and #39385 both push a fresh Flask app context per tool call now, and CompositeTokenVerifier pushes one at the transport layer specifically for API-key/JWT validation. Can anyone confirm whether this still reproduces on current master or a newer RC? If it does, a stack trace pinpointing exactly which layer logs "Failed to validate request" would help, since that determines whether the fix belongs in superset/mcp_service or needs to go upstream to fastmcp.
10. Ujjwaljain16 commented on Oct 1, 2026

    

    Ujjwaljain16

    on Oct 1, 2026

    Contributor

    More actions

    @rusackas
    i investigated this against current master (8ab7a85a3d) and also ran a 6.1.0rc1 control environment
    i could not reproduce the reported No application found error in either environment on current master, superset mcp run works end-to-end with JWT authentication in both stateless and stateful modes, including initialize, tools/list, and DB-backed tools.

    a few details from tracing the current implementation:

    the "Failed to validate request" message comes from the MCP SDK's generic request-processing exception handler; it does not identify the underlying failure
    the "No application found..." message is the Flask-SQLAlchemy 2.x error, so the original failure appears to have involved Flask/SQLAlchemy access without an application context somewhere in the request path
    #39385 changes app-context handling for the case where a context is already present, to prevent concurrent tool calls from sharing g/g.user.
    the no-context tool-call path already pushed an app context in 6.1.0rc1
    #38747 changes JWT-to-user resolution and stale g.user handling; it does not introduce the missing app-context behavior.

    i therefore don't think we can attribute the original issue to either #38747 or #39385, and i don't see a current production-code change justified by the reproduction so far

    there are still differences from the original report: my reproduction used HS256 rather than RS256/JWKS
    the exact exception that originally escaped into the MCP SDK's "Failed to validate request" handler therefore remains unidentified

    if this is still reproducible on a current 6.1.x/master deployment, a full server-side traceback around the "Failed to validate request" message would be especially useful to identify the failing layer
    otherwise, it would be useful for the original reporters to retest on 6.1.0 or current master
11. rusackas commented on Oct 2, 2026

    

    rusackas

    on Oct 2, 2026

    Member

    More actions

    Closing this one. #38747 and #39385 both merged and push a fresh app context per tool call, and @Ujjwaljain16 couldn't reproduce on current master. If you still see it on a build with those, please open a new issue with the full stack trace.

    👍React with 👍1Reacted by Ujjwal Jain
12. rusackas

    closed this as completedon Oct 2, 2026