Protocol passes every incoming message to the PSR-3 logger as context at info level:
// src/Server/Protocol.php (main @ 3175614b)
$this->logger->info('Received message to process.', ['message' => $input]); // raw JSON input
$this->logger->info('Handling request.', ['request' => $request]); // whole request object
$this->logger->info('Handling response from client.', ['response' => $response]); // sampling/elicitation replies
$this->logger->info('Handling notification.', ['notification' => $notification]);For a tools/call, that's the tool arguments twice, at the level most production setups keep. A sampling or elicitation reply puts what the user typed in the log the same way.
The builder docs (docs/run/server-builder.md, "Logger") show:
$logger = new Logger('mcp-server');
$logger->pushHandler(new StreamHandler('mcp.log', Logger::INFO));Monolog's default LineFormatter writes the full context with each record. So a server set up as documented stores every tool argument in mcp.log. Tool calls can carry content an application wouldn't otherwise log, such as personal data, document text, or credentials a user pastes into a prompt.
CallToolHandler already keeps payloads at debug (Executing tool with arguments, Tool executed successfully with structured_content). That seems like the right split, and Protocol doesn't follow it.
Proposal: at info, log the method and ID only, and move the full payload to debug. For example:
$this->logger->info('Handling request.', ['method' => $request::getMethod(), 'id' => $request->getId()]);
$this->logger->debug('Request payload.', ['request' => $request]);"Received message to process." could drop the raw input at info entirely, since the per-message lines that follow already name the method.
Downstream, the Drupal integration filters payloads out of the context in its logger decorator, because its database log is readable by site administrators: https://git.drupalcode.org/project/mcp_server/-/work_items/3585937. Fixing the levels in the SDK would let every integration control this with a normal log level.
Protocolpasses every incoming message to the PSR-3 logger as context atinfolevel:For a
tools/call, that's the tool arguments twice, at the level most production setups keep. A sampling or elicitation reply puts what the user typed in the log the same way.The builder docs (
docs/run/server-builder.md, "Logger") show:Monolog's default
LineFormatterwrites the full context with each record. So a server set up as documented stores every tool argument inmcp.log. Tool calls can carry content an application wouldn't otherwise log, such as personal data, document text, or credentials a user pastes into a prompt.CallToolHandleralready keeps payloads atdebug(Executing toolwitharguments,Tool executed successfullywithstructured_content). That seems like the right split, andProtocoldoesn't follow it.Proposal: at
info, log the method and ID only, and move the full payload todebug. For example:"Received message to process." could drop the raw input at
infoentirely, since the per-message lines that follow already name the method.Downstream, the Drupal integration filters payloads out of the context in its logger decorator, because its database log is readable by site administrators: https://git.drupalcode.org/project/mcp_server/-/work_items/3585937. Fixing the levels in the SDK would let every integration control this with a normal log level.