Skip to main content
Glama
fettlesh

fettle-mcp

by fettlesh
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

Get the exposed-ports preset

get_exposed_ports_preset
Read-onlyIdempotent

Lists database, queue, and admin ports that should stay closed to the internet, so you can choose ports for TCP monitors that flag exposed services. Returns port numbers and services; creates nothing.

Instructions

List the ports that should never be reachable from the internet (databases, queues, admin panels). Returns ports, each a port number and the service that usually listens on it. Use it to pick ports when asked to watch a server for exposed services; it creates nothing. Then create one TCP monitor on the server's public hostname or IP with config {"ports": [...], "expected_state": "closed"} (1 to 20 distinct ports, one region, interval_seconds 300 or more; 3600 is plenty) through create_monitor: it counts as one monitor and fails naming every port that answers.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
portsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.6.1
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "ports": {
+      "items": {
+        "properties": {
+          "port": {
+            "type": "integer"
+          },
+          "service": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "port",
+          "service"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "ports"
+  ],
+  "type": "object"
+}
  2. First observedv0.5.4

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so 'it creates nothing' is largely redundant. The description still adds genuine value by describing what the list contains (port number plus the service that usually listens on it) and by warning how the data is consumed downstream (one monitor counted, fails naming every answering port).

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?

Front-loaded with the purpose in the first clause, then uses. The final sentence is long and packs create_monitor configuration details that arguably belong in that tool's own docs, though they are actionable for completing the workflow.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter preset lookup with rich annotations and an output schema, this is more than sufficient: purpose, return content, safe-to-call status, and the intended downstream workflow are all covered.

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

Parameters4/5

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

The tool takes zero parameters, which is the baseline-4 case; nothing in the description is needed to disambiguate arguments. The mention of the 1-20 distinct ports / interval_seconds constraints pertains to create_monitor's payload, not this tool's schema.

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 with scope: 'List the ports that should never be reachable from the internet (databases, queues, admin panels).' It also names the return content, so an agent knows this is a static preset lookup rather than a scan of any particular server, distinguishing it from siblings like check_target or get_monitor.

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

Usage Guidelines5/5

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

Explicitly says when to use it ('Use it to pick ports when asked to watch a server for exposed services'), what it does not do ('it creates nothing'), and names the follow-up tool with the exact config shape, port/region/interval constraints, and the failure semantics of that call.

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