client_stop

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

With no annotations provided, the description carries the full burden and succeeds. It discloses the side effects: stopping the client, unplugging the virtual controller, and intentionally discarding the pad. It also explains the consequence of leaving a controller attached, including a concrete example with DayZ switching on-screen hints to controller mode.

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 appropriately detailed and well-structured, front-loading the core action before explaining side effects and the deliberate absence of a pid parameter. Every sentence earns its place, including the DayZ example, which concretely justifies why the controller must be unplugged.

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 the tool has no parameters and an output schema exists, the description need not explain return values. It fully covers what the tool does, when to use it, why it has no parameters, and the behavioral consequences of not using it. Nothing necessary for an agent to call it correctly is missing.

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?

There are zero parameters and the schema is empty, which gives a baseline of 4. The description goes further by explaining why there is no pid parameter: the client and server share the same executable, so a pid argument could not be safely validated and would turn the tool into a generic process killer. This adds meaningful rationale beyond the empty 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 names a specific verb and resource: 'Stop the client this session started' and 'unplug the virtual controller.' It also explicitly distinguishes itself from server_stop by explaining that client_stop takes no pid because the client shares an executable with the server, preventing it from becoming a general process killer.

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?

It clearly defines when to use the tool: 'Stopping the client is the end of the input session, so it is where the device is given back.' It also states that 'Nothing else in this tool set closes it,' ruling out alternatives, and explains why the pid-based approach of server_stop does not apply.

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