Skip to main content
Glama

watch_history

Read-only

List recent container restart incidents newest first, with optional before-and-after logs, to help diagnose recurring failures across local or remote servers.

Instructions

List recorded restart incidents, newest first. Captured logs are excluded unless include_logs is set, because every incident carries a hundred lines of output twice over

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "watch_history"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMost recent N incidents (default: 10, 0 for all)
serverNoRemote server name from config (optional, runs locally if omitted)
containerNoOnly incidents for this target (optional)
include_logsNoInclude the logs captured before and after each restart (default: false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.41.0
    • changedInput schema / properties / limit / type
      Previous value: -"string"New value: +"integer"
  2. Addedv0.22.0

TDQS

A3.8/5.0
Behavior4/5

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

With readOnlyHint and destructiveHint already declaring a safe read operation, the description adds valuable behavior beyond annotations: results are newest first, and captured logs are excluded by default due to their volume. It does not cover return shape, but the annotation burden is already low.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core action and ordering, followed immediately by the important default exclusion behavior. There is no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only list tool with full parameter documentation and no output schema, the description covers ordering, default log exclusion, and the reason for that default. It could be improved by briefly indicating the incident fields or total-count behavior, but it is otherwise complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all four parameters are already documented. The description adds practical rationale for include_logs specifically, but does not elaborate on limit, server, or container beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb and resource: 'List recorded restart incidents, newest first.' It distinguishes this from general watch management tools by focusing on incident history, but it does not explicitly name its sibling alternatives such as watch_list or watch_check.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives useful conditional guidance for include_logs, explaining that logs are excluded by default because each incident carries a hundred lines of output twice over. However, it does not state when to use this tool versus watch_list, watch_check, or other watch-related siblings.

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