Skip to content

feat: make MCP tool request timeout configurable#262

Open
fudujiji wants to merge 1 commit into
mozilla-ai:mainfrom
fudujiji:draft/mcpd-request-timeout
Open

feat: make MCP tool request timeout configurable#262
fudujiji wants to merge 1 commit into
mozilla-ai:mainfrom
fudujiji:draft/mcpd-request-timeout

Conversation

@fudujiji

@fudujiji fudujiji commented Jun 1, 2026

Copy link
Copy Markdown

Summary

  • Add mcp.timeout.request to daemon config get/set/list handling.
  • Use the configured request timeout for MCP tool calls instead of the previous hard-coded 15s deadline.
  • Document the new setting in docs/daemon-configuration.md.

Verification

  • go test ./internal/config ./internal/api ./internal/daemon ./cmd
  • go test ./...
  • git diff --check

Summary by CodeRabbit

Release Notes

New Features

  • MCP tool-call request timeout is now configurable via the mcp.timeout.request parameter, with a default of 15 seconds.

Documentation

  • Configuration guide updated with documentation and CLI examples for the new MCP request timeout setting.

@coderabbitai

coderabbitai Bot commented Jun 1, 2026

Copy link
Copy Markdown

Review Change Stack

Walkthrough

This PR adds configurable MCP tool-call request timeout throughout the system. The timeout flows from configuration schema and daemon CLI flags, through API options and route registration, into request handlers that apply it as a context deadline. All configuration paths and timeout application are tested.

Changes

MCP Request Timeout Configuration

Layer / File(s) Summary
Configuration schema and access patterns
internal/config/daemon_config.go
MCPTimeoutConfigSection gains Request *Duration field; AvailableKeys, Get, Set, Validate, and getAll are extended to expose and validate the request timeout as a duration.
Daemon command loading and flag validation
cmd/daemon.go
Daemon CLI loads MCP request timeout from config via loadConfigMCPTimeout, parses flag-set overrides in validateFlags, builds API options with WithToolCallTimeout in buildAPIOptions, and displays the configured value in formatConfigInfo dev-mode banner.
API options and timeout constants
internal/daemon/api_options.go
APIOptions struct gains ToolCallTimeout field initialised to DefaultToolCallTimeout(); WithToolCallTimeout option validates positive duration and DefaultToolCallTimeout() provides the shared 15-second default.
Route registration with functional options
internal/api/routes.go
Introduces RouteOptions struct and RouteOption functional option pattern; RegisterRoutes now accepts opts ...RouteOption, computes options (defaulting to 15 seconds), and passes to route registration.
Server route handler signatures and wiring
internal/api/servers.go, internal/api/tools.go
RegisterServerRoutes and RegisterToolRoutes signatures updated to accept RouteOptions; timeout is threaded through to handleServerToolCall invocation.
Tool call handler context and timeout logic
internal/api/servers.go
handleServerToolCall signature extended with explicit ctx and timeout parameters; implementation derives timeout context from provided context and duration (defaulting to DefaultToolCallTimeout() when non-positive).
API server startup and route registration
internal/daemon/api_server.go
APIServer gains toolCallTimeout field wired from apiOpts.ToolCallTimeout; route registration at startup now applies WithToolCallTimeout option.
Configuration tests, handler tests, and documentation
cmd/daemon_test.go, internal/config/daemon_config_test.go, internal/api/servers_test.go, docs/daemon-configuration.md
Configuration tests validate request timeout schema access, precedence, and validation; handler tests verify context deadline application; TestHandleServerToolCall_UsesConfiguredTimeout confirms timeout is used; docs add mcp.timeout.request parameter with default 15 seconds and usage examples.

Possibly related issues

  • mozilla-ai/mcpd#256: This PR directly implements the requested mcp.timeout.request configuration field and complete integration path through config loading, API wiring, route options, handler invocation, tests, and documentation.
🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 46.43% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The pull request title accurately summarizes the main change: making the MCP tool request timeout configurable instead of hard-coded.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@cmd/daemon.go`:
- Around line 147-148: Add a CLI flag so mcpRequest can be overridden like the
other timeouts: define a new flag constant (e.g., flagMCPRequestTimeout) and add
a corresponding flag in newDaemonCobraCmd alongside the existing
apiShutdown/mcpInit/mcpShutdown/healthCheck flags, then update
loadConfigMCPTimeout to check the new flag and override the config value when
present; target the mcpRequest field and the new flag name in your changes so
the CLI takes precedence over config when provided.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 41e9c53b-008a-4f87-9785-13cb48be99a0

📥 Commits

Reviewing files that changed from the base of the PR and between bb2a210 and 98b6ad3.

📒 Files selected for processing (11)
  • cmd/daemon.go
  • cmd/daemon_test.go
  • docs/daemon-configuration.md
  • internal/api/routes.go
  • internal/api/servers.go
  • internal/api/servers_test.go
  • internal/api/tools.go
  • internal/config/daemon_config.go
  • internal/config/daemon_config_test.go
  • internal/daemon/api_options.go
  • internal/daemon/api_server.go

Comment thread cmd/daemon.go
Comment on lines +147 to +148
// mcpRequest specifies how long to wait for MCP tool call requests.
mcpRequest string

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick | 🔵 Trivial | ⚡ Quick win

Consider adding a CLI flag for consistency.

All other timeout settings (apiShutdown, mcpInit, mcpShutdown, healthCheck) have corresponding CLI flags defined in newDaemonCobraCmd, but mcpRequest does not. This means the MCP request timeout can only be configured via the config file, not via command-line flags, which is inconsistent with the other timeouts and limits runtime configurability.

🔧 Add CLI flag for parity with other timeouts

Add a flag constant and flag definition in newDaemonCobraCmd:

 const (
 	// flagTimeoutMCPShutdown is the flag name for timeout when shutting down the MCP client.
 	flagTimeoutMCPShutdown = "timeout-mcp-shutdown"
+
+	// flagTimeoutMCPRequest is the flag name for MCP tool call request timeout.
+	flagTimeoutMCPRequest = "timeout-mcp-request"
 
 	// flagIntervalMCPHealth is the flag name for MCP server health check interval.
 	flagIntervalMCPHealth = "interval-mcp-health"

Then add the flag in newDaemonCobraCmd after the other timeout flags:

 	cobraCommand.Flags().StringVar(
 		&daemonCmd.config.timeout.mcpShutdown,
 		flagTimeoutMCPShutdown,
 		daemon.DefaultClientShutdownTimeout().String(),
 		"Timeout in seconds to wait for shutdown of MCP servers (e.g. 5s, 10s)",
 	)
+
+	cobraCommand.Flags().StringVar(
+		&daemonCmd.config.timeout.mcpRequest,
+		flagTimeoutMCPRequest,
+		daemon.DefaultToolCallTimeout().String(),
+		"Timeout in seconds to wait for MCP tool call requests (e.g. 5s, 15s)",
+	)

And add flag override logic in loadConfigMCPTimeout:

 	// Handle MCP request timeout.
 	if timeout.Request != nil {
 		parsed := timeout.Request.String()
-		logger.Debug("Using config file value", "setting", "mcp.timeout.request", "value", parsed)
-		c.config.timeout.mcpRequest = parsed
+
+		if cmd.Flags().Changed(flagTimeoutMCPRequest) {
+			warnings = append(
+				warnings,
+				flagOverrideWarning(flagTimeoutMCPRequest, parsed, c.config.timeout.mcpRequest),
+			)
+			logger.Debug("Flag overriding config value", "flag", flagTimeoutMCPRequest,
+				"config", parsed, "using", c.config.timeout.mcpRequest)
+		} else {
+			logger.Debug("Using config file value", "setting", "mcp.timeout.request", "value", parsed)
+			c.config.timeout.mcpRequest = parsed
+		}
 	}
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@cmd/daemon.go` around lines 147 - 148, Add a CLI flag so mcpRequest can be
overridden like the other timeouts: define a new flag constant (e.g.,
flagMCPRequestTimeout) and add a corresponding flag in newDaemonCobraCmd
alongside the existing apiShutdown/mcpInit/mcpShutdown/healthCheck flags, then
update loadConfigMCPTimeout to check the new flag and override the config value
when present; target the mcpRequest field and the new flag name in your changes
so the CLI takes precedence over config when provided.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant