Skip to main content
Glama
moimran

EVE-NG MCP Server

by moimran

delete_lab_network

Remove a network from an EVE-NG lab to clean up network topology. This action permanently deletes the network and all its connections.

Instructions

Delete a network from a lab.

This tool permanently removes a network from the lab. All connections to this network will be lost. This action cannot be undone.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
argumentsYes

Implementation Reference

  • MCP tool handler function that implements the delete_lab_network tool logic. Validates arguments, checks EVE-NG connection, calls the client wrapper, handles success/error responses, and returns formatted TextContent.
    async def delete_lab_network(arguments: DeleteNetworkArgs) -> list[TextContent]:
        """
        Delete a network from a lab.
    
        This tool permanently removes a network from the lab. All connections
        to this network will be lost. This action cannot be undone.
        """
        try:
            logger.info(f"Deleting network {arguments.network_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 network
            result = await eveng_client.delete_lab_network(arguments.lab_path, int(arguments.network_id))
    
            if result.get('status') == 'success':
                return [TextContent(
                    type="text",
                    text=f"Successfully deleted network {arguments.network_id} from {arguments.lab_path}\n\n"
                         f"⚠️  The network has been permanently removed from the lab.\n"
                         f"All connections to this network have been lost.\n"
                         f"This action cannot be undone."
                )]
            else:
                return [TextContent(
                    type="text",
                    text=f"Failed to delete network: {result.get('message', 'Unknown error')}"
                )]
    
        except Exception as e:
            logger.error(f"Failed to delete network: {e}")
            return [TextContent(
                type="text",
                text=f"Failed to delete network: {str(e)}"
            )]
  • Pydantic model defining input schema/arguments for the delete_lab_network tool: lab_path and network_id.
    class DeleteNetworkArgs(BaseModel):
        """Arguments for delete_network tool."""
        lab_path: str = Field(description="Full path to the lab (e.g., /lab_name.unl)")
        network_id: str = Field(description="Network ID to delete")
  • Helper method in EVENGClientWrapper that wraps the EVE-NG SDK API call to delete_lab_network, including connection check, async thread execution, logging, and error handling.
    async def delete_lab_network(self, lab_path: str, net_id: int) -> Dict[str, Any]:
        """Delete a network from a lab."""
        await self.ensure_connected()
    
        try:
            result = await asyncio.to_thread(self.api.delete_lab_network, lab_path, net_id)
            self.logger.info("Deleted lab network", lab_path=lab_path, net_id=net_id)
            return result
        except Exception as e:
            self.logger.error("Failed to delete lab network", **log_error(e, {"lab_path": lab_path, "net_id": net_id}))
            raise EVENGAPIError(f"Failed to delete lab network: {str(e)}")
  • Registration call for network management tools (including delete_lab_network) within the overall tools registration in tools/__init__.py.
    # Network management tools
    register_network_tools(mcp, eveng_client)
  • Top-level registration of all tools (including network tools with delete_lab_network) in the main MCP server initialization.
    register_tools(self.mcp, self.eveng_client)
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 behavioral traits: the action is permanent ('permanently removes'), has irreversible consequences ('cannot be undone'), and causes collateral damage ('All connections to this network will be lost'). This provides essential context about the destructive nature of the operation.

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 perfectly structured with three concise sentences that each add distinct value: stating the action, explaining consequences, and warning about irreversibility. There's zero redundancy or wasted words, and the most critical information (permanent removal) is front-loaded.

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?

For a destructive tool with no annotations and no output schema, the description does well on behavioral transparency but fails to address parameter semantics. It adequately warns about the irreversible nature but leaves the agent without guidance on how to specify which network to delete, creating a significant gap in usability.

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

Parameters2/5

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

The input schema has 0% description coverage, and the tool description provides no information about the required parameters (lab_path and network_id). While the description mentions 'a network from a lab,' it doesn't explain how to identify or specify these resources, leaving the agent with insufficient guidance on parameter usage.

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 ('permanently removes') and resource ('a network from the lab'), distinguishing it from sibling tools like delete_lab or delete_node. It uses precise language that goes beyond just restating the tool name.

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 delete_lab or wipe operations. It mentions the consequences ('All connections to this network will be lost') but doesn't specify prerequisites, dependencies, or comparative usage scenarios with sibling tools.

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