MCP Server Part 8: MCP server routes

[KoolADE85]

Summary

This PR pulls together everything from the previous PRs into a working MCP server you can connect to from any MCP-compatible LLM agent. Example:

claude mcp add dash-app --transport http http://localhost:8050/_mcp

• Routes are added per MCP spec
• Dash integration: control the feature with enable_mcp and mcp_path constructor params, (or DASH_MCP_ENABLED / DASH_MCP_PATH env vars)
• E2E test suite: all the previous PRs have E2E coverage via the actual MCP server endpoints.
• A number of one-liner type fixes since the mypy tests are now running in this PR.

[github-actions]

Thank you for your contribution to Dash! 🎉

This PR is exempt from requiring a linked issue due to its labels.

[chgiesse]

Hi Plotly team!

First of all, thanks for integrating MCP into Dash - this looks really exciting!
But I would like to address/discuss some concerns:

• this PR looks like its not compatible with the new bring your own Backend architecture by directly importing components like Response from Flask and not the response adapter - thus the mcp doesn't work with FastApi or Quart
• the same seems to apply for the SSE streaming. Which I think should be integrated into the server adapter classes and be provided for the other backends too
• and regarding the SSE implementation - I think the this version has some serious security implications - for synchronous Flask. With the current endless loop, session wise handling and Gunicorns default synchronous workers, the life time per session per sse stream blocks a complete worker! For example, google Chrome doesn't really provide a tab limit, so I could open a 1000 tabs and block a 1000 workers in your application. Although I think there is not a direct solutions to this (besides not providing endless stream capabilities to a synchronous backend) - a way to handle this would be to provide a DashQueueAdapter where a user can use a Gevent Queue instead of the default one. With this, the problem can be smoothed out in production. I also created a blog post ones - comparing server performance with SSE streams between Flask and Quart. https://community.plotly.com/t/flash-1-2-0-streaming-ui-updates-via-server-sent-events/93890/2

Let me know what you think - if you see it the same way or if I overlooked something! Would also love to contribute these changes :)

Best regards,
Christian

[KoolADE85]

Hey @chgiesse

Thanks for the comments, and happy to see the excitement around the feature!

• I'll be adjusting this to be compatible with the "bring your own backend" initiative. As you can see, the two projects have been happening independently so I'll make the appropriate code adjustments here.

• As for SSE streaming, I'm thinking to remove that for the initial release. Early on, I thought it would be useful to have some server-driven messaging, and this would represent the start of that. But since the core functionality is all achieved with basic, well-described tools/resources, it's probably wise to remove SSE until we think through the security and performance considerations.

And absolutely, I'd welcome any contributions you have towards this effort - there's tons of potential to make Dash apps even more LLM friendly!

Adrian