kill_process

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

With no annotations, the description carries the full disclosure burden. It usefully explains the signal semantics (SIGKILL vs graceful SIGTERM), which is real behavioral value, but omits the destructive and irreversible nature of the operation, permission requirements, what happens if a process_name matches multiple processes, and whether child processes are affected.

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

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

Front-loaded one-line purpose followed by a compact Args block; every line carries information. The doubled verb 'Stop/terminate' is minor redundancy but the structure is easy to scan.

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

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

An output schema exists, so return values need not be explained, but for an unannotated destructive process-killing tool the definition should state safety implications and name-matching behavior. Those omissions leave it adequate but not complete for its risk level.

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

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

Schema description coverage is 0%, so the description must supply all parameter meaning, and it defines each of the three: pid, process_name (used when pid is absent), and force as SIGKILL vs SIGTERM. Gaps remain around what happens if both or neither of pid/process_name are supplied and how name matching is resolved, which keeps it below a 5.

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

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

States a specific verb and resource (stop/terminate a running process) plus the two selection modes, PID or process name, so the agent knows exactly what the tool acts on. It never contrasts itself with siblings such as list_processes, start_process, or free_serial_port, so the differentiation must be inferred from the name alone.

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

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

There is no when-to-use guidance, no mention of alternatives (e.g. free_serial_port for port occupiers, list_processes to find a PID first), and no stated preconditions such as needing the PID to exist. The only selection hint is the parenthetical that process_name applies if pid is not specified, which is parameter routing rather than usage guidance.

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