Skip to main content
Glama
Sign In
portal

portal

by tiefeiyu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

process_kill

Kill a single process and retain its output for reading. Use process_cleanup to remove the process data.

Instructions

Kill a single process. Its output data is retained for reading. Use process_cleanup to remove it.

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": {
      "id": "<id>"
    },
    "name": "process_kill"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesInternal process ID.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior3/5

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

Without annotations, the description must disclose behavioral traits. It does state two important behaviors: the process is killed and its output data is retained. It also implies that process_cleanup is needed to remove the data. However, it does not clarify whether the kill uses a specific signal, whether it is reversible, or what happens to the process's resources beyond output retention. This is adequate but leaves gaps.

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 two short sentences that each earn their place. The first states the core action, the second adds critical behavioral context and points to the cleanup tool. No waste, front-loaded with the primary verb.

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?

Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers the essential information: what it does, what happens to output, and how to fully clean up. It is slightly incomplete in not specifying return behavior or whether the kill is graceful, but for a simple kill operation this is sufficient.

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

Parameters3/5

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

The input schema fully documents the single parameter 'id' as an internal process ID (100% coverage). The description adds no additional meaning about the parameter, but since the schema already covers it, a baseline 3 is appropriate.

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 the exact action ('Kill a single process') with a specific verb and resource. It distinguishes from siblings by explicitly saying 'single process' (contrasting with process_kill_all) and by indicating 'output data is retained' (contrasting with process_cleanup).

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?

The description provides clear context for when to use this tool: when you need to kill a process but retain its output. It explicitly names process_cleanup as the alternative for removing the output, and 'single process' differentiates from kill_all. It does not mention when to use process_signal or other alternatives, so it misses explicit exclusion guidance, but the core guidance is strong.

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