Spaces:
Running
Problem with Gradio and MCP Server
Hi team, I’m encountering an error when using mcp_server=True in a public Hugging Face Space.
My app.py uses gr.Interface with Gradio 4.44.1, and looks like this:
demo = gr.Interface(...)
demo.launch(mcp_server=True)
It works perfectly when running locally (Python 3.11), and the MCP server starts correctly.
However, when I deploy the same code to a Hugging Face Space, even though the file content is correct and the build completes without issues, the app crashes with the following error:
TypeError: Blocks.launch() got an unexpected keyword argument 'mcp_server'
What I’ve tried so far:
• Deleting and recreating the Space from scratch
• Confirming that gr.Blocks is not used anywhere in the code
• Forcing the update with git push --force
• Verifying that gradio==4.44.1 is actually installed in the environment
My guess is that the container is still running a cached version of a previous app.py, or there’s a bug when enabling mcp_server=True in public Spaces.
Is there any known limitation or workaround to make mcp_server=True work properly in public Hugging Face Spaces?
Thanks in advance! 🙏
hf jobs run python:3.12 python -c "print('Hello from the cloud!')"
Frankly, I have been keeping my projects up to date with Gradio. There have been lots of bug fixes. We are currently at 5.42.0.
i meet this problem too, i solved by change the version of python .
Python 3.12.3
Gradio 5.49.1
This looks like a version/environment mismatch more than stale code. mcp_server=True support landed in newer Gradio versions, so I would first make the Space prove what it is actually running at startup.
A quick debugging pattern:
import gradio as gr
import sys
print("python", sys.version)
print("gradio", gr.__version__)
Then pin both Python and Gradio explicitly in the Space config / requirements. If local and Space differ, the error makes sense even if app.py is correct. For MCP examples in particular, I would keep the version visible in logs because course/tutorial code can age quickly.
This looks like a version/runtime mismatch more than a cache problem.
mcp_server=True landed in newer Gradio versions, and the course examples have been moving with the MCP APIs. I would try making the Space runtime completely explicit:
# requirements.txt
gradio>=5.42.0
huggingface_hub[mcp]>=0.32.0
Then trigger a full rebuild and check the build log for the installed Gradio version. If the runtime still says Blocks.launch() got an unexpected keyword argument 'mcp_server', the process that is serving the app is not using the Gradio version you think it is.
A small sanity check inside app.py can save time:
import gradio as gr
print('gradio version:', gr.__version__)
For MCP demos, I would also keep the initial app minimal until the endpoint works, then add the real interface back. That separates “Spaces/runtime/version” issues from app logic issues.