Skip to main content
Glama
vmware-skills

io.github.zw008/vmware-log-insight

log_search

Read-onlyIdempotent

Retrieve raw log events from VMware Log Insight for a specified time window, filterable by message text, to investigate incidents.

Instructions

[READ] Search Log Insight events within a time window.

WHEN: to find the actual log lines behind an incident (e.g. what vmkernel logged during a storage event). For "where did logs burst?" use log_aggregate instead; for vCenter alarms use vmware-monitor.

RETURNS: {count, complete (False if truncated), constraints, events: [{timestamp_ms, text, fields}]}. Feed events to vmware-debug incident_timeline to correlate across sources. Read-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
lastNoRelative window ending now, as a quantity plus a unit suffix — s, m, h or d ("30m", "2h", "7d") — or a bare number of seconds. Anything else raises a ValueError naming the accepted forms. Cannot be combined with begin_ms/end_ms; passing both is refused. Omit all three and the query defaults to the last hour, so it is never unbounded.
textNoFree-text substring matched against the event message with the CONTAINS operator — not a regex and not a full query expression. Omit to match every event in the window. To filter on an extracted field instead, discover names with log_fields; this tool exposes no field-filter parameter.
limitNoMaximum events returned, 1..20000, default 50. Out-of-range values are silently clamped into that range rather than refused. Narrow the window or the text rather than raising this — raw events are the largest thing this skill can put in context.
end_msNoAbsolute window end as epoch milliseconds (not seconds). May be given without begin_ms, which then means "everything up to this instant". Cannot be combined with last.
targetNoLog Insight target name as spelled in ~/.vmware-log-insight/config.yaml. Omit to use that file's default_target — with no default configured, omitting it is an error that lists the configured names.
begin_msNoAbsolute window start as epoch milliseconds (not seconds). May be given without end_ms, which then means "from this instant onwards". Cannot be combined with last.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed7 schema fields changedv1.8.14
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / begin_ms / description
      Added value: +"Absolute window start as epoch milliseconds (not seconds). May be given without end_ms, which then means \"from this instant onwards\". Cannot be combined with last."
    • addedInput schema / properties / end_ms / description
      Added value: +"Absolute window end as epoch milliseconds (not seconds). May be given without begin_ms, which then means \"everything up to this instant\". Cannot be combined with last."
    • addedInput schema / properties / last / description
      Added value: +"Relative window ending now, as a quantity plus a unit suffix — s, m, h or d (\"30m\", \"2h\", \"7d\") — or a bare number of seconds. Anything else raises a ValueError naming the accepted forms. Cannot be combined with begin_ms/end_ms; passing both is refused. Omit all three and the query defaults to the last hour, so it is never unbounded."
    • addedInput schema / properties / limit / description
      Added value: +"Maximum events returned, 1..20000, default 50. Out-of-range values are silently clamped into that range rather than refused. Narrow the window or the text rather than raising this — raw events are the largest thing this skill can put in context."
    • addedInput schema / properties / target / description
      Added value: +"Log Insight target name as spelled in ~/.vmware-log-insight/config.yaml. Omit to use that file's default_target — with no default configured, omitting it is an error that lists the configured names."
    • addedInput schema / properties / text / description
      Added value: +"Free-text substring matched against the event message with the CONTAINS operator — not a regex and not a full query expression. Omit to match every event in the window. To filter on an extracted field instead, discover names with log_fields; this tool exposes no field-filter parameter."
  2. First observedv1.8.9

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing the return contract, including that complete can be False if truncated, and enumerating event fields. This gives the agent useful behavioral expectations beyond the annotations.

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?

The description is compact, front-loaded with the core action, then organized into WHEN and RETURNS sections. Every sentence contributes: purpose, usage guidance, output contract, and read-only confirmation. No filler or redundant restating of the tool name.

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?

For a tool with 6 optional parameters, no output schema, and multiple siblings, the description is complete: it explains what the tool does, when to prefer alternatives, what the response contains, and how the output should be chained downstream. The input schema covers parameter details, and annotations cover safety, so nothing critical is missing.

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%, and every parameter already has rich documentation covering formats, defaults, constraints, and error behavior. The description itself adds little parameter-level meaning, which is acceptable under the baseline rule, but it does not need to compensate because the schema carries the weight.

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 specific verb and resource: 'Search Log Insight events within a time window.' It also differentiates itself from log_aggregate by stating the search is for actual log lines behind an incident, and from vmware-monitor by scope. This makes the tool's purpose unmistakable.

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 WHEN section gives explicit conditions for use and names two alternatives: log_aggregate for 'where did logs burst?' and vmware-monitor for vCenter alarms. It also tells the agent to feed returned events into vmware-debug incident_timeline for correlation, leaving no ambiguity about when this tool is the right choice.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/vmware-skills/VMware-Log-Insight'

If you have feedback or need assistance with the MCP directory API, please join our Discord server