View recorded alert and remediation history for your homelab. Empty results indicate no watcher was running, not that nothing went wrong.
Show recorded alert and remediation history. Entries are only written while a watcher is running, so an empty list means nothing was recording rather than nothing went wrong
| Name | Required | Description | Default |
|---|---|---|---|
| server | No | Remote server name from config (optional, runs locally if omitted) |
Changes observed during successful MCP inspections.
v0.31.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds a valuable caveat about recording semantics and the meaning of an empty result, which goes beyond a basic summary. It does not describe output formatting or authorization, but for a simple read-only history tool this is adequate.
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 a single, focused sentence that front-loads the core purpose and then adds a high-value interpretive caveat. There is no redundant or filler content.
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 low-complexity tool with one optional, schema-documented parameter and no output schema, the description covers the essential interpretive context. The main missing element is an explicit statement that this is a read-only operation, though the verb 'Show' strongly implies it.
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 100%, and the single optional 'server' parameter is already fully documented in the schema. The description adds no additional parameter semantics, so the baseline score 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 uses a specific verb-resource pair, 'Show recorded alert and remediation history,' which clearly identifies the tool's function. It is distinct from sibling 'alerts' by emphasizing recorded history, though it does not explicitly name or contrast itself with related tools like '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?
The description provides important contextual guidance: history is only written while a watcher is running, and an empty list means nothing was recording rather than nothing went wrong. This clarifies when results may be misleading, though it does not explicitly direct the agent to alternatives like 'watch_history' or 'alerts.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.