Skip to main content
Glama

suspend_process

DestructiveIdempotent

Suspend all threads of a process to stop its CPU use until resumed; critical processes are refused, and games or anti-cheat programs require force=true.

Instructions

Suspends every thread of a process: it stops using the CPU until resumed (its windows stop responding meanwhile). Critical processes and Anabolic are refused; a game or anti-cheat program needs force=true.

Input Schema

NameRequiredDescriptionDefault
pidYesThe process ID.
forceNoTrue only after the user agreed to the risk this tool described.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the destructive/non-readonly annotations, it discloses exactly what suspension affects: all threads stop using the CPU and windows stop responding. It also discloses refusal conditions and the special force=true requirement for games or anti-cheat programs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and effect, then adds the key exceptions and force requirement. It is compact with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter mutation tool with full schema coverage and meaningful annotations, the description covers effects, refusals, and the force condition well. A minor gap is that it does not mention privilege/elevation requirements, and the term 'Anabolic' is not explained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the schema carries the basic parameter documentation. The description adds meaningful force semantics by explaining that game or anti-cheat processes require force=true, going beyond the schema's generic consent wording.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: suspend every thread of a process. It also clarifies the reversible effect ('until resumed') and user-visible impact ('windows stop responding'), which distinguishes it from termination tools such as end_process and from resume_process.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear usage context: critical processes and Anabolic are refused, and game/anti-cheat processes require force=true. It does not explicitly compare this tool to end_process, limit_process, or resume_process, so the when-to-choose guidance is not fully exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.