Recommendation

Add an optional parameter to Context logging methods (ctx.debug(), ctx.info(), etc.) to also log to the server's Python logger, allowing server operators to capture client-directed log messages in their server logs for monitoring, debugging, and observability.

The cleanest approach is adding a also_log_to_server boolean parameter (defaulting to False) to maintain backward compatibility while providing opt-in functionality.

Findings

Current Architecture

Client Logging via Context (ctx)

Context logging methods (ctx.debug(), ctx.info(), ctx.warning(), ctx.error()) send log messages to MCP clients via session.send_log_message() (src/fastmcp/server/context.py:210-342)
These messages are protocol-level notifications sent over the MCP transport to the client
Messages include support for structured logging via the extra parameter
Currently, these messages are only sent to the client and not captured in server logs

Server-Side Logging

FastMCP uses Python's standard logging module with rich formatting (src/fastmcp/utilities/logging.py)
Server logs are namespaced under fastmcp.* via get_logger(__name__)
Logging middleware (src/fastmcp/server/middleware/logging.py) logs MCP requests/responses but not the content of ctx.log() calls

The Gap
When developers use ctx.info("Processing transaction") in their tools, this message goes to the client but leaves no trace in server logs. Server operators lose visibility into what's happening inside tool executions unless they add redundant calls to both ctx.info() and logger.info().

Why This Matters

Server Monitoring: Operators need to see tool execution details in centralized logging systems
Debugging: When investigating issues, server logs should show what messages were sent to clients
Observability: Integration with systems like OpenTelemetry, Datadog, or ELK requires server-side log capture
Audit Trails: Compliance requirements often demand server-side logging of all operations

Related Work

Issue Document logging with OpenTelemetry #1998: Documents logging with OpenTelemetry - this enhancement would make ctx logging visible to OTEL handlers
Issue FastMCP Logging throwing RuntimeWarning with MCP Inspector #847: Reports RuntimeWarning with ctx logging in MCP Inspector - shows complexity of current logging flow
Issue Can't set logging capability from server #525: Discusses logging capability configuration in MCP spec
PR Updates to Logging Middleware #1974: Enhanced logging middleware with request duration - shows server-side logging patterns
PR Structured client-side logging #1326: Added structured logging support to ctx.log() methods with extra parameter

Detailed Action Plan

Implementation Steps

1. Modify Context Logging Methods

Update src/fastmcp/server/context.py to add also_log_to_server parameter:

async def log(
    self,
    message: str,
    level: LoggingLevel | None = None,
    logger_name: str | None = None,
    extra: Mapping[str, Any] | None = None,
    also_log_to_server: bool = False,  # NEW
) -> None:
    """Send a log message to the client.
    
    Args:
        message: Log message
        level: Optional log level
        logger_name: Optional logger name
        extra: Optional mapping for additional arguments
        also_log_to_server: If True, also write to server's Python logger
    """
    if level is None:
        level = "info"
    data = LogData(msg=message, extra=extra)
    
    # Send to client (existing behavior)
    await self.session.send_log_message(
        level=level,
        data=data,
        logger=logger_name,
        related_request_id=self.request_id,
    )
    
    # NEW: Optionally also log to server's Python logger
    if also_log_to_server:
        server_logger = get_logger(logger_name or "server.context")
        log_level = _map_mcp_to_python_level(level)
        server_logger.log(log_level, message, extra=extra)

Update convenience methods (debug, info, warning, error) to accept and pass through the parameter:

async def info(
    self,
    message: str,
    logger_name: str | None = None,
    extra: Mapping[str, Any] | None = None,
    also_log_to_server: bool = False,  # NEW
) -> None:
    """Send an info log message."""
    await self.log(
        level="info",
        message=message,
        logger_name=logger_name,
        extra=extra,
        also_log_to_server=also_log_to_server,  # NEW
    )

2. Add Level Mapping Helper

Add a helper function in src/fastmcp/server/context.py:

def _map_mcp_to_python_level(mcp_level: LoggingLevel) -> int:
    """Map MCP log levels to Python logging levels."""
    level_map = {
        "debug": logging.DEBUG,
        "info": logging.INFO,
        "notice": logging.INFO,
        "warning": logging.WARNING,
        "error": logging.ERROR,
        "critical": logging.CRITICAL,
        "alert": logging.CRITICAL,
        "emergency": logging.CRITICAL,
    }
    return level_map.get(mcp_level.lower(), logging.INFO)

3. Add Tests

Create tests in tests/server/test_context_logging.py:

async def test_context_logging_also_logs_to_server(caplog):
    """Test that also_log_to_server writes to Python logger."""
    mcp = FastMCP("test")
    
    @mcp.tool()
    async def test_tool(ctx: Context) -> str:
        await ctx.info("Test message", also_log_to_server=True)
        return "done"
    
    with caplog.at_level(logging.INFO):
        async with Client(mcp) as client:
            await client.call_tool("test_tool", {})
    
    assert "Test message" in caplog.text

4. Update Documentation

Update docs/servers/logging.mdx to document the new parameter:

## Logging to Both Client and Server

By default, `ctx.log()` methods only send messages to the MCP client. To also 
capture these messages in your server's Python logs, use the `also_log_to_server` 
parameter:

\`\`\`python
@mcp.tool
async def process_data(data: dict, ctx: Context) -> str:
    await ctx.info(
        "Processing started",
        also_log_to_server=True  # Also writes to server logs
    )
    # ... processing logic ...
\`\`\`

This is useful for:
- Server-side monitoring and alerting
- Integration with centralized logging systems
- Debugging server issues without client access
\`\`\`

5. Consider Alternative: Server Setting

As mentioned in the issue, another approach is a server-level setting that automatically logs all ctx messages:

mcp = FastMCP(
    "MyServer",
    settings={"tee_ctx_logs_to_server": True}  # Global setting
)

This could be added as a follow-up enhancement if the per-call parameter proves insufficient.

Related Issues and Pull Requests

Repository	Issue or PR	Relevance
jlowin/fastmcp	#1998: Document logging with OpenTelemetry	OpenTelemetry integration would benefit from server-side ctx logging
jlowin/fastmcp	#847: FastMCP Logging throwing RuntimeWarning	Shows complexity with current ctx logging implementation
jlowin/fastmcp	#525: Can't set logging capability from server	Related to MCP logging capability configuration
jlowin/fastmcp	#133: Additional Examples	Requests examples for logging patterns
jlowin/fastmcp	PR #1974: Updates to Logging Middleware	Shows server-side logging patterns and middleware structure
jlowin/fastmcp	PR #1326: Structured client-side logging	Added `extra` parameter for structured logging
jlowin/fastmcp	PR #1805: Refactor Logging Middleware	Consolidated logging middleware implementation

Related Files

Repository	File	Relevance	Sections
jlowin/fastmcp	src/fastmcp/server/context.py	Contains Context class with logging methods that send to clients	210-342
jlowin/fastmcp	src/fastmcp/utilities/logging.py	FastMCP logging configuration and `get_logger()` utility	13-23
jlowin/fastmcp	src/fastmcp/server/middleware/logging.py	Server-side logging middleware for requests/responses	148-201
jlowin/fastmcp	src/fastmcp/client/logging.py	Client-side log message handling	15-41
jlowin/fastmcp	docs/servers/logging.mdx	Documentation for Context logging methods	1-237
modelcontextprotocol/python-sdk	src/mcp/server/session.py	MCP SDK ServerSession.send_log_message implementation	183-187

Push client logging to logger #2059

Description

Enhancement

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions