Skip to main content
Glama
opsmill

infrahub-mcp

Official
by opsmill
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Node Delete

node_delete
Destructive

Delete a node from an Infrahub session branch using its kind and UUID or HFID. Changes remain branch-only until a proposed change is merged.

Instructions

Delete a node in Infrahub on the active session branch.

The deletion is applied to the session branch only and is not visible on the default branch until a proposed change is merged. To discover available kinds, read the infrahub://schema resource. If your client does not support MCP resources, call the get_schema tool instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoUUID of the node to delete.
hfidNoHuman-friendly ID of the node to delete, as a list of string segments.
kindYesKind of the node to delete. Check infrahub://schema.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.0
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "type": "object"
-}New value: +null
  2. First observedv1.1.5

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the mutation is branch-scoped and therefore not immediately propagated, which tells the agent the operation is contained and recoverable via the proposed-change flow.

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?

Front-loaded with the core action, followed by the branch-visibility caveat and a compact fallback instruction for clients without resource support. Each sentence earns its place; only slight redundancy between the resource mention in the description and the schema's kind note.

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?

For a 3-parameter destructive tool with no output schema, the description covers the essential branch semantics, the schema location for valid kinds, and a non-resource fallback. It is complete enough to call correctly, though it omits what a successful deletion returns or how errors surface.

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 description coverage is 100%, so the schema already documents id, hfid and kind. The description only reinforces kind discovery via infrahub://schema / get_schema and adds no syntax or selection guidance for id vs hfid beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource ('Delete a node in Infrahub') with a clear scope qualifier (active session branch). It does not explicitly contrast itself with the closest sibling node_upsert, but the verb makes the distinction inferable.

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?

Gives clear operational context: deletion affects the session branch only and is not visible on the default branch until a proposed change is merged, plus routing advice for discovering valid kinds. It stops short of stating when to prefer this over node_upsert or alternate deletion paths.

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