Skip to main content
Glama

network

Monitor and diagnose Windows network components including adapters, connections, ports, routing, and perform network testing operations.

Instructions

Network information and diagnostics including network adapters, connections, ports, routing, and network testing

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYesThe network operation to perform
hostNoTarget host for ping, traceroute, or port scanning
portNoSpecific port number for port-related operations
port_rangeNoPort range for scanning (e.g., '80-443')
protocolNoProtocol filter for connections and ports (default: all)all
countNoNumber of ping packets to send (default: 4)
timeoutNoTimeout in seconds for network operations (default: 5)

Implementation Reference

  • Main handler function that dispatches to specific network operations based on the 'action' parameter.
    async run(args: {
      action: string;
      host?: string;
      port?: number;
      port_range?: string;
      protocol?: string;
      count?: number;
      timeout?: number;
    }) {
      try {
        switch (args.action) {
          case "get_network_adapters":
            return await this.getNetworkAdapters();
          case "get_active_connections":
            return await this.getActiveConnections(args.protocol);
          case "get_listening_ports":
            return await this.getListeningPorts(args.protocol);
          case "get_routing_table":
            return await this.getRoutingTable();
          case "ping_host":
            return await this.pingHost(args.host!, args.count);
          case "trace_route":
            return await this.traceRoute(args.host!);
          case "get_dns_info":
            return await this.getDnsInfo();
          case "get_network_statistics":
            return await this.getNetworkStatistics();
          case "scan_open_ports":
            return await this.scanOpenPorts(args.host!, args.port_range);
          case "get_wifi_profiles":
            return await this.getWifiProfiles();
          default:
            throw new Error(`Unknown action: ${args.action}`);
        }
      } catch (error: any) {
        return {
          content: [{
            type: "text",
            text: `❌ Network operation failed: ${error.message}`
          }],
          isError: true
        };
      }
    },
  • Input schema defining parameters, actions, and options for the network tool.
    parameters: {
      type: "object",
      properties: {
        action: {
          type: "string",
          enum: ["get_network_adapters", "get_active_connections", "get_listening_ports", "get_routing_table", "ping_host", "trace_route", "get_dns_info", "get_network_statistics", "scan_open_ports", "get_wifi_profiles"],
          description: "The network operation to perform"
        },
        host: {
          type: "string",
          description: "Target host for ping, traceroute, or port scanning"
        },
        port: {
          type: "number",
          description: "Specific port number for port-related operations"
        },
        port_range: {
          type: "string",
          description: "Port range for scanning (e.g., '80-443')"
        },
        protocol: {
          type: "string",
          enum: ["tcp", "udp", "all"],
          description: "Protocol filter for connections and ports (default: all)",
          default: "all"
        },
        count: {
          type: "number",
          description: "Number of ping packets to send (default: 4)",
          default: 4
        },
        timeout: {
          type: "number",
          description: "Timeout in seconds for network operations (default: 5)",
          default: 5
        }
      },
      required: ["action"]
  • src/index.ts:52-56 (registration)
    Registration of network tool metadata in the list tools response.
    {
      name: networkTool.name,
      description: networkTool.description,
      inputSchema: networkTool.parameters
    },
  • src/index.ts:81-82 (registration)
    Dispatcher case for handling 'network' tool calls.
    case "network":
      return await networkTool.run(args as any);
  • Example helper method for retrieving network adapter information.
    async getNetworkAdapters() {
      try {
        const command = `Get-NetAdapter | Select-Object Name, InterfaceDescription, Status, LinkSpeed, MediaType, PhysicalMediaType | Format-Table -AutoSize`;
        const { stdout } = await execAsync(`powershell -Command "${command}"`);
        
        // Also get IP configuration
        const ipCommand = `Get-NetIPAddress | Where-Object {$_.AddressFamily -eq 'IPv4'} | Select-Object InterfaceAlias, IPAddress, PrefixLength | Format-Table -AutoSize`;
        const { stdout: ipInfo } = await execAsync(`powershell -Command "${ipCommand}"`);
        
        const result = `# Network Adapters\n\n## Adapter Information\n\`\`\`\n${stdout}\n\`\`\`\n\n## IP Configuration\n\`\`\`\n${ipInfo}\n\`\`\``;
        
        return {
          content: [{ type: "text", text: result }]
        };
      } catch (error: any) {
        throw new Error(`Failed to get network adapters: ${error.message}`);
      }
    },
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'network testing' which implies potentially invasive operations like port scanning, but doesn't warn about permissions needed, rate limits, network impact, or whether operations are read-only versus intrusive. The description is too vague about behavioral traits beyond stating what operations exist.

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 a single, efficient sentence that front-loads the core purpose ('network information and diagnostics') followed by specific examples. Every word earns its place with no redundancy or wasted phrasing. The structure is clear and appropriately sized for a multi-function tool.

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 7 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what kind of information is returned, how results are formatted, whether operations are synchronous/asynchronous, or any error conditions. The description covers what the tool does at a high level but lacks necessary operational context for proper agent usage.

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 all 7 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. It mentions general categories like 'network testing' which aligns with actions like ping_host and scan_open_ports, but provides no additional semantic context about parameter usage or relationships.

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 clearly states the tool provides 'network information and diagnostics' with specific examples like adapters, connections, ports, routing, and testing. It distinguishes itself from siblings like filesystem or process_manager by focusing on network operations. However, it doesn't explicitly differentiate from potential network-related siblings (none exist in this server).

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. While it lists network operations, it doesn't specify prerequisites, appropriate contexts, or limitations. For example, it doesn't mention if certain actions require administrative privileges or when to choose ping_host versus trace_route.

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/guangxiangdebizi/windows-system-mcp'

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