Dechonet MCP

Email Header Analysis

email_header_analysis

Read-onlyIdempotent

Analyze raw email headers to reconstruct delivery hops, check SPF/DKIM/DMARC results, measure delays, and flag non-TLS hops—diagnose spoofing, delays, or mail loss in delivered messages.

Instructions

Parse raw email headers to reconstruct the delivery path (each Received hop in order), extract SPF/DKIM/DMARC authentication results, measure per-hop delays, and flag unencrypted (non-TLS) hops. Use this to diagnose a specific message that was already delivered — spoofing, delays, or where mail was lost. Use email_auth instead to assess a domain's sending configuration before sending. Read-only; requires no API key; rate-limited. INPUT is the full raw header block. OUTPUT is a text report containing: the ordered hop route, per-mechanism auth results (pass/fail), detected inter-hop delays, the encryption status of each hop, and whether the first sending address is on the Tor Project exit list or in a VPN provider range (information only).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "headers": "<headers>"
    },
    "name": "email_header_analysis"
  }
}

Input Schema

Name	Required	Description	Default
`headers`	Yes	The complete raw email header block, copied verbatim — every line from the first 'Received:'/'From:' down to the blank line before the body. Paste as-is, including folded continuation lines; do not include the message body.

Output Schema

Name	Required	Description
`kpis`	No	Key metrics as label/value pairs
`grade`	No	Letter grade (A+ to F) when the tool grades the target
`score`	No	0-100 score when the tool scores the target
`issues`	No	Detected problems, severity-rated
`status`	Yes	Overall verdict, e.g. 'good' \| 'warning' \| 'bad' \| 'info' \| 'unknown'
`actions`	No	Recommended next actions, most important first
`summary`	No	One-paragraph interpretation of the result
`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 for this exact lookup on dechonet.com
`observation`	No	How 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.

Changed2 schema fields changedv1.5.14Oct 15, 2026

addedOutput schema / properties / observation

Added value: +{
+  "additionalProperties": false,
+  "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"
+    }
+  },
+  "required": [
+    "state",
+    "observedAt",
+    "cached",
+    "ageMinutes"
+  ],
+  "type": "object"
+}

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"
+}

Changed1 schema field changedv1.1.0Sep 8, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "actions": {
+      "description": "Recommended next actions, most important first",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "grade": {
+      "description": "Letter grade (A+ to F) when the tool grades the target",
+      "type": "string"
+    },
+    "issues": {
+      "description": "Detected problems, severity-rated",
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "key": {
+            "type": "string"
+          },
+          "severity": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "severity",
+          "key"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "kpis": {
+      "description": "Key metrics as label/value pairs",
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "label": {
+            "type": "string"
+          },
+          "value": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "label",
+          "value"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "reportUrl": {
+      "description": "Human-facing interactive report for this exact lookup on dechonet.com",
+      "type": "string"
+    },
+    "score": {
+      "description": "0-100 score when the tool scores the target",
+      "type": "number"
+    },
+    "status": {
+      "description": "Overall verdict, e.g. 'good' | 'warning' | 'bad' | 'info' | 'unknown'",
+      "type": "string"
+    },
+    "summary": {
+      "description": "One-paragraph interpretation of the result",
+      "type": "string"
+    }
+  },
+  "required": [
+    "status",
+    "reportUrl"
+  ],
+  "type": "object"
+}

Changed1 schema field changedv1.0.3Jun 17, 2026

changedInput schema / properties / headers / description

Previous value: -"Raw email headers to analyze (paste the full header text)"New value: +"The complete raw email header block, copied verbatim — every line from the first 'Received:'/'From:' down to the blank line before the body. Paste as-is, including folded continuation lines; do not include the message body."

First observedv0.1.0Jun 17, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, and the description still adds real context: no API key required, rate-limited, and that the Tor/VPN detection is 'information only'. It does not contradict anything, though it could say more about report size or failure modes on malformed headers.

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 core action and its transformations, then routing, then constraints, then I/O. Dense but readable; the enumerated OUTPUT list runs slightly long given an output schema already exists.

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

Completeness4/5

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

Covers input shape, transformations, routing to the sibling, and safety/rate context, which is everything needed to invoke it. The detailed OUTPUT recount partially duplicates the output schema, so completeness is high but with some redundancy.

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 parameter is fully documented in the schema, including folded continuation lines and body exclusion. The description's 'INPUT is the full raw header block' essentially restates the schema, so 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?

Opens with a specific verb+resource ('Parse raw email headers') and enumerates the exact outputs (delivery path, SPF/DKIM/DMARC, per-hop delays, TLS status). It explicitly distinguishes itself from the sibling email_auth, so an agent can route correctly without opening either 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 a concrete when-to-use ('diagnose a specific message that was already delivered — spoofing, delays, or where mail was lost') and names the alternative with its condition ('use email_auth instead to assess a domain's sending configuration before sending'). This is explicit routing guidance.

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