This server provides read-only access to VMware vCenter inventory and configuration data — it cannot create, modify, delete, clone, power, or move anything.
Available Capabilities
List Virtual Machines (vsphere_list_vms): Retrieve all visible VMs with optional filters by VM IDs, names, folders, datacenters, hosts, clusters, resource pools, and power states (POWERED_ON, POWERED_OFF, SUSPENDED).
Get VM Details (vsphere_get_vm): Fetch detailed information for a single virtual machine by its vSphere VM ID (e.g., vm-42).
Get VM Summary (vsphere_get_vm_summary): Retrieve a VirtualMachine summary property via VI/JSON for a specific VM ID.
Query Managed Object Properties (vsphere_query_properties): Read one allowlisted VI/JSON managed-object property by specifying the object type, object ID, and property path.
List ESXi Hosts (vsphere_list_hosts): Retrieve all visible ESXi hosts.
List Clusters (vsphere_list_clusters): Retrieve all visible vCenter clusters.
List Datastores (vsphere_list_datastores): Retrieve all visible datastores.
List Datacenters (vsphere_list_datacenters): Retrieve all visible datacenters.
List Networks (vsphere_list_networks): Retrieve all visible networks.
All tools are read-only, idempotent, and non-destructive, and results are scoped to what the configured vCenter account has permission to see.
Read-only integration with VMware vCenter, allowing to query information about virtual machines, hosts, clusters, datastores, datacenters, and networks.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Read-Only vSphere MCP Server list all virtual machines in my datacenter"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This project lets Codex read inventory from VMware vCenter. It exposes seven approved MCP tools and cannot create, update, delete, clone, power, or move anything.
You -> Codex -> this MCP server -> vCenter
|
+-> read information onlyCodex asks a question. The MCP server logs in to vCenter, performs an approved
REST request, and returns the answer. The MCP server runs locally through
standard input/output (stdio); it does not open a network port.
Related MCP server: VMware-Monitor
You need:
The HTTPS address of your vCenter Server, such as
https://vcenter.company.com.
A vCenter username.
That user's password.
The built-in Read-only role assigned at the inventory level you need, with propagation enabled.
Network or VPN access from your computer to vCenter.
Python 3.10 or newer, Git, and Codex.
The address alone is not enough. You need a username and password. You do not need a Broadcom developer API key. After login, vCenter returns a temporary session token automatically.
Send this request to your VMware administrator:
Please provide the HTTPS vCenter Server address and a dedicated service account with the built-in Read-only role. Assign it at the required inventory scope with propagation enabled. Please also provide the company CA certificate in PEM format if vCenter uses an internally signed certificate.
This project supports username/password authentication. If your company forces browser-only SSO or MFA, ask for a non-interactive read-only service account.
git clone https://github.com/arjungowdal4601/vcenter_mcp.git
cd vcenter_mcp
python3 --version
python3 -m venv .venv
source .venv/bin/activate
python -m pip install -e .
cp .env.example .env
chmod 600 .envThe version command must show Python 3.10 or newer. If python3 is older, use
the newer executable installed on your computer, such as python3.13, for the
virtual-environment command.
Open .env in a local text editor and replace the example values with your
credentials. Do not paste the password into an AI chat.
git clone https://github.com/arjungowdal4601/vcenter_mcp.git
cd vcenter_mcp
py -3 --version
py -3 -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install -e .
Copy-Item .env.example .envThe version command must show Python 3.10 or newer.
Open .env locally and replace the examples. If PowerShell blocks activation,
you can still use .\.venv\Scripts\python.exe in the remaining commands.
.envMinimum configuration:
VSPHERE_HOST="https://vcenter.company.com"
VSPHERE_USERNAME="codex-readonly@vsphere.local"
VSPHERE_PASSWORD="your-real-password"
VSPHERE_VERIFY_SSL="true"
VSPHERE_TIMEOUT_SECONDS="30"VSPHERE_HOST is the address used to open vCenter Server. Do not use an ESXi
host address, the Broadcom documentation website, or an address ending in an
API path such as /api or /sdk.
VSPHERE_USERNAME is the read-only vCenter account. Depending on your company,
it may look like user@vsphere.local, DOMAIN\\user, or an email address.
VSPHERE_PASSWORD is that account's password. .env is ignored by Git and
must never be committed.
VSPHERE_VERIFY_SSL should remain true. Turning verification off makes it
possible to send credentials to an impostor server.
If your company uses a private certificate authority, add the absolute path to its PEM bundle:
VSPHERE_CA_BUNDLE="/Users/you/certificates/company-ca.pem"On Windows, use a quoted absolute path:
VSPHERE_CA_BUNDLE="C:\\Certificates\\company-ca.pem"Process environment variables override values in .env.
Run the command from the repository directory after filling .env.
macOS or Linux:
codex mcp add vsphere -- "$(pwd)/.venv/bin/python" -m vsphere_mcp --env-file "$(pwd)/.env"Windows PowerShell:
$root = (Get-Location).Path
codex mcp add vsphere -- "$root\.venv\Scripts\python.exe" -m vsphere_mcp --env-file "$root\.env"The Codex registration stores only the Python command and .env path. It does
not store the vCenter username or password.
Check the registration:
codex mcp get vsphereRestart Codex after registering the server. Then ask:
Use the vSphere tools to list my virtual machines.To replace an old registration:
codex mcp remove vsphereThen run the appropriate codex mcp add command again.
Other MCP-compatible coding agents can run the same executable and arguments
as a local stdio server. Their configuration format is agent-specific.
Tool | What it reads | REST endpoint |
| Visible virtual machines |
|
| Details for one VM ID |
|
| ESXi hosts |
|
| Clusters |
|
| Datastores |
|
| Datacenters |
|
| Networks |
|
vsphere_list_vms can filter by VM IDs, names, folders, datacenters, hosts,
clusters, resource pools, and power states. Allowed power states are
POWERED_ON, POWERED_OFF, and SUSPENDED.
Example prompts:
Use vSphere to list all VMs.
Show only powered-on VMs named web-server.
Get details for VM vm-42.
List my ESXi hosts and clusters.
List all datastores and datacenters visible to this account.
List the available vCenter networks.The returned inventory depends on the account's vCenter permissions. An empty list can mean the login worked but the Read-only role was assigned at the wrong inventory scope.
The MCP server performs this flow internally:
It sends the username and password to POST /api/session using HTTPS Basic
authentication.
vCenter returns a temporary session token.
The server sends that token in the vmware-api-session-id header for REST
reads.
If the token expires and vCenter returns HTTP 401, the server logs in once more and retries the read once.
The password is not an API key. The temporary session token is not something you obtain manually.
Only explicit read tools are registered with MCP.
Every tool is marked read-only, non-destructive, and idempotent.
There is no generic call_api tool.
vCenter addresses must use HTTPS.
Redirects are not followed, preventing credentials from being forwarded to another host.
IDs and filters are validated before requests are sent.
Passwords are excluded from configuration representations and errors.
Real enforcement also comes from the vCenter account's Read-only role.
For stronger protection, create a dedicated service account instead of using a personal administrator account.
vCenter rejected the username, password, or expired session. Confirm the
credentials by signing in to the same VSPHERE_HOST. Browser-only MFA accounts
will not work.
The login worked, but the account lacks permission. Ask the administrator to assign the Read-only role at the correct inventory scope with propagation.
Ask the administrator for the company CA certificate in PEM format and set
VSPHERE_CA_BUNDLE. Do not solve production certificate errors by disabling
verification.
Confirm the address, DNS, VPN, firewall, and port 443 access from your computer.
Run codex mcp get vsphere, confirm the displayed Python and .env paths still
exist, and restart Codex. Absolute paths break if the repository is moved;
remove and add the registration again after moving it.
The account may have the Read-only role at the wrong scope. vCenter only returns objects visible to that account.
Share the GitHub repository, not your .env file. Each user should clone the
project, create their own .env, and register their local copy with Codex.
Never send vCenter passwords through Git, email, chat, screenshots, or tickets.
This version intentionally supports only local stdio. It does not provide a
central HTTP MCP service.
Install development dependencies and run the tests:
python -m pip install -e '.[dev]'
python -m pytestShow the command-line help:
python -m vsphere_mcp --helpThe automated tests use mocked vCenter responses. A real integration test requires a non-production vCenter address and read-only credentials.
Get read-only details for one virtual machine by vSphere VM id, for example vm-42.
| Name | Required | Description | Default |
|---|---|---|---|
| vm | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description merely restates 'read-only' without adding behavioral context like authorization needs or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no unnecessary words. It efficiently conveys the tool's purpose and input requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, rich annotations, and an output schema, the description is complete. It specifies the input format and the nature of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by explaining the 'vm' parameter is a vSphere VM id and provides a concrete example 'vm-42'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'read-only details for one virtual machine', and the identifier 'by vSphere VM id' with example. It distinguishes from sibling tools like vsphere_list_vms and vsphere_get_vm_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving full details of a single VM, but does not explicitly state when not to use or compare with siblings. The example and context from sibling names provide implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a VirtualMachine summary property through VI/JSON by VM id, for example vm-42.
| Name | Required | Description | Default |
|---|---|---|---|
| vm | Yes | ||
| release | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds minimal context ('summary property') without detailing what the summary includes or any side effects. Since annotations cover the safety profile, a moderate score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource. It avoids waste but omits necessary detail on parameters and usage context. Efficiency is good, but completeness sacrifices some structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values are not required. However, the description fails to explain when to use this tool over similar ones (e.g., vsphere_get_vm) and does not describe the 'release' parameter or its default behavior. For correct invocation and selection, the description is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains 'vm' via example (vm-42) but does not clarify its format beyond that. The 'release' parameter is completely unmentioned, leaving its purpose and acceptable values ambiguous. The example only partially helps for one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get), resource (VirtualMachine summary property), and mechanism (through VI/JSON by VM id) with an example. However, it does not explicitly differentiate from vsphere_get_vm, which may retrieve the full VM object, thus missing sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like vsphere_get_vm or vsphere_query_properties. The example implies a specific VM ID format but does not exclude use cases or mention prerequisites. Agents have no basis for choosing this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List visible vCenter clusters using the vSphere Automation REST API.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds minimal value by mentioning the API source, but no details on side effects, auth requirements, or output format beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of ten words, front-loaded with the verb and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers the subject and scope adequately for a parameterless tool with annotations. Missing mentions of error handling or authentication, but largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. The description does not need to add parameter meaning, and baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists visible vCenter clusters, using a specific verb ('list') and resource. It distinguishes from sibling tools that list other entities like datacenters or VMs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description lacks context such as prerequisites, alternative tools, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List visible datacenters using the vSphere Automation REST API.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description does not add any behavioral traits beyond stating it lists visible datacenters, so it adds minimal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose. Every word is necessary and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, good annotations, and an output schema (which renders return value explanation unnecessary), the description is adequate. It could briefly mention the output format but is not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema description coverage is 100%. The description does not need to add parameter info. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and the resource (datacenters), and specifies the API used. It is distinct from sibling tools like vsphere_list_clusters and vsphere_list_vms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. The context is implied by the name, but explicit when/when-not statements are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List visible datastores using the vSphere Automation REST API.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, openWorldHint, idempotentHint as true and destructiveHint as false, fully covering the safety profile. The description only adds the API identification ('using the vSphere Automation REST API'), which is technical but adds no new behavioral traits (e.g., rate limits, auth needs) beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and resource. It is concise with no wasted words, appropriate for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no input parameters, rich annotations, and an output schema that likely describes return values), the description is sufficient. It captures the core purpose and API used, though it could briefly note that it returns all visible datastores without pagination details, but the output schema may cover that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema description coverage is 100% (trivially). The description does not need to add parameter information. As per guidelines, 0 parameters warrants a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('datastores'), and the context of siblings (e.g., vsphere_list_vms, vsphere_list_clusters) makes it distinct from other listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like vsphere_list_datacenters or vsphere_get_vm. There is no mention of preconditions, exclusions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List visible ESXi hosts using the vSphere Automation REST API.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, indicating a safe read operation. The description adds the word 'visible,' implying some filtering based on permissions, but overall adds minimal behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It efficiently conveys the tool's function without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema is assumed to document return values, the description is sufficiently complete for a simple list operation. It provides all necessary context for an agent to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100% trivially. The description does not need to add parameter details, meeting the baseline of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists visible ESXi hosts, which is specific and unambiguous. The resource (ESXi hosts) and verb (list) are explicitly defined, making it easy for an agent to understand the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like vsphere_get_vm or vsphere_list_clusters. The description merely states the action without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List visible networks using the vSphere Automation REST API.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only adds 'using the vSphere Automation REST API', which is implementation detail and not behavioral. Annotations already fully disclose readOnlyHint, idempotentHint, and destructiveHint. No additional behavioral traits (e.g., permission requirements, pagination, or scope of 'visible') are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that conveys the essential purpose without any unnecessary words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and a provided output schema (indicated by context), the description covers the core function. However, it lacks detail on what 'visible' means or how the network list is returned, which could be clarified given the complexity of vSphere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no need for parameter description. According to the guidelines, baseline is 4 for no parameters. The description does not add any parameter info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'visible networks', directly corresponding to the tool name. It unambiguously identifies the tool's function, distinguishing it from sibling tools like vsphere_list_vms or vsphere_list_hosts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, context for use, or when not to use it. The usage context is only implied by the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List visible virtual machines using the vSphere Automation REST API.
| Name | Required | Description | Default |
|---|---|---|---|
| vms | No | ||
| hosts | No | ||
| names | No | ||
| folders | No | ||
| clusters | No | ||
| datacenters | No | ||
| power_states | No | ||
| resource_pools | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. Description adds no extra behavioral context beyond annotations, so minimal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, very concise. However, it omits critical parameter information, so it's not optimally structured despite brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 optional parameters and an output schema, the description fails to explain filtering capabilities or output details. Incomplete for a parameter-rich tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the 8 optional filter parameters (vms, hosts, names, etc.). The agent must guess their purpose from names alone, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List visible virtual machines' with a specific verb and resource. Distinguishes itself from sibling tools like vsphere_get_vm and other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like vsphere_get_vm or when filtering is needed. Missing any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one allowlisted VI/JSON managed-object property. Inputs are mo_type, mo_id, property_path, and optional release.
| Name | Required | Description | Default |
|---|---|---|---|
| mo_id | Yes | ||
| mo_type | Yes | ||
| release | No | ||
| property_path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true, so the description's 'Read' is consistent but adds little. It mentions 'allowlisted' as a constraint, which is useful, but no further info on behavior (e.g., error handling, rate limits). With good annotations, the description adds marginal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with front-loaded purpose and parameter list. No wasted words, but could be more structured. Appropriate length given simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists but description doesn't explain return format. 'Allowlisted' is vague—agent may not know which properties are allowed. No mention of error cases or how to handle missing properties. Adequate for a read-only tool with annotations, but incomplete for full agent autonomy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It merely lists parameter names (mo_type, mo_id, property_path, release) without defining them or providing valid values. No explanation of what each parameter means or how they are used, e.g., mo_type as managed object type. Insufficient for an agent to correctly set parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Read one allowlisted VI/JSON managed-object property', defining verb (read), resource (property), and constraint (allowlisted). It distinguishes from sibling tools like vsphere_get_vm (which retrieves full VM) and list tools by specifying a single property query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The description implies usage for reading a single property, but does not state when not to use it (e.g., if multiple properties needed, use vsphere_get_vm). Lacks exclusions or preferences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0vsphere_get_vmvsphere_get_vm_summaryvsphere_list_clustersvsphere_list_datacentersvsphere_list_datastoresvsphere_list_hostsvsphere_list_networksvsphere_list_vmsvsphere_query_propertiesScored across 9 tools
Tools are mostly distinct with clear purposes. The slight overlap between vsphere_get_vm and vsphere_get_vm_summary could cause confusion, but descriptions differentiate them (full VM details vs. summary property). All other tools target unique resource types.
All tools start with 'vsphere_' and follow a verb_noun pattern. Verbs are consistently 'list' for enumeration and 'get' for single resources, except 'query_properties' which uses 'query' instead of 'get', introducing minor inconsistency.
9 tools cover the core read-only operations for vSphere (listing main resources and retrieving VM details). The count is well-scoped for the server's purpose, not excessive or sparse.
The set covers listing for most resources and VM detail retrieval, but lacks ways to get detailed properties for clusters, datastores, or hosts beyond listing. The generic 'query_properties' tool may partially fill gaps but is limited to allowlisted properties and requires specific input.
Agent knowledge, private memory and coordination. Connect with MCP OAuth or an agent key.
MCP-first control plane for ProAgentStore agents and private instances.
One connector for 15,000+ MCP servers plus your team's private MCPs, from any AI client.
Agent-native cloud, EU-hosted. Provision VMs, networks & databases on redu.cloud via MCP.
