Implemented MCP Set Log Level by anushakolan · Pull Request #3419 · Azure/data-api-builder

anushakolan · 2026-04-08T20:13:26Z

PR Description

Note: This PR includes changes from PR #3420 which has been merged into this branch.

Why make this change?

Closes #3274 - MCP Server returns "Method not found: logging/setLevel" error when clients send the standard MCP logging/setLevel request.

Closes #3275 - Control output in MCP stdio mode (default to LogLevel.None, redirect/suppress console output).

What is this change?

MCP `logging/setLevel` Handler

Added handler for logging/setLevel JSON-RPC method in McpStdioServer.cs
Implemented DynamicLogLevelProvider with ILogLevelController interface to allow MCP to update log levels dynamically
Added IsCliOverridden and IsConfigOverridden properties to enforce precedence rules

Log Level Precedence System

Precedence (highest to lowest):

CLI --LogLevel flag - cannot be changed by MCP
Config runtime.telemetry.log-level - cannot be changed by MCP
MCP logging/setLevel - only works if neither CLI nor config set a level

If CLI or config set a level, MCP requests are accepted but silently ignored (no error returned per MCP spec).

Early Config Reading for MCP Mode

Added TryGetLogLevelFromConfig() in Program.cs to read config file early (before host build)
This ensures config log level is detected before Console redirect decision
Console redirect for MCP stdio mode now respects config log level

CLI Log Level Handling

Added Utils.CliLogLevel property to track the parsed --LogLevel value
CLI's CustomLoggerProvider now respects the --LogLevel value for its own logging

Config Helpers

Added HasExplicitLogLevel() helper to RuntimeConfig to correctly detect when config actually pins a log level
This properly handles null values in telemetry section (null values don't count as explicit override)

How was this tested?

Unit Tests (DynamicLogLevelProviderTests - 5 tests)
Manual Testing

Manual Test 1: No override (MCP can change level)

Start MCP server without --LogLevel and without config log-level
MCP sends logging/setLevel with level: info
Result: Log level changes to info

Manual Test 2: CLI override (MCP blocked)

Start MCP server with --LogLevel Warning
MCP sends logging/setLevel with level: info
Result: Log level stays at Warning, MCP request accepted silently

Manual Test 3: Config override (MCP blocked)

Add "telemetry": { "log-level": { "default": "Warning" } } to config
Start MCP server without --LogLevel
MCP sends logging/setLevel with level: info
Result: Log level stays at Warning, MCP request accepted silently

Manual Test 4: Config with null values (MCP can change level)

Add "telemetry": { "log-level": { "default": null } } to config
Start MCP server without --LogLevel
MCP sends logging/setLevel with level: info
Result: Log level changes to info (null values don't count as override)

Manual Test 5: CLI `--LogLevel Trace` shows verbose logs

Start MCP server with --LogLevel Trace
Result: Trace/Debug level logs visible in stderr

Manual Test 6: CLI `--LogLevel None` suppresses all output

Start MCP server with --LogLevel None
Result: Zero output to stderr, stdout clean for JSON-RPC

Manual Test 7: Config log level respected at startup

Add "telemetry": { "log-level": { "default": "Error" } } to config
Start MCP server without --LogLevel
Result: Only Error/Critical logs shown (no Info/Debug startup noise)

Sample Request(s)

MCP client sends:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "logging/setLevel",
  "params": {
    "level": "info"
  }
}

Server responds with empty result (success per MCP spec) and updates log level if no CLI/config override is active.

anushakolan · 2026-04-08T20:13:33Z

/azp run

azure-pipelines · 2026-04-08T20:13:41Z

Azure Pipelines will not run the associated pipelines, because the pull request was updated after the run command was issued. Review the pull request again and issue a new run command.

Copilot

Pull request overview

This PR addresses MCP stdio clients receiving Method not found: logging/setLevel by adding support for the logging/setLevel JSON-RPC method and wiring it to DAB’s dynamic log-level infrastructure with explicit precedence rules (CLI > config > MCP).

Changes:

Added logging/setLevel dispatch + handler in McpStdioServer to accept the standard MCP request and (when allowed) update runtime log level.
Introduced ILogLevelController and implemented it in DynamicLogLevelProvider, including CLI/config precedence tracking.
Updated CLI engine-launch argument construction to only pass --LogLevel when explicitly provided, plus added unit tests for MCP log-level updates.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/Service/Telemetry/DynamicLogLevelProvider.cs	Implements `ILogLevelController`, adds MCP level mapping and precedence handling (CLI/config/MCP).
src/Service/Program.cs	Registers `ILogLevelController` in DI so MCP can resolve the controller.
src/Service.Tests/UnitTests/DynamicLogLevelProviderTests.cs	Adds unit tests for MCP-driven log-level changes and override behavior.
src/Core/Telemetry/ILogLevelController.cs	New interface to decouple MCP from the concrete log-level provider.
src/Cli/ConfigGenerator.cs	Only forwards `--LogLevel` when explicitly set by the user (to avoid treating defaults as CLI overrides).
src/Azure.DataApiBuilder.Mcp/Core/McpStdioServer.cs	Adds `logging/setLevel` handler that calls into `ILogLevelController`.

Copilot · 2026-04-08T20:21:24Z

            if (!IsCliOverridden)
            {
                CurrentLogLevel = runtimeConfig.GetConfiguredLogLevel();
+
+                // Track if config explicitly set a log level (not just using defaults)
+                IsConfigOverridden = !runtimeConfig.IsLogLevelNull();
+            }


IsConfigOverridden is derived from !runtimeConfig.IsLogLevelNull(), but the schema allows runtime.telemetry.log-level values to be null (meaning “use host-mode defaults”). In that case IsLogLevelNull() returns false (because the dictionary exists), causing MCP logging/setLevel to be blocked even though config did not actually pin a log level. Consider treating config as “overridden” only when at least one configured log-level value is non-null (e.g., any entry value != null), or add a dedicated RuntimeConfig helper for this distinction.

Copilot · 2026-04-08T20:21:24Z

                minimumLogLevel = deserializedRuntimeConfig.GetConfiguredLogLevel();
                HostMode hostModeType = deserializedRuntimeConfig.IsDevelopmentMode() ? HostMode.Development : HostMode.Production;

                _logger.LogInformation($"Setting default minimum LogLevel: {minimumLogLevel} for {hostModeType} mode.", minimumLogLevel, hostModeType);


In the default log-level branch, _logger.LogInformation($"Setting default minimum LogLevel: {minimumLogLevel} for {hostModeType} mode.", minimumLogLevel, hostModeType); uses an interpolated string while also passing structured args—those args won’t be captured as structured fields. Use a message template without $"..." (or remove the extra args) so logging behaves as intended.

Suggested change

_logger.LogInformation($"Setting default minimum LogLevel: {minimumLogLevel} for {hostModeType} mode.", minimumLogLevel, hostModeType);

_logger.LogInformation("Setting default minimum LogLevel: {minimumLogLevel} for {hostModeType} mode.", minimumLogLevel, hostModeType);

Copilot · 2026-04-08T20:21:25Z

@@ -2597,17 +2598,22 @@ public static bool TryStartEngineWithOptions(StartOptions options, FileSystemRun

                minimumLogLevel = (LogLevel)options.LogLevel;
                _logger.LogInformation("Setting minimum LogLevel: {minimumLogLevel}.", minimumLogLevel);
+
+                // Only add --LogLevel when user explicitly specified it via CLI.
+                // This allows MCP logging/setLevel to work when no CLI override is present.
+                args.Add("--LogLevel");
+                args.Add(minimumLogLevel.ToString());
            }
            else
            {
                minimumLogLevel = deserializedRuntimeConfig.GetConfiguredLogLevel();
                HostMode hostModeType = deserializedRuntimeConfig.IsDevelopmentMode() ? HostMode.Development : HostMode.Production;

                _logger.LogInformation($"Setting default minimum LogLevel: {minimumLogLevel} for {hostModeType} mode.", minimumLogLevel, hostModeType);
-            }

-            args.Add("--LogLevel");
-            args.Add(minimumLogLevel.ToString());
+                // Don't add --LogLevel arg since user didn't explicitly set it.
+                // Service will determine default log level based on config or host mode.
+            }


