Skip to main content
Glama
vmware-skills

VMware-Monitor

by vmware-skills
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

host_log_scan

Read-onlyIdempotent

Scan recent ESXi host syslog lines for error/warning patterns, returning grouped findings with severity and sample messages to diagnose host issues when vCenter events are insufficient.

Instructions

[READ] Scan recent ESXi host syslog lines for error/warning patterns.

Reads the last lines entries of the hostd/vmkernel/vpxa logs via the diagnostic system and returns only the lines matching known trouble patterns (error, fail, critical, panic, lost access, timeout, …). Severity follows the level ESXi wrote on the line (Cr/Er/Wa/In…, raw token in log_level); a critical keyword still wins. By default findings are grouped by pattern — each item has count, hosts, first_seen/last_seen (log time), severity, source (host_log:<key>), pattern and one sample; lines_matched is the ungrouped count. group=false returns one row per line (severity, source, message, time, entity, log_level, log_time). Returns the list envelope {items, returned, limit, total, truncated, hint}. total is null on purpose — this is "errors within the scanned window", not all errors ever. logs_unavailable lists every host/log that could NOT be read, with the reason (e.g. the account lacks Global.Diagnostics); empty items means nothing matched only when logs_unavailable is empty too.

Use this when get_events or host_investigation_bundle show a host in trouble but not why: vCenter events and ESXi syslog are different sources. Filter with host_name to keep the scan fast on large clusters; a name that matches no host returns an error (get the exact name from list_esxi_hosts), not an empty result. Every call reads the last lines lines afresh.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
groupNoGroup repeated lines by pattern (default true). One call on a lab returned 353 lines, 195 of them one statistics-provider message.
linesNoHow many recent lines per log to scan (default 500, at least 1).
targetNovCenter/ESXi target from config (default if omitted).
host_nameNoFilter to a single host by exact name (None = all hosts).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.14.0
    • addedInput schema / properties / group
      Added value: +{
+  "default": true,
+  "description": "Group repeated lines by pattern (default true). One call on a lab returned 353 lines, 195 of them one statistics-provider message.",
+  "title": "Group",
+  "type": "boolean"
+}
  2. Changed1 schema field changedv1.11.3
    • changedInput schema / properties / lines / description
      Previous value: -"How many recent lines per log to scan (default 500)."New value: +"How many recent lines per log to scan (default 500, at least 1)."
  3. Changed5 schema fields changedv1.9.2
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / host_name / description
      Added value: +"Filter to a single host by exact name (None = all hosts)."
    • addedInput schema / properties / lines / description
      Added value: +"How many recent lines per log to scan (default 500)."
    • addedInput schema / properties / target / description
      Added value: +"vCenter/ESXi target from config (default if omitted)."
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "items": {
-        "additionalProperties": true,
-        "type": "object"
-      },
-      "title": "Result",
-      "type": "array"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "host_log_scanOutput",
-  "type": "object"
-}New value: +null
  4. Addedv1.6.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark this as read-only, idempotent, and non-destructive, and the description adds substantial behavioral context beyond that: it reads only the last `lines` entries, filters by known trouble patterns, explains severity precedence, documents that `total` is deliberately null, and describes `logs_unavailable` semantics. It also states that every call reads the log afresh, which is useful for an agent planning repeated calls.

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

Conciseness4/5

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

The description is long but tightly packed with necessary operational details, and the [READ] prefix and first sentence front-load the core purpose. Each subsequent paragraph addresses a distinct concern: output shape, grouping behavior, total semantics, and usage guidance, so no sentence feels wasted.

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

Completeness5/5

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

There is no output schema, so the description carries the full burden of explaining return values, and it does so thoroughly: the list envelope, grouped item fields, ungrouped row fields, `total` being null by design, `logs_unavailable`, and the interplay between empty `items` and `logs_unavailable`. It also covers error behavior and intended usage context, making it complete for an agent to select and invoke the tool correctly.

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

Parameters4/5

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

The input schema already documents all four parameters with 100% coverage, so the baseline is 3. The description adds meaningful parameter-level context beyond the schema: `group=false` output shape, the `host_name` exact-match error behavior, and the fact that `lines` controls the freshly read window per call.

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

Purpose5/5

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

The description opens with a precise action: scanning recent ESXi host syslog lines for error/warning patterns, naming the specific logs (hostd/vmkernel/vpxa) and the diagnostic mechanism. It clearly differentiates this tool from related tools by explicitly contrasting it with get_events and host_investigation_bundle, which read different sources.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use guidance: 'Use this when get_events or host_investigation_bundle show a host in trouble but not why.' It also provides practical usage details like filtering with host_name, exact name lookup from list_esxi_hosts, the error behavior for unmatched names, and the effect of group=false.

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

Deploy Server

Other Tools