DeepSeek-Reasonix MCP Timeout Settings: Complete Configuration Guide

DeepSeek-Reasonix defines two MCP timeout parameters—mcp_startup_timeout_seconds (default 30 seconds) for server initialization and mcp_call_timeout_seconds (default 300 seconds) for individual JSON-RPC calls—to govern how long the client waits for the Meta-Control-Protocol (MCP) server to respond.

The esengine/DeepSeek-Reasonix repository implements a JSON-RPC client for the MCP protocol that manages external tool servers. These timeout settings control the initialization phase and execution boundaries, ensuring the system can handle both slow-starting services and long-running operations without hanging indefinitely.

Understanding MCP Timeout Settings

DeepSeek-Reasonix communicates with MCP servers through JSON-RPC messages. Two distinct timeout values govern this interaction, both defined in the [tools] configuration section.

mcp_startup_timeout_seconds

This setting controls the upper bound for the background initialization of the MCP server, including the safety cap for tools/list requests. It covers the time required for the server to become ready before any tool calls can be executed.

According to the source code in internal/config/config.go, the default value is 30 seconds. This accommodates typical server startup sequences but may need adjustment for plugins that load large models or perform extensive initialization.

mcp_call_timeout_seconds

This parameter sets the default safety cap for any individual MCP JSON-RPC call, such as tool run or tool list operations. While individual plugins can override this value, the global setting provides a system-wide default.

As implemented in internal/config/config.go, the default value is 300 seconds (5 minutes). When a call exceeds this limit, the client surfaces a timeout error constructed in internal/plugin/plugin.go.

Default Values and Configuration

The timeout values are encapsulated in the Config struct with corresponding accessor methods that handle nil checks and enforce defaults.

Global Configuration

Both settings reside under the [tools] section in your TOML configuration file:

[tools]

# Time to wait for MCP server initialization (default: 30)

mcp_startup_timeout_seconds = 60

# Maximum duration for individual MCP calls (default: 300)

mcp_call_timeout_seconds = 600

These values are parsed from the configuration file and accessed via the MCPStartupTimeoutSeconds() and MCPCallTimeoutSeconds() methods defined in internal/config/config.go.

Per-Plugin Overrides

Individual plugins can override the call timeout while inheriting the global startup timeout:

[[plugins]]
name = "heavy-data-processor"

# Override only for this specific plugin

call_timeout_seconds = 1800  # 30 minutes

This override mechanism allows fine-grained control without affecting other MCP connections.

When to Adjust MCP Timeouts

Adjust these parameters based on your deployment environment and plugin characteristics:

• Slow server startup: Increase mcp_startup_timeout_seconds when using plugins that load large language models or perform complex initialization routines.
• Long-running operations: Raise mcp_call_timeout_seconds (or the per-plugin call_timeout_seconds) for tools that process large datasets, perform extensive API calls, or run heavy inference workloads.
• CI/CD environments: Lower both values to catch hangs early during automated testing.
• Production latency constraints: Tune values downward to meet strict SLAs, ensuring your MCP servers can still complete startup and typical operations within the reduced windows.

Programmatic Access

The configuration methods in internal/config/config.go resolve timeouts with fallback logic to ensure valid values:

func (c *Config) MCPStartupTimeoutSeconds() int {
    if c.Tools.MCPStartupTimeoutSeconds == nil || *c.Tools.MCPStartupTimeoutSeconds <= 0 {
        return defaultMCPStartupTimeoutSeconds // 30
    }
    return *c.Tools.MCPStartupTimeoutSeconds
}

func (c *Config) MCPCallTimeoutSeconds() int {
    if c.Tools.MCPCallTimeoutSeconds == nil || *c.Tools.MCPCallTimeoutSeconds <= 0 {
        return defaultMCPCallTimeoutSeconds // 300
    }
    return *c.Tools.MCPCallTimeoutSeconds
}

These accessors ensure that unset or invalid configuration values default to the safe baselines defined as constants in the same file.

Error Handling and Troubleshooting

When an MCP method exceeds the configured timeout, DeepSeek-Reasonix generates an error message in internal/plugin/plugin.go:

MCP method "…" on server "…" timed out after …; increase mcp_call_timeout_seconds or call_timeout_seconds to allow longer runs

This error indicates which specific limit was breached, allowing you to identify whether you need to adjust the global setting or the plugin-specific override.

Summary

• Two timeout parameters control MCP behavior: mcp_startup_timeout_seconds (default 30s) for initialization and mcp_call_timeout_seconds (default 300s) for execution.
• Configuration location: Both settings reside in the [tools] section of your TOML config, with per-plugin overrides available via call_timeout_seconds.
• Source files: Default values and accessor logic reside in internal/config/config.go, while timeout error messages are constructed in internal/plugin/plugin.go.
• Adjustment triggers: Increase startup timeout for slow-loading models, and increase call timeout for long-running tool executions.

Frequently Asked Questions

What happens when an MCP call exceeds the configured timeout?

The client aborts the request and returns an error indicating which method timed out and after how long. As implemented in internal/plugin/plugin.go, the error message suggests increasing either mcp_call_timeout_seconds or the plugin-specific call_timeout_seconds to accommodate longer-running operations.

Can I set different timeouts for different MCP plugins?

Yes. While mcp_startup_timeout_seconds is global, you can override mcp_call_timeout_seconds for individual plugins by setting call_timeout_seconds within the specific [[plugins]] configuration block. This allows heavy data-processing tools to run longer while keeping stricter limits on lightweight utilities.

Why does my MCP server fail to start even with the default 30-second timeout?

The default mcp_startup_timeout_seconds value may be insufficient for servers that load large machine learning models or establish multiple external connections during initialization. Check your server logs for initialization delays, then increase the startup timeout in the [tools] section to accommodate the actual startup duration.

How do I check the current MCP timeout values at runtime?

The Config struct methods MCPStartupTimeoutSeconds() and MCPCallTimeoutSeconds() in internal/config/config.go return the effective values after resolving defaults and configuration file settings. These methods handle nil pointer checks, ensuring they return the actual timeouts being used by the MCP client.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}