After this change, when options.LogLevel is not provided the CLI no longer passes --LogLevel to the engine. The Service defaults to LogLevel.Error when --LogLevel is absent (Program.GetLogLevelFromCommandLineArgs), so early startup logs will be suppressed even in Development until DynamicLogLevelProvider.UpdateFromRuntimeConfig(...) runs. If the intent is to keep the existing “Debug in Development / Error in Production” default behavior while still allowing MCP to change the level, consider setting the initial log level from the loaded config earlier in host construction (or introducing a non-override mechanism distinct from the CLI override flag).

Aniruddh25

Dont understand how the log level set by MCP tool call takes into effect. Can you show a working demo?

Aniruddh25 · 2026-04-11T00:39:00Z

+            bool changed = logLevelController.UpdateFromMcp(level);
+            if (changed)
+            {
+                Console.Error.WriteLine($"[MCP DEBUG] Log level changed to: {level}");


Where are these debug messages output? Will those confuse the agent?
Also, what if the LogLevel set by CLI is None. Do these debug messages still be shown? If not, how do you prevent them if you send them to Console.Error.WriteLine?

Do we really need these console messages?

No removed them

The resolution comment says - removed them, but I dont see the change pushed to remote yet. Reopening this comment so that this is not forgotten.

Please resolve a comment only "after" pushing to remote.

Aniruddh25

Manual Test 2: CLI override (MCP blocked)
Start MCP server with --LogLevel None
MCP sends logging/setLevel with level: info
Result: Log level stays at None, debug message shows "Log level not changed (CLI override active)"

As far as I understand, there should be no debug message altogether given that LogLevel has been defined as None through CLI.
So, why does the description above say Result shows "Log level not changed"?

anushakolan · 2026-04-22T23:56:11Z

Manual Test 2: CLI override (MCP blocked)
Start MCP server with --LogLevel None
MCP sends logging/setLevel with level: info
Result: Log level stays at None, debug message shows "Log level not changed (CLI override active)"

As far as I understand, there should be no debug message altogether given that LogLevel has been defined as None through CLI. So, why does the description above say Result shows "Log level not changed"?

Because it was writing directly to stderr. Those [[MCP DEBUG]] messages would still appear because they bypassed ILoggerfiltering and wrote directly to stderr. That's why we removed them.

Aniruddh25 · 2026-04-23T22:49:00Z

Note: This PR includes changes from #3420 which has been merged into this branch.

PR #3420 has not been merged into this branch, has it?

RubenCerna2079 · 2026-04-24T19:12:44Z

+        /// Log level precedence (highest to lowest):
+        /// 1. CLI --LogLevel flag - cannot be overridden
+        /// 2. Config runtime.telemetry.log-level - cannot be overridden by MCP
+        /// 3. MCP logging/setLevel - only works if neither CLI nor Config explicitly set a level


nit: I would also add as a 4th log level precedence that the log level is set depending on whether DAB is started in Production/Development mode

RubenCerna2079 · 2026-04-24T19:14:48Z

+        /// 2. Config runtime.telemetry.log-level - cannot be overridden by MCP
+        /// 3. MCP logging/setLevel - only works if neither CLI nor Config explicitly set a level
+        /// 
+        /// If CLI or Config set the log level, this method accepts the request but silently ignores it.


Wouldn't it be better to throw a warning that the request was ignored? I think it would be more beneficial to the user.

RubenCerna2079 · 2026-04-24T19:27:01Z

+            if (logLevelController is null)
+            {
+                // Log level controller not available - still accept request per MCP spec
+                Console.Error.WriteLine("[MCP DEBUG] ILogLevelController not available, logging/setLevel ignored.");


Just confirming, this is something that will need to be changed so it is buffered in my PR right?

Just saw Ani's comment below, will this be removed as well?

RubenCerna2079 · 2026-04-24T19:35:18Z

+                // Only add --LogLevel when user explicitly specified it via CLI.
+                // This allows MCP logging/setLevel to work when no CLI override is present.
+                args.Add("--LogLevel");


I see that some of the changes in the PR #3420 are included here, I think it would be better to have it only in one, so it is not confusing.

RubenCerna2079 · 2026-04-24T19:42:38Z

                .ConfigureServices((context, services) =>
                {
                    services.AddSingleton(LogLevelProvider);
+                    services.AddSingleton<ILogLevelController>(LogLevelProvider);


Why wouldn't we want only 1 signleton?

RubenCerna2079 · 2026-04-24T19:50:49Z

    {
+        /// <summary>
+        /// Maps MCP log level strings to Microsoft.Extensions.Logging.LogLevel.
+        /// MCP levels: debug, info, notice, warning, error, critical, alert, emergency.


Does MCP not have a none log level?

RubenCerna2079 · 2026-04-24T19:54:49Z

+                return false;
+            }
+
+            if (string.IsNullOrWhiteSpace(mcpLevel))


From the way that you use this function in the McpStdioServer.cs, the mcpLevel shouldn't even have the possibility of being empty or null. I think it would be better to throw an error for this case.

Implemented MCP Set Log Level

deb9866

Merge branch 'main' into dev/anushakolan/set-log-level

0e64f62

anushakolan marked this pull request as ready for review April 8, 2026 20:14

Copilot AI review requested due to automatic review settings April 8, 2026 20:14

anushakolan requested review from Alekhya-Polavarapu, Aniruddh25, JerryNixon, RubenCerna2079, aaronburtle, rusamant, sourabh1007, souvikghosh04, stuartpa and vadeveka as code owners April 8, 2026 20:14

anushakolan assigned aaronburtle and Aniruddh25 Apr 8, 2026

Copilot started reviewing on behalf of anushakolan April 8, 2026 20:17 View session

Copilot AI reviewed Apr 8, 2026

View reviewed changes

Aniruddh25 requested changes Apr 11, 2026

View reviewed changes

Aniruddh25 assigned RubenCerna2079 and unassigned aaronburtle Apr 23, 2026

RubenCerna2079 reviewed Apr 24, 2026

View reviewed changes

	_logger.LogInformation($"Setting default minimum LogLevel: {minimumLogLevel} for {hostModeType} mode.", minimumLogLevel, hostModeType);
	_logger.LogInformation("Setting default minimum LogLevel: {minimumLogLevel} for {hostModeType} mode.", minimumLogLevel, hostModeType);

Conversation

anushakolan commented Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Description

Why make this change?

What is this change?

MCP logging/setLevel Handler

Log Level Precedence System

Early Config Reading for MCP Mode

CLI Log Level Handling

Config Helpers

How was this tested?

Manual Test 1: No override (MCP can change level)

Manual Test 2: CLI override (MCP blocked)

Manual Test 3: Config override (MCP blocked)

Manual Test 4: Config with null values (MCP can change level)

Manual Test 5: CLI --LogLevel Trace shows verbose logs

Manual Test 6: CLI --LogLevel None suppresses all output

Manual Test 7: Config log level respected at startup

Sample Request(s)

Uh oh!

anushakolan commented Apr 8, 2026

Uh oh!

azure-pipelines Bot commented Apr 8, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Apr 8, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 8, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 8, 2026

Choose a reason for hiding this comment

Uh oh!

Aniruddh25 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Aniruddh25 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

anushakolan commented Apr 22, 2026

Uh oh!

Aniruddh25 commented Apr 23, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

anushakolan commented Apr 8, 2026 •

edited

Loading

MCP `logging/setLevel` Handler

Manual Test 5: CLI `--LogLevel Trace` shows verbose logs

Manual Test 6: CLI `--LogLevel None` suppresses all output

Aniruddh25 left a comment •

edited

Loading