nido-mcp
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 | {} |
| prompts | {} |
| resources | {
"subscribe": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| nido_eventsA | Control this MCP session's opt-in Nido event subscriptions. Subscribe to a VM URI or core resource; mute/unmute keeps filters, unsubscribe removes them. No notifications by default. Read nido://system/events for stream health and recent subscribed events. Notifications contain only an invalidated URI. |
| nido_vmB | Operate the VM fleet through a single high-power tool. Use actions such as list, info, create, start, stop, delete, ssh, prune, config_update, port_forward, port_unforward, and port_list. Prefer resources like nido://fleet/vms or nido://vm/{name} for inspection when your client supports resources; use this tool for mutations or as a universal fallback. |
| nido_templateB | Manage reusable VM templates with a single tool. Supported actions are list, create, and delete. Use nido://fleet/templates when you only need to inspect template names. |
| nido_imageA | Manage the image catalog and cache through one namespaced tool. Supported actions are list, info, pull, remove, refresh_catalog, cache_list, cache_info, cache_remove, and cache_prune. Prefer resources like nido://catalog/images, nido://image/{tag}, and nido://storage/cache for inspection to reduce token usage. |
| nido_blueprintB | Manage buildable image blueprints. Supported actions are list, info, and build. Prefer nido://catalog/blueprints and nido://blueprint/{name} for read-only inspection. |
| nido_systemC | Access system-wide Nido operations that are not tied to one VM. Supported actions are doctor, version, update_check, update, config_get, config_set, accel_list, register, completion, build_image, and uninstall. Use read-only resources when possible. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| nido_task_router | Guidance for using Nido efficiently through MCP with low token overhead. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Event stream | Session event subscriptions, stream health and bounded recent core events. |
| Fleet VMs | Compact fleet summary for all known VMs. |
| Fleet Templates | Template names available for cloning. |
| Image Catalog | Compact image catalog summary optimized for agent browsing. |
| Blueprint Catalog | Buildable image blueprint summaries, including output cache state. |
| Cache Summary | Cache stats plus cached image entries. |
| System Config | Current provider configuration. |
| System Doctor | Diagnostic report for the local environment. |
| System Version | Current Nido version and protocol. |
| System Accelerators | PCI accelerator candidates. |
| MCP Registration | MCP client registration block. |
TDQS
Scored across 6 tools
The six tools map cleanly to distinct domains: events, VMs, templates, images, blueprints, and system operations. Minor potential overlap exists around image building, where nido_system build_image, nido_image pull, and nido_blueprint build could require an agent to reason about which layer is intended.
All tools use a consistent nido_ namespace followed by a domain noun, making the set predictable. The only minor deviation is nido_events being plural while the other domain names are singular.
Six tools is well within the appropriate range and each corresponds to a meaningful resource domain. The set is compact even though several tools expose many actions internally.
VM, image, system, and event operations are broadly covered, including lifecycle and port-forwarding actions. There are some minor gaps, such as template update/info operations and blueprint create/delete lifecycle operations, though resources may cover read-only inspection.