Définir les niveaux de journalisation à l’exécution

Sometimes a user wants quiet logs, sometimes deep detail. MCP lets the client set a log level at runtime instead of restarting the server.

The client sends a logging/setLevel request naming the lowest level it wants. This is a request, so the server replies to confirm.

A server only receives setLevel if it advertised the logging capability during the initialize handshake. FastMCP enables this for you.

The chosen level is a threshold. Setting it to warning means warning and everything more severe gets through; quieter messages are dropped.

After setLevel, the server compares each log's severity against the floor. Anything below the threshold is simply not sent to that client.

To debug a tricky run, a client can set the level to debug. Now every message, even the noisy traces, streams back for inspection.

For a calm production view, set it to error. Only failures arrive, keeping the user's screen free of routine chatter.

The level applies to that client's session. Changing it later just moves the floor; it does not need a fresh connection or reload.

Before any setLevel arrives, the server uses its own default floor, often info. Always log richly and let the client choose what to keep.

Runtime levels mean you ship one build that is quiet by default yet ready to go verbose the moment a user reports a hard-to-find bug.

This dial controls the same ctx.info and ctx.debug calls you write. The client picks the floor; your code just logs at honest levels.

Reason about what a chosen log level actually filters.

You learned that logging/setLevel sets a runtime floor, how filtering drops quieter messages, and why this keeps one build flexible. Excellent!