Skip to main content
Glama
Sign In

Dechonet-MCP

by com.dechonet
OverviewDiscussionsAdmin

OWASP Security Checkup

owasp_check
Read-onlyIdempotent

Assess a domain's OWASP posture from EXTERNAL OBSERVATION only: the OWASP Secure Headers Project plus the externally observable OWASP Top 10:2025 subset — A04 Cryptographic Failures (TLS/cert), A02 Security Misconfiguration (header/info leaks), and A03 Software Supply Chain Failures (outdated components via version disclosure) — returning an A+ to F grade. Scope: A01 (Access Control, incl. SSRF), A05 (Injection), A06 (Insecure Design), A07 (Authentication), A08, A09 and A10 (Exceptional Conditions) are not checked — they need authenticated access or active/injection testing, so the result lists them as out-of-scope rather than "pass". The result is an external-posture check, not a full OWASP Top 10 assessment. This is PASSIVE (a normal HTTPS request, the TLS certificate and a public CT-log lookup; no port scan, no path probing), so it is suitable for domains you do not own. The sensitive-file check (.env, .git, server-status) runs only for the verified domain owner on the web report (DNS TXT), never through this tool. Use http_security or ssl_check for depth on one layer. Read-only; requires no API key; rate-limited. Returns a text report: grade, per-category findings, the out-of-scope list, and a shareable report link.

Input Schema

NameRequiredDescriptionDefault
hostYesHostname to assess, without scheme (e.g., 'example.com'). The host portion of a pasted URL is also accepted.

Output Schema

NameRequiredDescriptionDefault
gradeYesOWASP posture grade A+ to F, over the observable categories only
scoreYes0-100 across the categories that could be evaluated
checksYesPer observable category: Secure Headers, A02, A05, A06
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 on dechonet.com
notObservableNoTop 10 categories NOT checked (need authenticated/active testing)

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. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, and the description adds substantial context beyond them: the exact passive techniques used (HTTPS request, TLS cert, CT-log lookup), explicit absence of port scanning or path probing, the owner-only gating of the sensitive-file check, no API key requirement, and rate limiting.

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?

Dense but front-loaded: capability and scope come first, exclusions and safety characteristics follow, and the return shape is stated last. Every clause carries information, though the single long paragraph could be broken up for faster scanning.

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?

Despite an output schema existing, the description still summarizes the return (grade, per-category findings, out-of-scope list, shareable link), which is more than required. Scope limits, safety posture, prerequisites, and alternatives are all covered for a one-parameter 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?

Schema coverage is 100% and the single 'host' parameter's format (no scheme, URL host accepted) is already fully documented in the schema. The description adds no syntax or constraint detail beyond that, 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+resource (assess a domain's OWASP posture) and precisely delineates what subset is covered (A04/A02/A03 plus Secure Headers) versus what is not (A01, A05-A10). It also names the sibling tools http_security and ssl_check as alternatives for single-layer depth, so an agent can distinguish it without opening any 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?

Gives explicit when-to-use (external posture check), when-not (authenticated or active/injection testing categories are out of scope and listed as such rather than 'pass'), and routes the agent to http_security or ssl_check for depth. Also states it is suitable for domains you do not own because the technique is passive.

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