get_process_info

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

With no annotations provided, the description carries the full burden of disclosing behavior. It explicitly states 'Does not modify system state,' which is a key read-only trait. However, it does not mention potential failure modes (e.g., process not found), permission requirements, or whether the operation is instantaneous or expensive. For a simple getter, this is minimal but adequate; additional error or side-effect disclosure would improve it.

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?

The description is two tightly written sentences. The first sentence front-loads the core purpose and the exact fields returned; the second sentence gives usage guidance and a behavioral note. Every word earns its place, with no filler or repetition. This is a model of concise structuring.

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?

Given that an output schema exists and defines the return structure, the description does not need to enumerate return fields. It covers the purpose, input, usage context, and non-destructive nature. It does not cover error cases or provide details on how to handle invalid pids, but for a simple informational tool this is near-complete. The absence of explicit alternatives slightly reduces completeness, but the reference to list_processes anchors the workflow well.

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% because the description never explicitly names 'pid' or describes its format. However, the phrase 'specific process' and the single required parameter make it obvious that pid is the process identifier. The description indirectly compensates by establishing the context, but it does not add explicit detail like units or allowed range. Given there is only one obvious parameter, this is acceptable but not exceptional. A baseline of 3 is appropriate.

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?

The description clearly states the input (a specific process) and the output (PID, parent PID, name, status, user, CPU%, memory%, command line, working directory). It explicitly says 'specific process' and references list_processes, distinguishing it from sibling tools like get_cpu_usage that report system-wide metrics. This is a specific verb-resource pairing with no ambiguity.

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?

The description provides explicit guidance: 'Use this when investigating a specific process identified by list_processes or other tools.' This tells the agent when to invoke it and ties it to a workflow. It does not explicitly state when not to use it, but the context of 'specific process' vs. the sibling set makes the exclusion implicit. The note 'Does not modify system state' adds a relevant constraint. Slightly more explicit comparison to alternatives would earn a 5.

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