Nginx Proxy Manager MCP

Overview Schema Source Related Servers Discussions Admin

List Streams

list_streams

List configured TCP/UDP streams and their status to find stream IDs before fetching, changing, enabling, disabling, or deleting port forwards. Filter by enabled; read-only.

Instructions

List configured TCP/UDP streams and their current status. Use this to find stream IDs before fetching, changing, enabling, disabling, or deleting a port forward. This is read-only and does not change NPM. Filter status with enabled. Set compact=True to return only summary fields. Returns stream objects with IDs, incoming and forwarding ports, protocols, and status.

Input Schema

Name	Required	Description	Default
`compact`	No	Return only summary fields when True; defaults to full NPM objects.
`enabled`	No	Keep items with this enabled status; omit for both enabled and disabled items.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.6.0Oct 18, 2026

addedInput schema / properties / compact

Added value: +{
+  "default": false,
+  "description": "Return only summary fields when True; defaults to full NPM objects.",
+  "type": "boolean"
+}

addedInput schema / properties / enabled

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Keep items with this enabled status; omit for both enabled and disabled items."
+}

First observedv0.5.1Oct 16, 2026

TDQS

A4.2/5.0

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 and does state 'This is read-only and does not change NPM', which is the key safety signal for an agent. It also previews the shape of returned objects, though it says nothing about pagination or ordering.

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?

Five short sentences, front-loaded with purpose, then usage, then the read-only caveat, then parameter hints and return shape. No filler and no repetition that isn't functional.

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?

An output schema exists, so the description needn't enumerate return fields — the closing sentence describing stream objects is somewhat redundant. Otherwise nothing an agent needs to select and call this read-only list tool correctly is missing.

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%, so both parameters are already fully documented in the schema. The description's 'Filter status with enabled' and 'Set compact=True to return only summary fields' largely restate the schema text rather than adding format or interaction detail, so the baseline 3 applies.

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?

States a specific verb and resource ('List configured TCP/UDP streams and their current status'), distinguishing it immediately from mutation siblings like create_stream or enable_stream. The scope (all configured streams, not a single one) is unambiguous versus get_stream.

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

Usage Guidelines4/5

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

Explicitly frames the tool as the lookup step before fetching, changing, enabling, disabling, or deleting a port forward, which maps onto the get_stream/update_stream/enable_stream/disable_stream/delete_stream siblings. It stops short of naming an alternative list tool or stating when not to use it, keeping it just below a 5.

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