How do you find which of your ports are open, from an AI assistant?

Ask your agent to check a target you own

Install AdminKit’s open-source adminkit-mcp connector (MIT, PyPI) and wire it into any MCP-capable AI agent — see connect an AI agent to AdminKit’s MCP server if you haven’t yet:

uvx adminkit-mcp

Then ask it, in plain language:

“Use check_owned_ports to check which ports are open on the device/host I just verified I own, and tell me if anything looks risky.”

The agent calls check_owned_ports(target="...") and gets back a structured result rather than raw scan output you’d have to interpret yourself.

Why this check is gated, and what that means for an agent

Active port probing is only meaningful, and only safe to run without abuse risk, once the target’s ownership is verified — that gate lives on AdminKit’s Check API, not in the connector, so an agent calling this tool inherits the same server-side ownership check a human would hit using the port exposure check tool page directly. This matters for agent builders specifically: a tool an agent can call freely against any string a user supplies is a different trust boundary than one gated server-side, and check_owned_ports is built as the latter on purpose rather than trusting the calling agent (or whatever prompted it) to self-police which targets are fair game.

Example response (fixture)

This is a labelled fixture, not a claim about any specific host’s real exposure: the exact response shape check_owned_ports returns, matching the connector’s own open-source test suite. Reproduce it yourself by asking your agent to run the tool against a target you’ve verified you own. A host with an exposed legacy service comes back like this:

{
  "tool": "check_owned_ports",
  "status": "warn",
  "result": {
    "check": "ports",
    "target": "verified-asset.example.com",
    "summary": "1 commonly-exploited port is open.",
    "findings": [
      { "fix_hint": "Close Telnet (23) on this host." }
    ],
    "score": 70
  },
  "evidence": {},
  "fix_hint": "Close Telnet (23) on this host.",
  "report_url": "https://adminkit.net/tools/port-check/?utm_source=mcp"
}

If the Check API’s port endpoint is briefly unreachable, the tool reports status: "not_available" with a plain message saying so, rather than fabricating a result — the same honesty guarantee every adminkit-mcp tool follows. How to read an open ports on my IP scan result covers interpreting a findings list like this port-by-port, including why some ports (database ports like MongoDB, management ports like RDP) carry a higher fix_hint priority than others.

Why this matters for an inventory, not just one host

Telnet, RDP, VNC, SMB and database ports like MongoDB or Redis were mostly built for trusted local networks, and the NIST firewall guidelines treat default-deny on exactly these kinds of unneeded inbound services as a baseline control, not an advanced one — the IANA port registry is the authoritative list of what each of these numbers is actually assigned to serve. An agent that can call check_owned_ports on demand fits naturally into a recurring inventory check across every host you own, rather than a one-off manual pass — see our AI agent builders solutions page for the broader pattern of wiring AdminKit’s checks into an agent-driven workflow.

This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.