vmware-vks

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: compatibility checks, supervisor status, storage policies, namespace CRUD, VM classes, TKC cluster lifecycle, kubeconfigs, and storage usage. The few potentially related tools (e.g., get_supervisor_kubeconfig vs. get_tkc_kubeconfig) are clearly separated by their target resource and described as alternatives. There is no ambiguity about which tool to select.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern: check_, get_, list_, create_, update_, delete_, scale_, upgrade_. Resources are consistently named (namespace, tkc_cluster, supervisor_kubeconfig, etc.). The mix of get_ vs list_ is principled and matches the standard singular/plural distinction.
Tool Count4/5
20 tools is slightly above the 3–15 sweet spot, but the scope is broad: vSphere with Tanzu manages supervisors, namespaces, TKC clusters, storage, and kubeconfigs. Each tool exists to support a distinct operation and there is no duplication or filler. The count is reasonable for the feature surface.
Completeness5/5
The full lifecycle is covered for both namespaces (create/read/update/delete) and TKC clusters (create/read/scale/upgrade/delete). Supporting operations such as compatibility checks, supervisor health, storage policy listing, PVC usage, and kubeconfig retrieval are present. No obvious dead ends or missing operations prevent an agent from accomplishing common workflows.
Average 4.9/5 across 20 of 20 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 49 commits in the last 12 weeks
- Last stable release on August 6, 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 indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by detailing the return format (newest first), that it returns an empty list with error/hint if API unavailable, and the parameter roles. No contradiction with 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 very concise: two paragraphs plus parameter docs, no fluff. It front-loads the purpose with [READ] and a clear sentence, then provides essential details in a structured manner.
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 adequately explains the return format ({versions: [...]}) and edge case (empty list with error). It covers the key behavioral aspects (ordering, error handling) and provides sufficient context for an agent to use the tool effectively.
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 coverage is 0%, so the description bears full responsibility for explaining parameters. It describes 'namespace' as the vSphere Namespace for the Supervisor K8s API and 'target' as the vCenter (omit for default), adding meaningful context beyond the raw 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 it lists Kubernetes versions (TanzuKubernetesReleases) available on the Supervisor, using the verb 'list' and resource. It distinguishes itself from sibling tools like create_tkc_cluster and upgrade_tkc_cluster by explicitly noting it should be called before them to pick a valid version.
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 'Call this before create_tkc_cluster or upgrade_tkc_cluster to pick a valid k8s_version,' providing clear guidance on when to use it. It also describes behavior when the API is unavailable, but does not explicitly state when not to use it or mention alternatives.
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?
Beyond the annotations (readOnlyHint, idempotentHint), the description discloses the return envelope structure, status value meanings, and pagination behavior ('one call returns them all, so truncated is always false'). This is useful behavioral context that annotations alone do not convey.
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?
The description is well-organized: purpose, return semantics, usage guidance, and parameter note. Each sentence adds value, and the [READ] tag front-loads the safety profile, though it is slightly longer than strictly necessary.
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 compensates by detailing the list envelope and status semantics, covers the single parameter, and provides navigation guidance. It fully equips the agent to use the tool correctly and safely.
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?
The only parameter, target, is explained as 'vCenter in config.yaml; omit for the default', adding meaning absent from the schema, which has no descriptions for properties. This compensates for the 0% schema description coverage.
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 all vSphere Namespaces on the target vCenter with their status', a specific verb+resource+scope. It further distinguishes itself from siblings by directing to get_namespace for detail, list_tkc_clusters for what runs inside, and update/delete_namespace for modifications.
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?
It explicitly positions the tool as the entry point: 'Start here' and names alternatives for next steps, making the usage context unmistakable. This clearly answers when to use this tool versus siblings.
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 indicate this is a write operation (readOnlyHint=false). The description adds important behavior: dry-run is default (dry_run=True), and the return shape differs between dry-run and actual creation. This goes beyond annotations to explain expected 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a clear header, return behavior, usage guidance, and parameter list. Though somewhat long, every sentence earns its place; the parameter list is justified given the lack of schema descriptions.
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?
Comprehensive for a create tool: explains return values, dry-run behavior, where to get prerequisites, and follow-up confirmation. Even with 8 parameters and no output schema, the agent has enough context to invoke the tool safely and 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 coverage, the description fully compensates by documenting all 8 parameters with meaningful details: units (MHz, MiB), sources (MoRef from check_vks_compatibility), defaults (dry_run=True), and omission semantics ('Omit for no limit'). This adds significant value over 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?
Clearly states 'Create a vSphere Namespace on a Supervisor Cluster' with a specific verb and resource. Distinguishes from siblings by explicitly mentioning update_namespace for existing namespaces and get_namespace for confirmation.
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 when to use which alternative: 'Use update_namespace instead when it already exists; confirm with get_namespace afterwards.' Also references prerequisite tools for parameter values (check_vks_compatibility, list_supervisor_storage_policies), providing clear usage context.
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 indicate read-only, open-world, idempotent, and non-destructive behavior. The description adds specifics about return fields (status/storage may be null) and error handling (returns error/hint if Harbor not enabled).
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 front-loaded with the READ tag and purpose, then details return structure and usage. Every sentence is informative without 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 the low complexity (one optional param, no output schema), the description covers return format, edge cases (null values, error on not enabled), and links to a related tool. Complete.
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?
Despite 0% schema coverage, the description fully explains the single optional parameter 'target': it is the vCenter in config.yaml, and omitting it uses the default. This adds clear meaning beyond the 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 explicitly states the tool gets the status of the Harbor container registry and distinguishes it from siblings like check_vks_compatibility, which checks Supervisor health.
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?
It tells when to use the tool (check registry health, find push URL) and when not to (doesn't list repos/images). It also suggests running check_vks_compatibility first if Supervisor may be down.
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 indicate read-only, idempotent, non-destructive behavior. The description adds that 'one call returns them all' making truncated always false, and describes the return envelope structure, providing useful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence is purposeful: READ tag, purpose, return details, usage guide, and parameter explanation. It's front-loaded and concise with no wasted words.
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 list tool with one parameter and comprehensive annotations, the description covers return format, pagination, usage context, and parameter details. No additional information is needed.
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?
With 0% schema coverage, the description compensates by explaining the 'target' parameter as 'vCenter in config.yaml; omit for the default,' adding 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 vCenter storage policies assignable to Supervisor Namespaces' with a specific verb (list) and resource (storage policies). It distinguishes from sibling tool list_namespace_storage_usage by noting it is for PVC-level usage.
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 to call this before create_namespace or update_namespace to obtain a storage_policy ID, and directs to list_namespace_storage_usage for PVC-level usage, providing clear when-to and when-not-to guidance.
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 read-only, open-world, idempotent, non-destructive. Description adds valuable context: vSphere version requirement, specific return fields, and behavior caveat about CONFIGURING clusters. No contradiction.
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?
Well-structured with [READ] tag, clear paragraphs, and args section. Some redundancy (e.g., return fields listed twice), but overall efficient and front-loaded with key purpose.
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 details return fields and their subfields, plus usage context. For a single optional parameter tool, this is complete and actionable.
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?
With 0% schema description coverage, the description compensates by explaining the target parameter refers to a vCenter in config.yaml and default behavior. This adds meaning beyond the schema's minimal 'anyOf string|null'.
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?
Clearly states it checks vCenter support for VKS, with version requirement. Explicitly ties returned data to sibling tools (get_supervisor_status, create_namespace), differentiating its role as a starting point.
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 guidance: 'Start here' for downstream tools, explains target parameter usage, and warns that clusters may still be CONFIGURING despite vCenter support.
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 indicate a write operation (readOnlyHint=false), and the description adds behavioral context: dry-run mode, background provisioning, and return values. It complements 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear header and bullet-like argument list. It is front-loaded with purpose. While slightly verbose, each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, no output schema), the description covers the process, prerequisites, and return behavior. It lacks output schema details and error handling, but is adequate for the context.
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 provides practical examples for each parameter (e.g., k8s_version: 'v1.28.4+vmware.1', vm_class: 'best-effort-large'). It explains dry_run and target, adding meaning 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 the verb 'Create' and the resource 'TanzuKubernetesCluster in a vSphere Namespace'. It distinguishes itself from sibling tools like scale_tkc_cluster and upgrade_tkc_cluster by specifying the creation action.
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 when-to-use guidance: it explains the dry-run behavior, the need to poll get_tkc_cluster, and prerequisites such as calling get_tkc_available_versions and list_vm_classes first. It also notes that namespace must exist.
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. Description adds that the returned kubeconfig carries a short-lived session token and advises against logging/sharing. Adds value 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with [READ] prefix, clear main description, differentiation, security note, and Args list. Every sentence adds value; no waste.
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, description explains return format (YAML string). Covers usage guidance, security, parameter details, and alternatives. Complete for a 2-param read 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?
Schema coverage is 0%, but description fully explains both parameters: namespace is 'vSphere Namespace to set as context', target is 'vCenter in config.yaml; omit for default'. Adds meaning beyond 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?
Clearly states it retrieves a kubeconfig for the Supervisor K8s API endpoint. Specifies output format (YAML with namespace and kubeconfig). Explicitly distinguishes from sibling get_tkc_kubeconfig.
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 guidance on when to use this tool ('Supervisor-level access') vs sibling ('workloads inside a TKC cluster'). Includes security best practice about treating the token as a credential.
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 valuable context beyond that: it specifies the return shape (one object, not the list envelope), lists the exact fields returned, and explains that it serves as a polling tool for async mutations. It does not contradict annotations, though it could go further (e.g., error conditions), but it scores high given the annotation coverage.
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: a [READ] tag, a clear one-line purpose, a list of return fields, usage guidance, and a separated Args section. Every sentence provides useful information with no fluff. It is front-loaded with the main purpose and maintains readability.
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 has no output schema, the description compensates by listing the exact fields. It covers the prerequisite (run list first), the polling use case, and parameter meanings. It is complete for a read-only status tool and fits well within the sibling set by clearly differentiating from listing and mutation tools. No critical information is missing.
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%, so the description carries the full burden. It provides meaningful descriptions for all three parameters: name ('Cluster name via list_tkc_clusters'), namespace ('Namespace holding it'), and target ('vCenter in config.yaml; omit for the default'). This goes well beyond the bare schema and clarifies usage nuances like namespace-scoped uniqueness.
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 'Get detailed status for a single TKC cluster' — a specific verb and resource, and immediately distinguishes itself from list_tkc_clusters by noting 'Returns one object, not the list envelope.' This clearly separates it from sibling tools like list_tkc_clusters and the mutation 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?
The description gives explicit when-to-use guidance: 'Run list_tkc_clusters first' because a TKC name is only unique within a namespace, and 'Poll this after create_tkc_cluster, scale_tkc_cluster or upgrade_tkc_cluster to watch an async change land.' This provides clear prerequisites and typical usage context, effectively guiding the agent toward correct invocation.
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 indicate read-only and idempotent. Description adds crucial context about a short-lived session token and the risk of inline return, plus the different return formats. No contradiction with 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?
Description is well-structured with a brief intro, return format, security note, and a parameter list. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisites, return formats, and security. Lacks mention of error cases or what happens if the cluster does not exist, but overall complete for a simple get 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?
Input schema has 0% description coverage, but the description provides clear, concise explanations for all four parameters, including examples for output_path and default behavior for target.
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 clearly states the tool gets a kubeconfig for one TKC cluster, using a specific verb and resource. It distinguishes from sibling 'get_supervisor_kubeconfig' by specifying when to use that alternative.
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 user to run list_tkc_clusters first for name/namespace, and advises using get_supervisor_kubeconfig for supervisor-level access. Also recommends preferring output_path for security.
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?
Describes return envelope structure, mentions that every PVC comes back in one call and truncated is always false. Adds context beyond annotations (readOnlyHint, etc.) 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, front-loaded with purpose. Slightly verbose with deprecated alias details but all information is useful.
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?
Covers prerequisite, alternative tool, return envelope, parameter docs, and deprecated aliases. No output schema, but description provides thorough coverage.
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?
Description provides explicit Arg definitions for namespace and target, adding meaning beyond the input schema which only has titles and types. Schema coverage is 0%, but description compensates fully.
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?
Explicitly states it lists PersistentVolumeClaims and storage usage inside a vSphere Namespace via the Supervisor K8s API. Distinguishes from sibling list_supervisor_storage_policies by specifying policy-level vs PVC-level information.
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?
Clearly instructs to run list_namespaces first for the namespace and recommends list_supervisor_storage_policies for policy-level needs. Also explains deprecated aliases and that truncated is always false.
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?
Adds detail beyond annotations: describes async nature, immediate return, polling recommendation, and that only workers are scaled. Confirms non-destructive intent but warns about draining nodes, aligning with destructiveHint=false.
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?
Well-structured with header, async note, and args list. Slightly verbose but each sentence contributes value. Could compress the args list into a table or shorter form, but remains clear and easy to parse.
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?
Complete for a 5-param tool with no output schema: describes return format, polling mechanism, and distinguishes from sibling tools. No gaps in explaining usage, behavior, or parameters.
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 coverage, the description fully compensates by explaining each parameter's meaning, constraints (worker_count >= 1), and usage tips (omit pool_name for first, target for default). This is essential for correct invocation.
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 scales the worker node count of an existing TKC. It distinguishes from upgrade_tkc_cluster by specifying that upgrades are for K8s versions, and from create_tkc_cluster by targeting existing clusters.
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 (scale workers) and when to use upgrade_tkc_cluster instead (change K8s version). Also explains async behavior and that lowering worker_count drains nodes, setting clear expectations.
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 destructiveHint and readOnlyHint annotations, the description reveals critical behaviors: the tool is refused while TKC clusters exist, it performs a dry run by default unless dry_run=False and confirmed=True, it is irreversible, and it returns either a preview or a deletion confirmation. This rich detail goes far 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a concise summary, a safety/behavior section, and an Args list. Every sentence provides unique and essential information—no filler. Although it is longer than a simple one-liner, it packs crucial details in an organized, skimmable way.
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 destructive tool with no output schema, the description is remarkably complete: it states the outcome, the safety refusal condition, the required prerequisite steps, the alternative tool, the dry-run default, and the meanings of all parameters. There is no significant missing context that a caller would need.
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 manually explains all four parameters: name (discover via list_namespaces), confirmed (must be True to proceed), dry_run (preview only, default True), and target (vCenter in config.yaml, default if omitted). This fully compensates for the schema's lack of 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 clearly states the action: 'Delete a vSphere Namespace and everything inside it.' It uses a specific verb and resource, and distinguishes itself from update_namespace by noting it is the irreversible deletion option. This fully differentiates it from sibling 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?
The description gives explicit when-to-use and when-to-avoid guidance: it says prefer update_namespace for quota changes only, and explains that deletion is refused while TKC clusters exist, directing the user to list_tkc_clusters and delete_tkc_cluster first. It also mentions discovering names via list_namespaces, making usage conditions clear.
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?
The description discloses critical behaviors beyond annotations: dry run default, confirmed/dry_run interplay, irreversible nature, force parameter dangers, and the refusal when workloads run. Annotations already mark destructiveHint=true, but the description adds vital safety context 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?
Well-structured with a summary first, return value, safety block, and Args list. Every sentence carries operational meaning; no filler or redundancy. The [WRITE] prefix is a useful upfront signal.
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?
Covers the full operational picture: purpose, return value, safety prerequisites, alternative tool suggestions, and all 6 parameter semantics. Given the complexity of a destructive action with multiple safeguards, this description leaves no critical gaps.
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 every parameter in Args, including name sourcing via list_tkc_clusters, namespace meaning, confirmed requirement, dry_run semantics, force danger, and target default. This exceeds schema value.
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 'Delete a TKC cluster and all of its nodes,' which is a specific verb+resource statement that clearly distinguishes it from siblings like scale_tkc_cluster and delete_namespace. It goes further by explicitly referencing alternatives, eliminating any ambiguity about what this tool does.
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 when-to-use and when-not-to-use guidance: use scale_tkc_cluster for fewer nodes, empty a namespace before delete_namespace, and notes the safety condition requiring force=True to bypass running workloads. This is exceptional contextual direction.
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 indicate read-only, open-world, idempotent, non-destructive. Description adds context: returns a single object not list, is point-in-time, and CONFIGURING namespace may lack quotas. No contradictions.
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?
Well-structured: header, return details, usage sequence, state note, parameter documentation. Every sentence is informative and no 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?
Covers return fields, usage flow, state warning, and parameter info despite no output schema. Complete for the tool's 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 has 0% description coverage; description fully documents both parameters: name with example and discovery source (list_namespaces), target with default behavior.
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 it '[READ] Get detailed configuration for a single vSphere Namespace' and lists specific fields returned. It distinguishes from sibling tools like list_namespaces, list_namespace_storage_usage, and list_tkc_clusters.
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 guides to use list_namespaces first for the name, and follow with list_namespace_storage_usage or list_tkc_clusters for related info. Also warns about point-in-time and CONFIGURING state.
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 readOnly/idempotent annotations, the description details return fields and semantics (e.g., config_status values, kubernetes_version null behavior with hint), and begins with '[READ]' to reinforce safety. It adds meaningful behavioral context without contradicting 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 well-structured: a lead sentence, a concise list of return fields, usage guidance, and then parameter details. Every sentence earns its place; there is no fluff 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 the tool's moderate complexity, the description covers purpose, output, prerequisites, parameter semantics, and typical usage context. No output schema exists, but the description 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.
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 cluster_id with an example and source from check_vks_compatibility, and target with its default behavior. This goes far beyond the bare schema, making invocation accurate.
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 'Get the health of one Supervisor Cluster' with a specific verb and resource, listing the exact status fields returned. It distinguishes itself from sibling tools like get_namespace and get_tkc_cluster by focusing on Supervisor Cluster health.
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?
It explicitly instructs to run check_vks_compatibility first for cluster IDs and to use this tool to confirm health before create_namespace or create_tkc_cluster, giving clear when-to-use context and prerequisites. This is strong guidance for an agent deciding between tools.
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 annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint), the description explains the return envelope structure, guarantees 'truncated is always False' due to walking the Supervisor list, and warns about a deprecated 'clusters' alias. This adds meaningful 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 well-structured and front-loaded with the action and resource. It includes return format, workflow guidance, deprecation note, and parameter explanations without redundancy or wasted words.
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 complexity and lack of output schema, the description adequately documents the return envelope, pagination behavior, and next-step suggestions. It covers all essential invocation context, making it complete for an AI agent.
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 compensates by explaining both parameters: namespace as a filter with 'omit to list every one' and target as the vCenter in config.yaml with a default. This adds substantive meaning beyond the raw 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 specifically states 'List TanzuKubernetesCluster (TKC) clusters, optionally in one namespace', using a clear verb and resource. It also distinguishes itself from related tools by mentioning get_tkc_cluster and get_tkc_kubeconfig for follow-up actions.
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 guidance is provided: 'Start here, then call get_tkc_cluster for full detail or get_tkc_kubeconfig for access.' It also clarifies that omitting namespace lists all clusters, and provides deputy default behavior for target.
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?
Discloses return envelope details, that one call returns all results with truncated always false, and the resource reservation semantics of class names. This goes well beyond the annotations, which only state read-only/idempotent hints.
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 a clear [READ] prefix, purpose, return details, usage guidance, and args section. Every sentence adds value without redundancy 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?
For a simple list tool with one optional parameter and no output schema, this description covers purpose, return shape, usage prerequisites, and parameter semantics. It is fully self-contained and leaves no important gaps.
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?
Describes the only parameter 'target' as a vCenter from config.yaml and explains how to omit it for default. This adds meaning beyond the raw schema, which only lists a nullable string with a default.
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 clearly states it lists VM classes for sizing TKC cluster nodes, with specific verb and resource. It distinguishes itself from siblings by mentioning the use case and the return envelope structure, making it clear what the tool does.
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 to call this before create_tkc_cluster and pass the id as vm_class, and contrasts guaranteed vs. best-effort classes. This provides clear when-to-use guidance and even names a sibling tool.
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?
Discloses important behavioral traits beyond annotations: 'Applies immediately — no dry run, no undo.' Describes return values ('no_changes' or {namespace, status:'updated'}). No contradiction with annotations (readOnlyHint=false, etc.).
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?
Well-structured with a clear heading, behavioral summary, usage guidance, and parameter descriptions. Every sentence adds value; no unnecessary words. Important info is front-loaded.
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 complexity (write operation, multiple optional parameters), the description covers all necessary context: patching behavior, no undo, how to get valid policy values, return values, and usage vs sibling. No output schema needed as return is described.
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 provides explicit semantics for all 5 parameters: name, cpu_limit, memory_limit_mib, storage_policy, and target. For each, it explains the meaning and how to omit to keep current value.
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 begins with '[WRITE]' and clearly states 'Update resource quotas or storage policy of an existing vSphere Namespace.' It distinguishes from sibling create_namespace by explicitly saying 'Use this rather than create_namespace when the namespace exists.'
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 guidance: 'Use this rather than create_namespace when the namespace exists' and 'valid storage_policy values come from list_supervisor_storage_policies.' Also explains the behavior when omitting all fields (returns 'no_changes' without API call).
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 (destructiveHint=false), the description discloses that the operation is asynchronous, irreversible (cannot downgrade), and has no dry run. This provides critical behavioral context that annotations alone do not convey.
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 (6 sentences), front-loaded with the core purpose, and structured with a summary, behavioral notes, and parameter details. No superfluous text.
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 complexity (async, irreversible) and no output schema, the description provides complete guidance: what it does, returns, monitoring steps, alternative tools, and parameter meanings. It equips an agent to use the tool 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?
The description includes an Args section that explains each parameter: name (via list_tkc_clusters), namespace, k8s_version (from get_tkc_available_versions), and target (vCenter config.yaml). This adds significant meaning despite the input schema having 0% description coverage.
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 upgrades a TKC cluster to a new Kubernetes version using a specific verb+resource. It distinguishes itself from sibling tools like scale_tkc_cluster and provides context on what it does not do (e.g., node count changes).
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 explicitly states to use this tool only for K8s version upgrades, prefers scale_tkc_cluster for node counts, and provides monitoring instructions (poll get_tkc_cluster). It also notes the asynchronous and irreversible nature.
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-VKS MCP server](https://glama.ai/mcp/servers/vmware-skills/VMware-VKS/badges/card.svg)](https://glama.ai/mcp/servers/vmware-skills/VMware-VKS)

Score Badge

Copy to your README.md:

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

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-VKS'

If you have feedback or need assistance with the MCP directory API, please join our Discord server