MCP Tools: High CPU load

For now, I extended both prod to 8 cores 12GB RAM. I will have to observe if that makes things smoother.


I still think rate limiting MCP tools would be a good idea. As it stands we have very little leeway to configure MCP tools in any way (at least in 2026.1.x)
To combat high loads caused by jobs spanwed MCP tools, it would also be a good idea to be able to configure Computer Groups and Enviroments where the MCP tools are allowed to start jobs.

Should I create a feature request for this?

I agree that rate limiting, computer groups and environments for MCP tools would all be useful and would indeed be a good way to combat this. Is it possible to run these scripts in the integrated environment to avoid spawning processes for MCP tool calls? We could also consider making MCP tools behave more like APIs where they dont necessary spawn a job but instead call into a long running process.

For now I set the environment to Integrated in each script used by the MCP tools and the CPU load is a fraction of what it was before.
But is this really the solution? It goes against best practice and some random MCP job could crash the whole PSU process. Would it be an alternative to create a new persisting environment for MCP tools where the only overhead is serializing the jobs for the new persistent env?

New script params for MCP Tools example:

$Parameters = @{
    Module            = 'psu_mcp_tools'
    Command           = 'Get-MCPDNSRecord'
    Description       = 'Get DNS record information'
    Environment       = 'Integrated'
    TimeOut           = 2
    ConcurrentJobs    = 10
    MaxHistory        = 20
    InformationAction = 'SilentlyContinue'
    ErrorAction       = 'Stop'
}
New-PSUScript @Parameters

Hi schubfre,

Your diagnosis is on the mark: the dominant cost here is not the work the tool does, it is the per-job spawn of a Universal.

Host.exe child process to run a PowerShell session for that single MCP call.
Each spawn pays a full .NET + PowerShell runtime startup, and at >10 in parallel that easily saturates a 4-core box for a few seconds. AV/EDR amplifies the spike (script-block logging, AMSI, image-load callbacks all fire on each new process) but it is not the root cause, just an accelerant.

Before we tune anything, could you run one quick test on 2026.2 (current branch is 2026.2.1) so we have a clean baseline?

You do not need to migrate your prod cluster, a side-by-side instance on your dev VM running the same parallel MCP fan-out is enough.
Reasoning: 2026.1.x is now the maintenance branch and several MCP fixes landed in 2026.2.x.
None of those tickets target the spawn-cost angle directly, so I do not expect the CPU profile to change, but I want to confirm the architecture is the same on the current branch before we agree the FR scope is "both branches". If 2026.2 behaves materially differently, that is a useful data point either way.


In parallel, two settings already in 2026.1.x can give you real relief without waiting on a feature.

First, move the MCP tool scripts to the Integrated environment.

The Integrated environment runs scripts directly inside the PowerShell Universal server process rather than starting an external PowerShell host, so each MCP tool call no longer launches a Universal.Host.exe. The docs are explicit about the performance angle: "you will also see a performance improvement because there is no need to serialize and communicate via interprocess communication" (https://docs.devolutions.net/powershell-universal/config/environments).
You can set this per script via the script's Environment property in the admin UI, or in scripts.ps1 with New-PSUScript -Environment 'Integrated'.

The trade-offs to be aware of: Integrated cannot run a script as alternate credentials, it cannot use Start-Job, and concurrent calls share the worker process and its module state, so heavy modules pre-imported via environments.ps1 for the Integrated environment will load once and stay warm across MCP calls, which is often what you want here.


Second, cap the per-script Concurrent Jobs value.

Each script has a Concurrent Jobs setting that defaults to 100.
Lowering it to, say, 4 to 8 on your MCP tool scripts gives you exactly the rate limit you described, once the cap is hit, additional MCP invocations queue rather than spawning more hosts simultaneously. This is per script today, not a global "MCP throttle", so it acts as a budget per tool rather than across all tools.

Combining the two, an integrated environment plus a low Concurrent Jobs cap, should flatten the CPU spike substantially, even before you finish your AV/EDR work. While you are tuning AV/EDR, the binaries to whitelist for the spawn-driven scenario are Universal.Host.exe (under C:\Program Files (x86)\Universal), pwsh.exe, and powershell.exe.

On your follow-up question, yes, please file the feature requests, and you can file them as two separate items.
We have no internal ticket today that covers either a first-class concurrency / rate-limiting control specifically for the MCP server (the Concurrent Jobs setting is per-script, so it is a workaround, not the dedicated knob you are asking for), or the ability to scope MCP tool invocations to a Computer Group / Environment so an MCP tool can only spawn jobs on a designated node or in a designated environment.

Best regards,