Dechonet MCP

OWASP Security Checkup

owasp_check

Read-onlyIdempotent

Assess a domain's external OWASP posture to get an A+ to F grade for secure headers, TLS, misconfigurations, and outdated components.

Instructions

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

TableJSON Schema

Name	Required	Description	Default
`host`	Yes	Hostname to assess, without scheme (e.g., 'example.com'). The host portion of a pasted URL is also accepted.

Output Schema

TableJSON Schema

Name	Required	Description
`grade`	Yes	OWASP posture grade A+ to F, over the observable categories only
`score`	Yes	0-100 across the categories that could be evaluated
`checks`	Yes	Per observable category: Secure Headers, A02, A05, A06
`receipts`	No	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.
`reportUrl`	Yes	Human-facing interactive report on dechonet.com
`notObservable`	No	Top 10 categories NOT checked (need authenticated/active testing)

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.5.14Oct 15, 2026

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": {
+    "additionalProperties": false,
+    "properties": {
+      "id": {
+        "type": "string"
+      },
+      "tool": {
+        "type": "string"
+      },
+      "url": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "tool",
+      "id",
+      "url"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

Addedv1.2.2Sep 22, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered; the description still adds substantive context beyond them — the check is PASSIVE (normal HTTPS request, TLS cert, CT-log lookup, no port scan/path probing), the sensitive-file check never runs through this tool, and it is rate-limited with no API key. Strong disclosure, though the rate-limit specifics are qualitative rather than quantified.

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 scope and safety before details, and most sentences carry distinct information. Slight redundancy: 'The result is an external-posture check, not a full OWASP Top 10 assessment' restates the scope already established by the category enumeration.

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?

An output schema exists, yet the description still usefully characterizes the return (grade, per-category findings, out-of-scope list, shareable link). Combined with the scope, passivity, and alternative guidance, an agent has everything needed to select and call it correctly.

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?

Only one parameter with 100% schema coverage, and the schema already documents the no-scheme format and the pasted-URL acceptance. The description adds no parameter syntax beyond that, but with a single fully documented parameter the baseline is high.

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 ('Assess a domain's OWASP posture') and immediately bounds it ('from EXTERNAL OBSERVATION only'). It names the exact categories checked (A02, A03, A04) and explicitly names the sibling tools (http_security, ssl_check) it is not, so an agent can route without opening schemas.

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?

Explicit when-to-use (external posture, domains you do not own), when-not (A01/A05/A06/A07/A08/A09/A10 are out of scope), and named alternatives for depth on a single layer. Nothing is left to inference.

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