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

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

Why make this change?

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

What is this change?

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

Precedence (highest to lowest):

CLI --LogLevel flag - cannot be changed
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).

How was this tested?

Unit 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, debug message shows "Log level changed to: info"

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)"

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, debug message shows "Log level not changed (Config override active)"

Sample Request(s)

MCP client sends:

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

Server responds with empty result (success) 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

src/Service/Telemetry/DynamicLogLevelProvider.cs

            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

src/Cli/ConfigGenerator.cs

                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

src/Cli/ConfigGenerator.cs

@@ -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

src/Azure.DataApiBuilder.Mcp/Core/McpStdioServer.cs

+            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?

Aniruddh25 · 2026-04-11T00:43:42Z

src/Azure.DataApiBuilder.Mcp/Core/McpStdioServer.cs

+
+            // Attempt to update the log level
+            // If CLI or Config overrode, this returns false but we still return success to the client
+            bool changed = logLevelController.UpdateFromMcp(level);


Even though the level is modified using the level controller, how does it take into effect in STDIO mode? HandleToolCallAsync seems to be writing to the console using WriteError function regardless of the logging level defined by the configuration/CLI/even the logging/setLevel call.

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.

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

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implemented MCP Set Log Level#3419

Implemented MCP Set Log Level#3419
anushakolan wants to merge 2 commits intomainfrom
dev/anushakolan/set-log-level

anushakolan commented Apr 8, 2026 •

edited

Loading

Uh oh!

anushakolan commented Apr 8, 2026

Uh oh!

azure-pipelines bot commented Apr 8, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Apr 8, 2026

Uh oh!

Copilot AI Apr 8, 2026

Uh oh!

Copilot AI Apr 8, 2026

Uh oh!

Aniruddh25 left a comment

Uh oh!

Aniruddh25 Apr 11, 2026

Uh oh!

Aniruddh25 Apr 11, 2026

Uh oh!

Aniruddh25 Apr 11, 2026

Uh oh!

Aniruddh25 left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

	_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!

Why make this change?

What is this change?

How was this tested?

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!

Aniruddh25 Apr 11, 2026

Choose a reason for hiding this comment

Uh oh!

Aniruddh25 Apr 11, 2026

Choose a reason for hiding this comment

Uh oh!

Aniruddh25 Apr 11, 2026

Choose a reason for hiding this comment

Uh oh!

Aniruddh25 left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

anushakolan commented Apr 8, 2026 •

edited

Loading