Skip to main content
Glama
Sign In

Dechonet-MCP

by com.dechonet
OverviewDiscussionsAdmin

Open Port Scan

port_scan
Read-onlyIdempotent

Probe a host for a fixed set of common TCP ports (HTTP, HTTPS, SSH, FTP, SMTP, DNS, and common databases) and report which are open, the service name, and the response time. BEHAVIOR: this makes an ACTIVE TCP connection to the target. It is non-intrusive — a connect probe only; it does not authenticate, send exploits, or transfer data — and changes nothing on the target (read-only), but the connection is visible in the target's logs, so only scan hosts you own or are explicitly authorized to test. Use this to confirm which services are exposed. Use ssl_check or http_security instead to assess a specific service's configuration. Requires no API key; rate-limited. Returns a per-port open/closed list with service names.

Input Schema

NameRequiredDescriptionDefault
hostYesHostname or IP to probe (e.g., 'example.com' or '203.0.113.10'). A 'host:port' form is accepted to hint a specific port. Only supply targets you own or are authorized to test.

Output Schema

NameRequiredDescriptionDefault
kpisNoKey metrics as label/value pairs
gradeNoLetter grade (A+ to F) when the tool grades the target
scoreNo0-100 score when the tool scores the target
issuesNoDetected problems, severity-rated
statusYesOverall verdict, e.g. 'good' | 'warning' | 'bad' | 'info' | 'unknown'
actionsNoRecommended next actions, most important first
summaryNoOne-paragraph interpretation of the result
receiptsNoSigned observation receipts behind this result, one per lookup: when, from where and under which rules version DechoNet observed it. Each url shows the record and checks its Ed25519 signature.
reportUrlYesHuman-facing interactive report for this exact lookup on dechonet.com
observationNoHow much was actually observed and when. A partial observation means some checks did not answer: missing parts are not verified, never clean.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / receipts
      Added value: +{
+  "description": "Signed observation receipts behind this result, one per lookup: when, from where and under which rules version DechoNet observed it. Each url shows the record and checks its Ed25519 signature.",
+  "items": {
+    "properties": {
+      "id": {
+        "type": "string"
+      },
+      "tool": {
+        "type": "string"
+      },
+      "url": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "tool",
+      "id",
+      "url"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
  2. Changed1 schema field changed
    • addedOutput schema / properties / observation
      Added value: +{
+  "description": "How much was actually observed and when. A partial observation means some checks did not answer: missing parts are not verified, never clean.",
+  "properties": {
+    "ageMinutes": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "cached": {
+      "type": "boolean"
+    },
+    "observedAt": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "state": {
+      "enum": [
+        "complete",
+        "partial",
+        "unknown"
+      ],
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint true, destructiveHint false, idempotentHint true, and openWorldHint true, but the description adds substantial context beyond them: the probe is an ACTIVE TCP connect, it does not authenticate or send exploits, it changes nothing on the target, the connection appears in the target's logs, and it is unauthenticated but rate-limited. These details materially inform safe and responsible use.

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 front-loaded with the core action and scope, then layers behavior, safety constraints, alternatives, and rate-limit notes. Every sentence contributes actionable information, and the structure follows a logical progression from what it is to how to use it responsibly.

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?

Given that an output schema exists, the description need not detail return values, yet it still summarizes the output ('per-port open/closed list with service names'). Combined with annotations covering safety and the description's coverage of authorization, rate limits, and behavior, it provides everything an agent needs to call and interpret the tool.

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?

With one parameter and 100% schema description coverage, the schema already fully documents 'host' including the 'host:port' form. The description adds no additional parameter-level syntax or format details, so the baseline score of 3 is appropriate.

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?

The description states a specific verb ('Probe'), resource ('a host'), and scope ('fixed set of common TCP ports'), and explicitly distinguishes itself from siblings ssl_check and http_security by naming them. An agent can identify the tool's unique purpose without opening its schema.

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?

It provides explicit when-to-use ('confirm which services are exposed'), when-not/alternatives ('Use ssl_check or http_security instead to assess a specific service's configuration'), and a clear authorization precondition ('only scan hosts you own or are explicitly authorized to test'). This leaves no ambiguity about appropriate invocation contexts.

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

All Dechonet-MCP toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources