Skip to main content
Glama

esxi_resource_get

Read-onlyIdempotent

Query hypervisor resource status by domain and declared properties, removing the need to manually build manager IDs.

Instructions

按资源域直接查询状态,无需手工拼管理器 ID;只允许已声明属性。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
depthNo
domainYes
max_itemsNo
propertiesYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

C2.7/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds one genuinely useful rule beyond that: only declared properties are permitted ('只允许已声明属性'). It does not disclose pagination/truncation behavior implied by max_items and depth defaults.

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?

Two short clauses, front-loaded with the core capability (query by domain) before the constraints. No filler, though it is perhaps too terse given the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need no explanation, but with 4 params at 0% schema coverage and no usage guidance, the description does too little for a tool sitting among many similar query/schema siblings. Undefined 'resource domain' and silent depth/max_items leave real gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter meaning. It maps only two of four params loosely ('资源域'→domain, '已声明属性'→properties) and says nothing about depth or max_items, leaving half the interface unexplained in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a verb and abstract resource ('按资源域直接查询状态') but '资源域' is undefined and it does not distinguish itself from conceptual siblings like esxi_resource_schema, esxi_api_get, or esxi_inventory. An agent cannot confidently tell what concrete data this returns versus those tools.

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

Usage Guidelines2/5

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

The phrase '无需手工拼管理器 ID' hints that this is a convenience alternative to manually assembling IDs (e.g., via esxi_api_get), but there is no explicit when-to-use, when-not, or naming of the alternative. No usage context for the required vs optional params is given.

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