Skip to main content
Glama
moimran

EVE-NG MCP Server

by moimran

delete_node

Remove a node from an EVE-NG lab to delete its data and configuration permanently. This action cannot be undone.

Instructions

Delete a node from a lab.

This tool permanently removes a node from the lab. All node data and configuration will be lost. This action cannot be undone.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
argumentsYes

Implementation Reference

  • The primary handler function for the 'delete_node' MCP tool. It processes DeleteNodeArgs, ensures EVE-NG connection, invokes the client helper, and formats success/error responses as TextContent.
    @mcp.tool()
    async def delete_node(arguments: DeleteNodeArgs) -> list[TextContent]:
        """
        Delete a node from a lab.
    
        This tool permanently removes a node from the lab. All node data
        and configuration will be lost. This action cannot be undone.
        """
        try:
            logger.info(f"Deleting node {arguments.node_id} from {arguments.lab_path}")
    
            if not eveng_client.is_connected:
                return [TextContent(
                    type="text",
                    text="Not connected to EVE-NG server. Use connect_eveng_server tool first."
                )]
    
            # Delete node
            result = await eveng_client.delete_node(arguments.lab_path, arguments.node_id)
    
            if result.get('status') == 'success':
                return [TextContent(
                    type="text",
                    text=f"Successfully deleted node {arguments.node_id} from {arguments.lab_path}\n\n"
                         f"⚠️  The node has been permanently removed from the lab.\n"
                         f"This action cannot be undone."
                )]
            else:
                return [TextContent(
                    type="text",
                    text=f"Failed to delete node: {result.get('message', 'Unknown error')}"
                )]
    
        except Exception as e:
            logger.error(f"Failed to delete node: {e}")
            return [TextContent(
                type="text",
                text=f"Failed to delete node: {str(e)}"
            )]
  • Pydantic BaseModel defining the input arguments for the delete_node tool: lab_path and node_id with descriptions.
    class DeleteNodeArgs(BaseModel):
        """Arguments for delete_node tool."""
        lab_path: str = Field(description="Full path to the lab (e.g., /lab_name.unl)")
        node_id: str = Field(description="Node ID to delete")
  • Top-level registration of all tools in the main server class, which chains through tools/__init__.py to register_node_tools and ultimately the @mcp.tool() decorator for delete_node.
    # Register tools
    register_tools(self.mcp, self.eveng_client)
  • Intermediate registration call for node management tools specifically, invoking register_node_tools where delete_node is defined and registered via @mcp.tool().
    # Node management tools
    register_node_tools(mcp, eveng_client)
    
    # Network management tools
    register_network_tools(mcp, eveng_client)
  • Supporting method in EVENGClientWrapper that wraps the underlying EVE-NG API delete_node call, handles connection, logging, and error propagation.
    async def delete_node(self, lab_path: str, node_id: str) -> Dict[str, Any]:
        """Delete a node from a lab."""
        await self.ensure_connected()
    
        try:
            result = await asyncio.to_thread(self.api.delete_node, lab_path, node_id)
            self.logger.info("Deleted node", lab_path=lab_path, node_id=node_id)
            return result
        except Exception as e:
            self.logger.error("Failed to delete node", **log_error(e, {"lab_path": lab_path, "node_id": node_id}))
            raise EVENGAPIError(f"Failed to delete node: {str(e)}")
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates critical traits: the action is permanent ('permanently removes'), destructive ('All node data and configuration will be lost'), and irreversible ('This action cannot be undone'). This covers safety and consequences well, though it lacks details on permissions, errors, or 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose in the first sentence, followed by critical warnings in subsequent sentences. Every sentence adds essential value—no fluff or repetition—making it highly efficient and well-structured for quick comprehension.

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

Completeness3/5

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

Given the tool's complexity (destructive operation with 1 parameter but 0% schema coverage and no output schema), the description is partially complete. It covers behavioral aspects thoroughly but fails to address parameters or output, leaving gaps that could hinder correct invocation despite good safety warnings.

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

Parameters1/5

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

The description adds no information about parameters beyond what the input schema provides. With schema description coverage at 0% (parameters like 'arguments' are undocumented in schema), the description fails to compensate by explaining what 'arguments' contains (e.g., lab_path and node_id) or their semantics, leaving parameters entirely unclear.

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 specific action ('Delete a node from a lab') with the resource ('node') and scope ('from a lab'), distinguishing it from siblings like delete_lab, wipe_node, or stop_node. It uses precise language that leaves no ambiguity about the tool's function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like wipe_node (which may reset but not delete) or delete_lab (which removes an entire lab). It mentions the action is permanent but does not specify prerequisites, conditions, or comparisons to sibling tools, leaving the agent with insufficient context for selection.

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

Install Server

Other Tools

Latest Blog Posts

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/moimran/eveng-mcp'

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