Skip to main content
Glama
Sign In
nido-mcp

nido-mcp

by Josepavese
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

nido_blueprint

Manage buildable image blueprints by listing available ones, inspecting details, or triggering a build, so agents can prepare VM images from blueprints.

Instructions

Manage buildable image blueprints. Supported actions are list, info, and build. Prefer nido://catalog/blueprints and nido://blueprint/{name} for read-only inspection.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "nido_blueprint"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoBlueprint name for action=info or action=build.
actionYes
blueprint_nameNoCompatibility alias for name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv4.8.7

TDQS

B3.4/5.0
Behavior2/5

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

With no annotations, the description carries the full burden, and it never explains what build actually does — whether it mutates state, what it produces, whether it requires preconditions, or whether it is destructive/irreversible. The only behavioral hint is implicit in the word 'buildable' and the read-only resource pointers.

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?

Two short sentences with the resource and action list front-loaded and the alternative-resource guidance second. Nothing is wasted.

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

Completeness2/5

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

For a tool with a mutating action (build), no annotations, and no output schema, the description should explain what build produces and any preconditions or risks. As written, an agent knows the read-only escape hatches but not the semantics of the one action that changes state.

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

Parameters3/5

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

Schema coverage is 67% and the action enum is undocumented in the schema, so the description's enumeration of list/info/build does add meaning. However, it never distinguishes what each action requires or returns (e.g. that name matters only for info/build), and the blueprint_name alias is left to the schema.

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

Purpose4/5

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

The description names a concrete resource (buildable image blueprints) and enumerates the exact action verbs (list, info, build), which lets an agent tell it apart from siblings like nido_image or nido_template. The 'manage' framing is a bit broad, but the action list pins down the scope.

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?

It explicitly advises preferring nido://catalog/blueprints and nido://blueprint/{name} resources for read-only inspection, giving a concrete when-not-to-use signal for list/info. It stops short of saying when build is appropriate versus inspecting a blueprint via the resource first.

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

Deploy Server

Other Tools