server_stop

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

With no annotations provided, the description carries the full burden. It discloses the safety check against the recorded image name before invoking stop(), and explains the rationale (recycled Windows pids could target unrelated processes). It also mentions that stop() calls taskkill, providing concrete behavioral transparency beyond the simple 'stop' action.

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?

Though the description is a few paragraphs, every sentence contributes critical information: main action, two modes, eligibility rules, orphaned access, and safety rationale. It is front-loaded with the primary action and uses structured paragraphs for edge cases, with no filler or redundancy.

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?

For a destructive operation with no annotations and a minimal schema, the description is exceptionally complete. It covers what the tool does, when to use it vs. not, the exact conditions for pid acceptance, the safety mechanism, and the underlying implementation (taskkill). An agent has all necessary context to invoke it correctly.

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?

The schema provides only a pid integer with default 0 and no description, so schema coverage is 0%. The description compensates fully by explaining the semantics of pid: absence stops the session's own server, presence stops a specific pid only if it meets eligibility criteria (started by session or orphaned), and any other pid is refused. This adds deep meaning beyond the bare schema.

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 opens with a clear verb + resource combination: 'Stop a server this session is responsible for.' It distinguishes two modes (own tracked server vs. specific pid) and explicitly differentiates from siblings like server_start and server_status by defining scope ('this session is responsible for').

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 precise when-to-use guidance: no pid stops the session's own server, while a pid stops that specific process only if it was started by the session or reported as orphaned_server_pid. It explicitly refuses any other pid, and states that this is the only way to reach an orphaned server, preventing misuse as a general process killer.

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