Async vs Sync Features and Customization

In the previous examples, our tool was defined as a synchronous function using a regular def:

def dog_to_human_age(age: int) -> int:
    """Calculate the real age of a dog in human years."""
    return age * 7

However, FastMCP also supports asynchronous tools.

When you write a tool in FastMCP, you have a choice between defining it as a regular synchronous function using def or as an asynchronous function using async def. Understanding when and why to use each approach is important, though FastMCP makes it easy to use either one without breaking your server.

Asynchronous programming in Python is built around the concept of cooperative multitasking. When you define a function with async def, you're telling Python that this function might need to wait for something like a database query, a network request, or a file read without blocking the entire program. Instead of freezing and waiting, an async function can pause at an await point and let other work happen while it waits. This is particularly valuable when your server handles multiple requests at once, because one slow database query won't prevent other tools from running.

The practical question is whether you actually need async for your tools. The answer depends on what your tool does and what features you want to use.

There are 2 main scenarios (among others) where async is beneficial:

• If you're making HTTP requests with modern async libraries like httpx or aiohttp, or using async database drivers like asyncpg, then async is the natural choice since these libraries are designed around await.

• If you're using FastMCP's Context features for logging, progress reporting, or state management, async is recommended. Context does work in synchronous tools as well, but using async def gives you access to the full range of context features with less friction.