io.github.zw008/vmware-log-insight

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.8.9
Disambiguation5/5
Each tool targets a distinct resource and action: alerts have list/get/history, logs have search/aggregate/fields, and version is separate. No overlapping purposes.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (alert_list, alert_get, alert_history, log_fields, log_search, log_aggregate, log_version).
Tool Count5/5
7 tools is well-scoped for a read-only Log Insight client, covering the essential querying and inspection needs without bloat.
Completeness5/5
The read-only surface is complete: alert discovery with detail and history, log field discovery, raw log search, aggregation for spike detection, and version diagnostics. No obvious gaps.
Average 4.9/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 25 commits in the last 12 weeks
- Last stable release on August 1, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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 bar is low for additional transparency. The description still adds value by explicitly stating 'Read-only' and detailing the return structure (bins and spikes with zscore), as well as the aggregation types. It stops short of describing bin alignment or time range inclusivity, but given the annotation coverage, this is thorough.
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 uses clear section labels (WHEN, INPUT, RETURNS) and front-loads the purpose. Every sentence contributes essential information: purpose, usage, parameter semantics, and output shape. There is no redundancy or filler.
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 7 parameters, no output schema, and no schema descriptions, this description covers all aspects: what it does, when to use it, how parameters map to log_search, the aggregation options, and the full return format. It fully equips 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?
Schema description coverage is 0%, so the description carries the burden. It explains aggregation values (COUNT, UCOUNT, etc.) and defaults (bin_width_ms=60000), and clarifies 'text/last/begin_ms/end_ms' share log_search semantics. While it relies on the user knowing log_search for some params, that reference is a reasonable way to reuse existing knowledge and adds meaning beyond bare schema names.
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 '[READ] Aggregate matching events into a time series and detect spikes,' which uses a specific verb ('Aggregate') and resource ('matching events') and clearly distinguishes from sibling tools like log_search (raw events) and log_fields. It immediately conveys the tool's unique role.
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 explicitly states the use case: 'to find when/whether log volume burst without pulling raw events.' It also provides guidance on follow-up with log_search for the spike window, and clarifies that the input semantics match log_search. This is exemplary usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds behavioral context by explaining the purpose: diagnostics and query-syntax compatibility, plus the sequencing guidance regarding log_search. This goes beyond structured fields without contradicting them.
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?
Four short sentences, each delivering distinct value: the operation, the parameter, the usage scenario, and the safety confirmation. It is front-loaded with the core purpose and contains no fluff or repetition beyond the harmless 'Read-only' tag.
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?
Given the tool's simplicity (one optional param, no output schema) and rich annotations, the description fully covers the necessary information: what it returns, the parameter origin, and when to invoke it. The lack of return-format details is acceptable since no output schema exists but the output is self-evident (version/build string).
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 provides no description for the 'target' parameter (0% coverage). The description compensates by explaining 'target = target name from config', clarifying that it comes from configuration. This is minimal but sufficient for a single optional parameter, though it lacks examples or format details.
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?
Description opens with '[READ] Return the Log Insight appliance version/build', clearly stating the action (return) and resource (appliance version/build). It distinguishes itself from siblings by noting its diagnostic role and query-syntax compatibility, which is unique among log_* tools.
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?
Explicit instructions: 'Use this first when a query behaves unexpectedly, to confirm the appliance version before trusting log_search.' This provides a concrete trigger condition and names the sibling tool to validate against, giving clear when-to-use and relational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds beyond annotations by stating the return is 'sanitized detail' and that alert_id comes from alert_list, providing useful behavioral context. No contradiction found.
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 and every sentence serves a purpose: main action, usage context, parameter clarification, and pointer to sibling. The 'Read-only' tag is redundant with annotations but not a significant distraction. No unnecessary elaboration.
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 simple get-by-id tool with no output schema, the description adequately covers what is returned (sanitized detail), how to obtain the id, and where to go for related data (alert_history). It is complete enough for selection and invocation without external resources.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining alert_id as 'the id it returned (from alert_list)' and target as 'target name from config'. Both parameters receive meaningful semantic context beyond the schema's structural titles.
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 clearly states the action: 'Get full details for one alert.' It distinguishes itself from sibling tools by referencing alert_list for listing and alert_history for firings, making the specific scope (single alert detail) unambiguous.
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?
Explicitly says 'Use this after alert_list' for sequencing and 'for its firings use alert_history' to direct to an alternative. This provides clear when-to-use and when-not-to-use guidance with named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description explains the list envelope structure, the meaning of 'total' and 'truncated', and instructs to raise the limit when truncated is true. This adds valuable behavioral context not present in 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 efficiently structured: a bracketed [READ] prefix, a one-line summary, usage guidance, parameter explanations, and return format. Every sentence adds value with no repetition or fluff.
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?
Despite no output schema, the description fully documents the response envelope and item fields, including guidance on interpreting truncated. It covers purpose, parameters, behavior, and output, making it highly complete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter: alert_id (from alert_list), limit (max records, default 50), and target (target name from config). This goes well beyond the raw schema types.
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 clearly states the tool's function: 'List recent trigger-history records for an alert.' It also distinguishes from siblings by clarifying it's for when an alert fired, not how it's defined, and references alert_list as a source for alert_id.
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?
Explicitly tells when to use this tool vs alternatives: 'Use this for when an alert fired, not how it's defined.' Also references alert_list for obtaining the alert_id, providing cross-tool context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent), the description adds substantial behavioral context: it explains the return envelope structure, that total is the real count, and how truncated indicates whether more results exist. It also states the operation is read-only explicitly, reinforcing annotations without contradiction.
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 concise yet dense, with a clear structure: purpose, parameters, return format, workflow, pagination note, and safety disclaimer. Every sentence adds value, and the use of inline code-like formatting for field names improves readability without bloat.
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 full burden of explaining return values—it does so with the envelope format and item structure. It also covers pagination semantics, parameter meanings, and the recommended workflow, making it complete for a list tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining each parameter: name_filter is a case-insensitive substring, limit is max results (default 50), and target is a target name from config. This provides essential meaning that the schema lacks.
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 clearly states 'List defined Log Insight alerts' with a specific verb and resource. It also distinguishes from sibling tools by explicitly saying 'Start here, then pass an id to alert_get or alert_history', positioning itself as the entry point for listing alerts.
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?
Provides explicit workflow guidance: 'Start here' for listing, then use alert_get or alert_history for details. Also gives actionable pagination advice: 'raise limit or narrow name_filter when truncated is true.' This clearly indicates when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description goes far beyond annotations by disclosing the return envelope format, guaranteeing the result is complete ('No limit — every matching field is returned'), and explaining that truncated is always false. This gives the agent clear expectations about pagination and result completeness.
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?
Every sentence serves a distinct purpose: purpose, usage, parameter details, and complete return envelope. The structure is front-loaded with the READ action and purpose, and the description is appropriately sized—detailed but without irrelevant filler.
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?
The tool has no output schema and only two optional parameters, yet the description covers the full return shape, pagination behavior, and completeness guarantee. It provides all necessary context for an agent to use the tool correctly without ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover 0% of parameters, so the description carries the full burden. It defines both 'name_filter' as 'optional case-insensitive substring' and 'target' as 'target name from config', adding meaningful semantics beyond the schema's bare titles and default nulls. This fully compensates for the lack of schema descriptions.
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 '[READ] List the extracted fields available to use in query filters,' which clearly states the verb and resource. It further distinguishes the tool from siblings by explicitly mentioning use before 'log_search / log_aggregate,' aligning with the sibling tool names.
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 provides explicit usage guidance: 'Use this to discover valid field names before filtering log_search / log_aggregate.' This tells exactly when to use the tool and implies it is a prerequisite for other log tools. It also clarifies the optional parameters, giving immediate practical context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses the return shape including a 'complete' flag that indicates truncation, the mutual exclusivity of last vs begin_ms/end_ms, and the limit guidance to narrow with text rather than raising the value. This adds substantial behavioral context not available from annotations alone.
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 well-structured with READ/WHEN/INPUT/RETURNS sections, each sentence delivering necessary information. The content is front-loaded with purpose and usage, with concise parameter explanations and return format. No filler or redundancy.
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?
Given no output schema and six parameters, the description provides complete coverage of inputs, outputs (including truncation flag), constraints (mutual exclusivity), and integration guidance. It also confirms read-only behavior, making it fully self-contained for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully documents all 6 parameters: text as free-text CONTAINS search, last as a relative window with examples and default, begin_ms/end_ms as absolute epoch-ms with mutual exclusivity, limit with range and best-practice advice, and target as a config-provided name. This goes well beyond the bare schema.
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 clearly states 'Search Log Insight events within a time window' with a specific verb and resource. It also distinguishes from siblings by explicitly naming log_aggregate and vmware-monitor for alternative use cases, leaving no ambiguity about this tool's unique purpose.
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 explicitly says to use this tool to find actual log lines behind an incident, and directs to log_aggregate for log bursts and vmware-monitor for vCenter alarms. It also suggests feeding results to vmware-debug incident_timeline, providing clear usage context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![VMware-Log-Insight MCP server](https://glama.ai/mcp/servers/vmware-skills/VMware-Log-Insight/badges/card.svg)](https://glama.ai/mcp/servers/vmware-skills/VMware-Log-Insight)

Score Badge

Copy to your README.md:

[![VMware-Log-Insight MCP server](https://glama.ai/mcp/servers/vmware-skills/VMware-Log-Insight/badges/score.svg)](https://glama.ai/mcp/servers/vmware-skills/VMware-Log-Insight)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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