Dechonet MCP

OWASP Security Checkup

owasp_check

Read-onlyIdempotent

Assess a domain's externally observable OWASP posture: security headers, TLS, and version leaks. Get an A–F grade, with out-of-scope items explicitly flagged.

Instructions

Assess a domain's OWASP posture from EXTERNAL OBSERVATION only: the OWASP Secure Headers Project plus the externally observable Top 10 subset — A02 Cryptographic Failures (TLS/cert), A05 Security Misconfiguration (header/info leaks), and A06 Vulnerable & Outdated Components (version disclosure) — returning an A+ to F grade. IMPORTANT SCOPE: this does NOT check A01 (Access Control), A03 (Injection), A04, A07 (Authentication), A08, A09, or A10 (SSRF) — those require authenticated access or active/injection testing and are explicitly reported as out-of-scope, never as "pass". Do not present this as a full OWASP Top 10 assessment. Unlike security_scan this is fully PASSIVE (a normal HTTP GET plus a public CT-log lookup, no port scan), so it is safe and lawful to run on domains you do not own. 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
`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.

Addedv1.2.2Sep 22, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive, but the description adds substantial behavioral context: the tool is fully passive (HTTP GET plus public CT-log lookup, no port scan), rate-limited, requires no API key, and reports out-of-scope categories as out-of-scope rather than 'pass'. This significantly exceeds what the annotations alone convey.

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 long but every sentence serves a purpose: scope definition, explicit exclusions, passive-safety justification, alternatives, and return format. The key constraint ('EXTERNAL OBSERVATION only') is front-loaded, and the structure guides the agent from what it does to what it does not do to what to use instead.

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 the tool's complexity, the description is complete enough for an agent to call it correctly: it covers method, exclusions, safety/lawfulness, rate limits, API key requirements, alternatives, and return format. The presence of an output schema means return details don't need to be spelled out further, and the description already summarizes the report contents.

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?

The single parameter `host` is already fully documented in the schema (hostname without scheme, accepts host portion of a URL), so schema coverage is 100%. The description adds no extra parameter-level semantics beyond calling it a domain, so the baseline 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 (assess), resource (domain's OWASP posture), and method (external observation), and explicitly names the exact subset covered. It also differentiates itself from security_scan by describing the key difference (passive vs. active), so an agent can distinguish this from siblings 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?

The description gives clear when-to-use context: it is safe and lawful on domains not owned, and it is not a full OWASP Top 10 assessment. It also names alternatives explicitly ('Use http_security or ssl_check for depth on one layer') and warns against misusing the results, leaving no ambiguity about when this tool is appropriate.

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