Skip to main content
Glama
vmware-skills

vmware-aria

by vmware-skills
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

promql_query

Read-onlyIdempotent

Run real-time PromQL instant queries against VMware Aria Operations to retrieve current metrics within seconds, complementing historical data with near-real-time values for monitoring and troubleshooting.

Instructions

[READ] Run a real-time PromQL instant query (VCF Operations 9.1 VODAP service).

Use this for near-real-time (~2s) metrics via a Prometheus-compatible instant query, complementing the historical rollups from get_resource_metrics. Requires the real-time metrics (VODAP) integration to be registered; if it is not, the tool returns an actionable error. Returns result series (labels, timestamp, value) in the paginated envelope plus result_type/status. Gotcha: the query reaches a sibling service whose base path (/data-query-service) is INFERRED — every result carries base_path_confirmed=False until confirmed against a live appliance.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
timeNoOptional evaluation timestamp (RFC3339 or Unix seconds).
limitNoMax result series to return (default 50; None returns all).
queryYesPromQL expression (required), e.g. "cpu_usage_average{}".
targetNoAria/VCF Operations target name from config; default when omitted.
source_idNoOptional data-source id to scope the query.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.10.0
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / limit / description
      Added value: +"Max result series to return (default 50; None returns all)."
    • addedInput schema / properties / query / description
      Added value: +"PromQL expression (required), e.g. \"cpu_usage_average{}\"."
    • addedInput schema / properties / source_id / description
      Added value: +"Optional data-source id to scope the query."
    • addedInput schema / properties / target / description
      Added value: +"Aria/VCF Operations target name from config; default when omitted."
    • addedInput schema / properties / time / description
      Added value: +"Optional evaluation timestamp (RFC3339 or Unix seconds)."
  2. Addedv1.8.10

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses a real-time latency profile, a hard prerequisite (VODAP integration) with the resulting actionable error, and the return envelope contents. It also surfaces a non-obvious gotcha: the sibling service base path is inferred and every result carries base_path_confirmed=False until validated. This is substantial 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.

Conciseness5/5

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

The description is compact yet information-dense, with each sentence contributing a distinct fact: purpose, use case, prerequisite, return format, and a critical gotcha. The '[READ]' prefix and front-loaded purpose statement make the tool's intent immediately clear.

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 read-only query tool with full schema coverage and no output schema, the description covers the essential operational context: when to use it, what it returns, the required integration, error behavior, and a latency caveat. An agent has enough information to select and invoke it correctly under normal conditions.

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%, so the input schema and its per-property descriptions already document all five parameters thoroughly. The description adds high-level context about the query and return shape, but does not need to repeat parameter syntax; baseline 3 is appropriate.

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 opening line, '[READ] Run a real-time PromQL instant query', states a specific verb, resource, and temporal characteristic. It also names the underlying VODAP service, separating it clearly from the historical-rollup tool get_resource_metrics among the siblings.

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 explicitly says to use this for near-real-time (~2s) metrics and references get_resource_metrics as the complementary historical alternative, giving clear context for tool selection. It does not spell out an explicit 'do not use when...' condition, though the complementing-rollups phrase implies the boundary.

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