Option to not rewrite the logging configuration

Is your feature request related to a problem? Please describe.
We are integrating FastMcp into a larger python process that requires a custom logging handler and when initialising the FastMCP server (in our case in sse mode) we see that the logging library configuration changes with a custom configuration of the server itself.

Describe the solution you'd like
Define a configuration parameter that disables the logging configuration performed by the server.

Describe alternatives you've considered
Reviewing the configuration parameters I have seen the existence of the parameter log_level (

python-sdk/src/mcp/server/fastmcp/server.py

Line 71 in c2ca8e0

log_level: Literal["DEBUG", "INFO", "WARNING", "ERROR", "CRITICAL"] = "INFO"

) and perhaps if this parameter allowed the value None this could prevent the reconfiguration from being carried out.

Additional context
As far as I have been able to identify, there are two points where this configuration is being made and which should be modified:

The call to the configure_logging method (

python-sdk/src/mcp/server/fastmcp/server.py

Line 138 in c2ca8e0

configure_logging(self.settings.log_level)

), which should be prevented.
The configuration of uvicorn (

python-sdk/src/mcp/server/fastmcp/server.py

Line 471 in c2ca8e0

config = uvicorn.Config(

) that if the parameters log_config and log_level are not None also makes the change.

Hi, any update on this?

The cleanest way would be to just reset the logging configuration after the instantiation of the FastMCP object, but this is more fun:

def nuke_function(fn):
    def noop(*args, **kwargs):
        return

    fn.__code__ = noop.__code__

import mcp.server.fastmcp.utilities.logging as fast_mcp_logging_module

nuke_function(fast_mcp_logging_module.configure_logging)

Note: I tried to simple assign fast_mcp_logging_module.configure_logging to an dummy function, but did not work. The variable have likely already been bound somewhere else.

This would be great to make configurable - it take a decent amount of troubleshooting to figure out what imported library is adding a logging handler. From the perspective of a developer who has already configured global logging for their application, log messages are suddenly duplicated.

Enumerating handlers and removing them works fine, but global side effects you can't opt out of aren't developer friendly.

We ran into a similar issue attempting to use our structured logging config for FastMCP server logging. We were able to work around the issue by adding a FastMCP logger to our log config and calling logging.config.dictConfig(OUR_LOGGING_CONFIG) to reconfigure the MCP logger to do what we wanted.

With that said, agreed that it would be helpful to have an option to not remove other handlers.

We ran into a similar issue attempting to use our structured logging config for FastMCP server logging. We were able to work around the issue by adding a FastMCP logger to our log config and calling logging.config.dictConfig(OUR_LOGGING_CONFIG) to reconfigure the MCP logger to do what we wanted.

With that said, agreed that it would be helpful to have an option to not remove other handlers.

Can you say more about your workaround? Were you using structlog? If so, care you share some more about how you did it?

Is there any update on this? The FastMCP logs break our ability to cleanly ship JSON formatted logs... The massive multi-line console formatted logs create a ton of noise.

Hi, I am also wondering if there is any update on this. The logging output looks weird to me ... and is inconsistent with every other log line in our app:

2025-09-24 16:58:30 | INFO | app.services.chat_service | Intent: redirect, Confidence: 0.95    
2025-09-24 16:58:36 | INFO | app.services.chat_service | Intent: job_search, Confidence: 0.95
[09/24/25 16:58:37] INFO     Processing request of type            server.py:624             
                             ListToolsRequest                                                
[09/24/25 16:58:38] INFO     Processing request of type            server.py:624             
                             CallToolRequest                                                 
                    ERROR    Error in search_jobs: Server   search_handler.py:45             
                             error '500 Internal Server                                      
                             Error' for url                                                  
                             'http://mcp/api/bf                                  
                             f/search/?name=h                                  
                             ealthcare&area_radius=25&type=                                  
                             Actionable&what=details&where=area&size=15.0'                                               
                             For more information check:                                     
                             https://developer.mozilla.org/                                  
                             en-US/docs/Web/HTTP/Status/500                                  
                    INFO     Processing request of type            server.py:624             
                             ListToolsRequest                                                
[09/24/25 16:58:40] INFO     Processing request of type            server.py:624             
                             CallToolRequest                                                 
                    INFO     Processing request of type            server.py:624             
                             ListToolsRequest

How do I override this?

I believe internally MCP uses basicConfig to set up logging (not the only location, but for example

python-sdk/src/mcp/server/fastmcp/utilities/logging.py

Line 39 in 71889d7

logging.basicConfig(

). This is configuring the default logger.

Per the documentation:

This function does nothing if the root logger already has handlers configured, unless the keyword argument force is set to
True.

So the trick is to ensure that you can get a default logger handler installed before MCP does its log initialization (e.g. using dictConfig or an earlier call to basicConfig). Then the MCP calls to basicConfig will be no-ops.

@nvachhar

Thanks @nvachhar

I tried it with .dictConfig like this:

LOGGING_CONFIG = {
    'version': 1,
    'disable_existing_loggers': False,
    'formatters': {
        'standard': {
            'format': '%(asctime)s | %(levelname)s | %(name)s | %(message)s'
        },
    },
    'handlers': {
        'console': {
            'class': 'logging.StreamHandler',
            'formatter': 'standard',
            'level': 'DEBUG',
            'stream': 'ext://sys.stdout',
        },
    },
    'loggers': {
        # Configure FastMCP logger to use our structured logging
        'mcp': {
            'handlers': ['console'],
            'level': 'DEBUG',
            'propagate': False,
        },
        # Also configure the FastMCP server logger
        'mcp.server': {
            'handlers': ['console'],
            'level': 'DEBUG',
            'propagate': False,
        },
        # Configure our application logger
        'app.jobsearch_mcp': {
            'handlers': ['console'],
            'level': 'DEBUG',
            'propagate': False,
        },
    },
    'root': {
        'handlers': ['console'],
        'level': 'INFO',
    }
}

logging.config.dictConfig(LOGGING_CONFIG)
logger = logging.getLogger(__name__)

mcp = FastMCP(settings.MCP_SERVER_NAME)

... but the result was: no log lines from the code anymore, not even weird looking ones. Just no output 🤷

I’ll try to think of something else, later ...

Very strange. I do something quite similar (except I don't specifically call out any loggers, I just let the root logger do the logging) and it has worked for me.

Navigation Menu

Repository navigation

Option to not rewrite the logging configuration #420

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Option to not rewrite the logging configuration #420

Description

Activity

sergioave commented on May 22, 2025

olejorgenb commented on Jun 18, 2025

kulinacs commented on Jul 9, 2025

mukulmurthy commented on Aug 6, 2025

lukehsiao commented on Aug 19, 2025

ChuckJonas commented on Sep 5, 2025

flegelleicht commented on Sep 24, 2025

nvachhar commented on Sep 24, 2025

flegelleicht commented on Sep 24, 2025

nvachhar commented on Sep 24, 2025

laozhangzzz commented on Jun 25, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions