List monitored targets, their kinds, and last check results. Specify a remote server config to inspect watches on that host, or leave blank for local.
List the targets being watched, with their kind and what the last check recorded
| Name | Required | Description | Default |
|---|---|---|---|
| server | No | Remote server name from config (optional, runs locally if omitted) |
Changes observed during successful MCP inspections.
v0.22.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. 'List' signals a non-mutating read operation, and the output is described well enough for an agent to set expectations. It does not mention optional server scope or edge cases like empty results, but beyond the schema that is minor.
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?
A single, front-loaded sentence covers the action, the target, and the returned data without any filler or repetition. Every part contributes to the purpose.
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?
With one optional parameter, no output schema, and a simple list behavior, the description and schema together are almost fully sufficient. The only missing detail is explicit handling of the optional server scope (e.g., that it queries remote vs local watch lists), but the schema already conveys that.
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 only parameter, server, is 100% described in the input schema (remote server from config, optional, local if omitted), so the description has no obligation to repeat it. The description adds nothing beyond the schema, matching the baseline for high schema coverage.
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 ('List') and resource ('targets being watched'), and further clarifies the output as 'kind and what the last check recorded.' This makes the tool's purpose immediately distinct from the infrastructure-focused siblings like system_status and the history-focused watch_history.
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?
Usage is implied: use this when you want the current watch list and its last recorded result. However, there is no explicit guidance about when to choose watch_list over watch_history or watch_check, or any when-not-to-use note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.