Hermes Agent 0.21.4 Sets Default MCP Startup Concurrency to Four, Reducing Process Load Spikes

Nous Research released Hermes Agent 0.21.4 on September 21, incorporating recent fixes into an official release tag for Docker, Hermes Cloud, and hosted deployments. Among the changes, MCP tool discovery gains a startup concurrency limit to address large numbers of tool servers spawning subprocesses simultaneously when the agent starts. Consolidated release notes are still planned for 0.22.0. [Release announcement](https://github.com/NousResearch/hermes-agent/releases/tag/v2026.9.21)

The previous workflow connected to all candidate servers simultaneously. Each MCP service using standard input/output (stdio) transport could, in turn, spawn its own subprocess tree. The new version connects to at most four services concurrently during each discovery round. The limit is configurable through `mcp.discovery_concurrency`, with zero restoring unlimited concurrency. It limits concurrent connection establishment, not subsequent tool calls. [Discovery mechanism](https://hermes-agent.nousresearch.com/docs/user-guide/features/mcp)

Batching also changes timeout semantics. The discovery budget calculates the number of batches from the service count and concurrency limit, allocating 120 seconds per batch, with a maximum of 300 seconds for the entire round. The cross-process lock-wait budget is set to 320 seconds. This prevents later waiters from giving up on the lock prematurely and launching the same set of tools again while discovery is still underway. [Lock-wait fix](https://github.com/NousResearch/hermes-agent/pull/117956)

Maintainers reproduced the behavior with eight simulated services: before the fix, peak concurrent startups reached eight; with the default setting, that fell to four, while all eight services still connected successfully. However, the total time increased from 4 seconds to 5.6 seconds. With the limit reduced to two, the test took 13.2 seconds. This trades longer startup time for a smoother load profile. It does not demonstrate that memory usage was halved, nor should it be treated as a capacity benchmark for real services. [Reproduction results](https://github.com/NousResearch/hermes-agent/pull/117956)

The official documentation confirms that the limit applies to discovery triggered by startup, reloads, and configuration monitoring. From an engineering perspective, it should be understood as a “concurrent connection limit per discovery round”; it does not imply that only four MCP processes can exist on the entire host. Deployers should check that all tools are registered, determine whether slow services hit the overall discovery deadline, and measure startup peaks and wait times. The number of resident processes after connections are established still depends on the actual tool configuration. [MCP runtime behavior](https://hermes-agent.nousresearch.com/docs/user-guide/features/mcp)

The documentation also describes lazy startup, which can be used alongside this limit: services with a valid schema cache can register their tools first and defer connecting until the first call. New services, or services whose configuration has changed, must still connect first. This lets teams manage startup peaks and idle costs separately, but they should also verify the latency of the first tool call and whether the cache reflects the service’s current capabilities. [Lazy startup](https://hermes-agent.nousresearch.com/docs/user-guide/features/mcp)