Skip to main content
Glama
Sign In
vmware-knight

vmware-knight

by CyberKnightLabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

cross_vcenter_attention

Read-onlyIdempotent

Aggregate cluster health across every configured vCenter into one ranked list of top issues, tagged by source, with per-target rollup and graceful handling of unreachable targets.

Instructions

[READ] "What needs attention now?" across EVERY configured vCenter — one list.

Runs cluster_health_summary against every configured target and returns one globally ranked top_issues list (worst first, each tagged with its vcenter) plus a per-target rollup — "where do I look first, anywhere in the estate?". Degrades gracefully: an unreachable target is listed under unreachable and the rest still aggregate. Delegates to the vmware-monitor library (read-only). Lead with top_issues, then drill in with vm_investigation_bundle. Point-in-time.

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": "cross_vcenter_attention"
  }
}

Input Schema

NameRequiredDescriptionDefault
top_nNoCap the merged top_issues focus list (default 10).
cluster_filterNoCase-insensitive cluster substring applied to every target.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.12.10

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnlyHint/idempotentHint annotations, the description discloses important runtime behavior: it degrades gracefully when a target is unreachable, lists unreachable targets separately, aggregates remaining results, and is point-in-time. It also names the underlying library and confirms read-only behavior, giving an agent confidence in side-effect safety.

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 dense but well-structured, front-loading the core value proposition and then providing behavior, fallback semantics, and follow-up guidance. Every sentence contributes useful information; there is no filler or repetition of schema content.

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?

Even without an output schema, the description sufficiently describes the return shape: a globally ranked top_issues list tagged by vcenter, a per-target rollup, and an unreachable list. It also covers failure behavior, read-only safety, point-in-time semantics, and a suggested drill-in path, making it complete for a read-only aggregation tool.

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 both parameters (top_n and cluster_filter) are already clearly documented in the schema. The tool description adds context about ranking and aggregation but does not need to repeat parameter details. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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 a specific purpose: aggregate attention-worthy issues across every configured vCenter into one ranked list. It explicitly names the underlying operation (runs cluster_health_summary against every target) and distinguishes itself from single-target tools by emphasizing the cross-vCenter scope.

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

Usage Guidelines4/5

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

The description gives clear context for when to use this tool: as the first estate-wide triage step, and it explicitly suggests following up with vm_investigation_bundle for deeper drill-in. It does not explicitly state when not to use it or compare it directly to cluster_health_summary as an alternative, but the 'across EVERY configured vCenter' scope makes the usage context unambiguous.

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