Skip to main content
Glama
Sign In
homebutler

homebutler

by Higangssh
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Hybrid

open_ports

Read-only

List open network ports and the processes behind them, locally or on a configured remote server, flagging ports whose process can't be read without privileges.

Instructions

List open network ports with associated process information. The process behind a port is not always readable without privilege, and missing_process says so rather than leaving the field quietly empty

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "open_ports"
  }
}

Input Schema

NameRequiredDescriptionDefault
serverNoRemote server name from config (optional, runs locally if omitted; inside a container a local call is refused, because a container cannot see the machine it is on)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.8.0
    • changedInput schema / properties / server / description
      Previous value: -"Remote server name from config (optional, runs locally if omitted)"New value: +"Remote server name from config (optional, runs locally if omitted; inside a container a local call is refused, because a container cannot see the machine it is on)"
  2. First observedv0.10.2

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare this a safe read-only, non-destructive operation, so the bar is lower. The description goes beyond them by disclosing that process attribution depends on privilege and that unreadable owners are surfaced via a missing_process indicator rather than silently omitted — a genuinely useful behavioral caveat.

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?

Two sentences with the purpose front-loaded and the privilege caveat second; nothing is redundant. The second sentence is slightly dense but earns its place by explaining a field that would otherwise look like an error.

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 single optional-parameter, read-only tool this covers what the agent needs to call it and interpret the tricky case of unattributed processes. With no output schema, a brief note on the overall return shape (host/port/protocol fields) would make it fully complete.

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 100% and the server parameter is already documented in detail, including the local-vs-remote and container-refusal behavior. The description adds no additional parameter meaning, so the baseline of 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?

The description gives a specific verb and resource ("List open network ports") and adds the scope of the returned data (associated process information). It is clearly distinguishable from a generic process listing, though it does not explicitly contrast itself with siblings like network_scan or processes.

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

Usage Guidelines3/5

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

Usage is implied by the purpose: use this when you want to see which ports are listening and what owns them. There is no explicit statement of when to prefer it over network_scan (remote scanning) or processes, and no exclusions are given.

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