Dechonet-MCP

Verify Outside Expectations Now

verify_expectations

Idempotent

Check expectations from outside now, with fresh reads: either a stored set by id (from set_expectations — its state is updated and an anonymous set is kept another 30 days), or a domain plus a list of checks once, storing nothing. Same checks and outcomes as set_expectations (pass / fail / unknown, unknown is never a pass), each tool read once with a signed observation receipt. Typical use: right after a change, to see whether it is visible from outside yet — DNS and CDN changes can take minutes to hours to show. Rate-limited (a few checks per minute).

Input Schema

Name	Required	Description
`id`	No	Stored set id ('ex_…') to re-check
`domain`	No	Domain to check once (with expect), when there is no stored set
`expect`	No	Checks for a one-off verify, 1-20

Output Schema

Name	Required	Description
`id`	No	Expectation set id (stored sets)
`url`	No	Status page of the set: last results and recent checks
`owner`	No	'account' (alerts by the API key account's daily mail) or 'anonymous' (no alerts)
`state`	Yes	'pass' (every check holds) \| 'fail' (at least one does not) \| 'unknown' (some could not be read — not a pass)
`domain`	Yes
`stored`	Yes	Whether DechoNet keeps re-checking this set daily
`results`	Yes
`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.
`checkedAt`	No
`expiresAt`	No	Anonymous sets: removed after this unless checked again

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 15, 2026

addedOutput schema / properties / results / items / properties / fix

Added value: +{
+  "description": "Where to fix a check that does not hold, for the platform the site runs on (Cloudflare, Vercel, Netlify, nginx, Apache) or its DNS host",
+  "properties": {
+    "doc": {
+      "type": "string"
+    },
+    "note": {
+      "type": "string"
+    },
+    "platform": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "snippet": {
+      "type": "string"
+    },
+    "where": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "where"
+  ],
+  "type": "object"
+}

AddedOct 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare the safety profile (readOnlyHint=false, idempotent, openWorld, non-destructive); the description adds substantial context beyond them: the stored set's state is updated and an anonymous set is retained 30 days, the domain mode stores nothing, outcomes are pass/fail/unknown with unknown never treated as a pass, each read yields a signed observation receipt, and the tool is rate-limited to a few checks per minute.

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 the two modes, and every clause carries information (retention, outcomes, rate limit). It is dense with parentheticals in a single long first sentence, which costs a little readability but not correctness.

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, so return values need no prose. Combined with annotations and a fully described input schema, the description supplies everything else an agent needs: mode selection, storage side effects, outcome vocabulary, freshness expectations, and rate limits.

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?

Schema coverage is 100%, so the schema already documents every field including the nested check kinds, establishing a baseline of 3. The description adds meaning the schema does not state: that 'id' and 'domain'+'expect' are mutually exclusive modes and that only the id mode persists state. It does not restate the per-check semantics, which is fine since the schema carries them.

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 ('Check expectations from outside now, with fresh reads') and immediately enumerates the two modes: re-check a stored set by id, or run a one-off domain+checks pass. It names the sibling it complements (set_expectations) and makes clear this tool observes rather than stores.

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 an explicit when-to-use ('right after a change, to see whether it is visible from outside yet — DNS and CDN changes can take minutes to hours to show') and routes between the two input modes ('when there is no stored set'), referencing set_expectations as the counterpart. An agent can pick the right mode without inference.

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

All Dechonet-MCP tools Inspect

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

Need Help?