Skip to main content
Glama
Sign In
SapperMCP

SapperMCP

by MasterX1582
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Kill Processes By Name

kill_processes_by_name

Terminate processes matching a specified name to stop unwanted or stuck tasks, with optional exact-match and force modes plus per-PID results.

Instructions

Kill all processes matching a name. Returns per-pid results.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "kill_processes_by_name"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYes
exactNo
forceNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.7/5.0
Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It says processes are killed but not that termination is irreversible, whether 'force' changes the kill signal or escalation, whether terminating can lose unsaved work, or what permissions are required.

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

Conciseness4/5

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

Two short sentences, front-loaded with the core action. 'Returns per-pid results' is somewhat redundant given an output schema exists, but nothing is bloated.

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

Completeness2/5

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

Output schema covers return values, but this is a destructive, unannotated tool with three entirely undocumented parameters. The description leaves too much for the agent to infer about matching semantics and kill behavior.

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

Parameters2/5

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

Schema description coverage is 0%, so description must compensate. It hints that 'name' is matched, but 'exact' and 'force' are never explained – an agent cannot tell whether 'exact' means case-sensitive/substring/whole-word matching or what 'force' does.

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

Purpose4/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 ('Kill all processes matching a name'), and 'all ... matching a name' distinguishes it from the singular sibling kill_process. However, it does not name the sibling or clarify matching behavior.

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

Usage Guidelines2/5

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

There is no guidance on when to use this rather than kill_process (single target) or find_processes_by_name (discovery before kill). The agent is left to infer that bulk-by-name termination is the intended choice.

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

Deploy Server

Other Tools