mcp-server-wslc
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_containersA | List all WSL containers. Use the optional 'format' parameter to control output format (table, json). |
| container_createC | Create a new WSL container. Returns the container ID on success. |
| container_runB | Run a new WSL container. Defaults to foreground; use detach for background. |
| container_inspectB | Display detailed information about a WSL container. |
| container_startA | Start a stopped WSL container. |
| container_stopB | Stop a running WSL container. |
| container_restartA | Restart a WSL container. Since wslc has no native restart command, this stops then starts the container. |
| container_removeB | Remove a WSL container. |
| container_logsB | View logs from a WSL container. |
| container_execB | Execute a command inside a running WSL container. |
| container_statsB | Display resource usage snapshot for running WSL containers. |
| list_imagesA | List all WSL container images. Use the optional 'format' parameter to control output format (table, json). |
| image_pullB | Pull a container image from a registry. |
| image_pushA | Push a container image to a registry. |
| image_buildB | Build a container image from a Dockerfile. |
| image_tagB | Tag a container image with a new name/tag. |
| image_inspectB | Display detailed information about a container image. |
| image_removeB | Remove a container image. |
| network_listA | List all WSL networks. |
| network_createC | Create a new WSL network. |
| network_removeC | Remove one or more WSL networks. |
| volume_listB | List all WSL volumes. |
| volume_createA | Create a new named volume that can be attached to containers. |
| volume_removeA | Remove one or more volumes. Volumes in use by a container cannot be removed. |
| registry_loginA | Log in to a container registry. If no server is specified, the session default is used. Prefer using passwordStdin over password to avoid exposing credentials in process lists. |
| registry_logoutA | Log out from a container registry. If no server is specified, the session default is used. |
| system_versionA | Get wslc CLI version information. |
| system_pruneA | Remove all stopped containers and unused images, networks, and volumes to free up resources. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 28 tools
Each tool targets a distinct resource-action pair, such as container_run vs container_create vs container_start, which are clearly differentiated by their descriptions. Resources like containers, images, volumes, networks, and registry operations are cleanly separated, leaving no ambiguity.
Most tools follow the verb_noun pattern (e.g., container_create, image_pull, network_list), but a few like list_containers and list_images reverse the order, creating minor inconsistency. The overall structure is predictable and readable, with only slight deviations.
With 28 tools, the count is on the higher end, but it corresponds to the broad domain of container management, covering containers, images, volumes, networks, and registry operations. Each tool serves a distinct purpose, making the size justified despite being above the typical 15-tool benchmark.
The tool surface provides comprehensive lifecycle coverage for containers (create, run, start, stop, restart, remove, inspect, logs, exec, stats), images (build, pull, push, tag, inspect, remove), and basic operations for volumes, networks, and registries. Minor gaps such as network connect/disconnect and volume inspect are present, but core workflows are well-supported.