Repository navigation
FastMCP configures logging on init, which messes up application-level logging #1656
Description
Activity
- added a commit that references this issue
on Mar 12, 2026 I have a fix for this — PR incoming. The change moves
configure_logging()fromMCPServer.__init__()toMCPServer.run(), so instantiation no longer touches the root logger. Only therun()entrypoint configures logging.Please note that no parts of the library should run
configure_logging(). TheMCPServerclass is part of the library, so none of it's methods should configure the logging.If you want people to be able to quickly start an MCP server for exploring/learning, add a project script to the library that calls
configure_logging(). This is the right approach to do this.E.g. add a module
cli.pywith adef run()function, where you:configure_logging()- create a server
- run the server
That way people can call this to experiment, or copy it for quickstart, but no library user instantiating and running an
MCPServerobject would be forced to use this logging config.Reacted by Gustavo Machado, gp3t1, lacebal and Matthias UrlichsWe are facing the same problem and I have seen many open issues reported but no solution (that's ok, this is Open Source so a best effort), but the worst of all is that there seems to not be any plan or roadmap to tackle this basic usage hinderance on library from an official "Open" protocol. This looks ridiculous.
Is there any plan to work on that or would you just accept any vibe coded changing logging initialization to follow best practices as pointed out?
For anyone coming across this, you can work around these types of issue by using
logging.basicConfig(..., force=True)in your application entrypoint after creating the FastMCP server. This will remove and close any existing handlers attached to the root logger.If you are using a more elaborate manual logging config you will have to manually remove all existing handlers before setting up your own logging pipeline.
For people willing to engage with the maintainers to try and fix this: If I'd be maintaining this library, I'd want to make sure that all of the examples referenced in the README still have reasonable logs when running them in a CLI. You might have to specifically call
logging.basicConfig()for these types of entrypoints. I don't think just removing the call fromFastMCP.__init__is necessarily a good fix.I initially considered working on this, but after re-checking the issue I noticed active linked PRs already cover this area. I will not open a duplicate PR here.
While PR #2532 waits for whatever it is it's waiting for, here's a monkey-patchy workaround:
import logging from typing import cast ... # configure your own logging here -- before importing, well, anything else really def _no_config(*_a: Any, **_k: Any) -> None: import warnings # noqa: PLC0415 warnings.warn("Call to logging config ignored", stacklevel=2) logging.basicConfig = cast(Any, _no_config) logging.config.dictConfig = cast(Any, _no_config) logging.config.fileConfig = cast(Any, _no_config)Sigh PR #2532 was closed without resolving it.
Dear authors: please don't do that. IMHO, calling
logging.basicConfigunconditionally, when you're not__main__, is disruptive and anti-social. I'm setting up my logging before importing things, because that's how I can catch import errors and whatnot. You're forcing me to do it all over again, possibly losing important information.
Initial Checks
Description
Hi everyone, thanks for maintaining the Python SDK for MCP!
I've noticed that the
FastMCPclass configures the logging ecosystem on__init__(), both by adding custom handlers and callinglogging.basicConfig(...). This will conflict with any logging setup that any application using the MCP SDK will use.Please note that the best practice for logging is:
Please refer to the official logging HowTo, section "Configuring Logging for a Library":
For the sake of easy quickstarts, I'd advice to create some module specifically meant for quickstarts that runs a FastMCP server, taking care of setting up the rich logging as well before. But keep it separated from the main library usage of FastMCP server, so applications using it don't get their logging config messed up.
Example Code
Python & MCP Python SDK