fastmcp tool func block asyncio

[archever]

Initial Checks

• I confirm that I'm using the latest version of MCP Python SDK
• I confirm that I searched for my issue in https://github.com/modelcontextprotocol/python-sdk/issues before opening this issue

Description

unlike fastapi, fastmcp run sync tool func directly. this may block async loop if the func uses block io like requests

fastmcp

class FuncMetadata(BaseModel):
 ...
 async def call_fn_with_arg_validation(
 self,
 fn: Callable[..., Any | Awaitable[Any]],
 fn_is_async: bool,
 arguments_to_validate: dict[str, Any],
 arguments_to_pass_directly: dict[str, Any] | None,
 ) -> Any:
 """Call the given function with arguments validated and injected.

 Arguments are first attempted to be parsed from JSON, then validated against
 the argument model, before being passed to the function.
 """
 arguments_pre_parsed = self.pre_parse_json(arguments_to_validate)
 arguments_parsed_model = self.arg_model.model_validate(arguments_pre_parsed)
 arguments_parsed_dict = arguments_parsed_model.model_dump_one_level()

 arguments_parsed_dict |= arguments_to_pass_directly or {}
 if fn_is_async:
 return await fn(**arguments_parsed_dict)
 else:
 return fn(**arguments_parsed_dict)

fastapi

async def run_endpoint_function(
 *, dependant: Dependant, values: dict[str, Any], is_coroutine: bool
) -> Any:
 # Only called by get_request_handler. Has been split into its own function to
 # facilitate profiling endpoints, since inner functions are harder to profile.
 assert dependant.call is not None, "dependant.call must be a function"

 if is_coroutine:
 return await dependant.call(**values)
 else:
 return await run_in_threadpool(dependant.call, **values)

Example Code

import time
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("Demo", json_response=True, stateless_http=True)


@mcp.tool()
def wait() -> str:
 """Add two numbers"""
 time.sleep(10)
 return "ok"


mcp.run()

# call wait tool, any call will be blocked until the sleep is done

Python & MCP Python SDK

python=3.12
mcp=latest

[archever]

related issue microsoft/markitdown#1517

[jlowin]

FastMCP runs synchronous tools synchronously as it doesn't represent a specific opinion of how to achieve background concurrency. My recommendation would be to invoke run_in_threadpool yourself inside an async tool.

[maxisbey]

Yea I think what @jlowin said the best workaround.

Although I do think having some sort of support for this would be nice given the FastMCP module allows sync functions to be registered and I could see people not realising the performance implications of it.

If we were to do it I think it'd need to be done after changing how context works to avoid the contextvar we currently have that relies on which async task is running.

[Kludex]

I disagree with both messages above. If the user is allowed to invoke a non-async function, then the framework should run in a thread pool.

If we were to do it I think it'd need to be done after changing how context works to avoid the contextvar we currently have that relies on which async task is running.

We can change it already. AnyIO propagates the ContextVar properly.

[jayhemnani9910]

Hi! I'm interested in working on this issue.

I went through the comments and spent some time exploring the codebase to understand the problem better. While looking at how similar
cases are handled, I noticed that FileResource and DirectoryResource in resources/types.py already use anyio.to_thread.run_sync()
for blocking operations:

# FileResource.read() 
return await anyio.to_thread.run_sync(self.path.read_bytes) 
 
This led me to think the fix in FuncMetadata.call_fn_with_arg_validation() could be: 
 
if fn_is_async: 
 return await fn(**arguments_parsed_dict) 
else: 
 return await anyio.to_thread.run_sync( 
 lambda: fn(**arguments_parsed_dict) 
 ) 
 
Regarding the ContextVar concern raised earlier - I checked and anyio.to_thread.run_sync() uses copy_context() internally, so the request
 context should propagate correctly to the worker thread. Also, the MCP Context object is passed explicitly as a function argument (via 
arguments_to_pass_directly), so it doesn't rely on ContextVars at all. 
 
Would love to hear your thoughts on this approach

[jlowin]

I take @Kludex point - blocking the loop is a worse offense than making sync footguns available without warranty.