Skip to main content
Glama
vmware-skills

io.github.zw008/vmware-log-insight

by vmware-skills
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

list_log_fields

Read-onlyIdempotent

List available log fields and types on a target to pick valid names for aggregate_logs or decode search_logs event fields.

Instructions

[READ] List the fields this appliance knows (static and extracted).

Use this to pick a 'field' for aggregate_logs, or to learn what a key in a search_logs event's 'fields' means. Returns the family list envelope {items, returned, limit, total, truncated, hint}; each item is {name, internal_name, type}; a content-pack field adds 'display_name' and 'content_pack', and its 'name' is qualified ("com.vmware.vsphere:"); 'unresolved': true (with a 'note') means its pack's namespace is unknown, so that name will match nothing. 'name' is what aggregate_logs takes; 'type' (STRING, NUMBER, ...) says which functions apply. No limit — every matching field is returned. An 8.18.7 appliance with the default content packs has ~340 fields (~15k tokens unfiltered), so pass name_filter. Read-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
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.
name_filterNoCase-insensitive substring matched against 'name' — for a content-pack field the qualified name, so "vsphere" matches every vSphere-pack field. Omit to return every field this appliance extracts. Field extraction is deployment-specific, so a name absent here does not exist for this target no matter what it is called elsewhere.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.4.1

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses the exact return envelope shape, item structure, the content-pack qualification rule, the 'unresolved' failure mode, and the cardinality cost (~340 fields, ~15k tokens) with the mitigation (pass name_filter). This is unusually rich behavioral context.

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?

Dense but front-loaded: the purpose sentence comes first, then usage, then return shape and caveats. Nearly every sentence earns its place, though the return-envelope detail is somewhat lengthy given no output schema exists.

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?

With no output schema, the description carries the return-format burden and does so fully (envelope fields, item fields, edge cases). For a 2-param read tool with rich annotations, nothing an agent needs to call it correctly is missing.

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?

Schema coverage is 100%, so a 3 is the baseline; the description adds real value by explaining that name_filter matches the qualified content-pack name and that omission returns everything, plus the practical warning to use it. It adds meaning beyond the schema text.

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?

Opens with a specific verb+resource ('[READ] List the fields this appliance knows') and immediately scopes it as static and extracted. It clearly distinguishes itself from siblings by naming what it feeds (aggregate_logs) and what it explains (search_logs 'fields').

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?

States two concrete use cases: picking a 'field' value for aggregate_logs, and interpreting a key in a search_logs event's 'fields'. Names the sibling tools explicitly so the agent can route without opening schemas.

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