Whisper

Verify a Whisper agent identity

whisper_verify

Read-only

Is this IPv6 address or hostname a real Whisper agent, and whose? Grades the full keyless trust chain: the reverse DNS record, the forward AAAA confirming it back to the same address, and the DANE-EE certificate pin published in DNSSEC-signed DNS. Returns is_whisper_agent with the evidence for the verdict either way, so a negative answer is an answer and not an error. Answers without an API key, and every leg of it is independently checkable from the DNS root with dig. Example call: {"skill":"verify","input":"2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478"}

Input Schema

TableJSON Schema

Name	Required	Description	Default
`input`	Yes	The indicator to look up: a domain, an IP address, an ASN or a file hash. The example passes 2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478.

Output Schema

TableJSON Schema

Name	Required	Description
`fqdn`	No	The agent's canonical hostname, forward-confirmed against the address. Positive verdicts only.
`detail`	No	A sentence explaining a negative verdict. Absent on a positive one.
`jws_ok`	No	Whether a verifiable signed identity document can be produced for this agent.
`tenant`	No	The tenant handle, which also appears inside the fqdn.
`dane_ok`	No	Whether the certificate this address actually serves satisfies the DANE-EE pin published for it in DNSSEC-signed DNS. This is the leg that cannot be forged without the zone.
`evidence`	Yes	What was checked and what was found: the address or fqdn as given, the PTR, and the forward record that did or did not confirm it.
`operator`	No	The opaque handle of the account that owns this agent.
`verified_at`	No	When this verdict was graded, ISO 8601.
`is_whisper_agent`	Yes	The verdict. False is an ANSWER, not a failure: the address or name is simply not a Whisper agent, and the evidence says which leg of the chain is missing.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 25, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "description": "Whether an address or hostname is a Whisper agent, with the evidence for the verdict either way. Every leg is independently checkable from the DNS root with dig.",
+  "properties": {
+    "dane_ok": {
+      "description": "Whether the certificate this address actually serves satisfies the DANE-EE pin published for it in DNSSEC-signed DNS. This is the leg that cannot be forged without the zone.",
+      "type": "boolean"
+    },
+    "detail": {
+      "description": "A sentence explaining a negative verdict. Absent on a positive one.",
+      "type": "string"
+    },
+    "evidence": {
+      "description": "What was checked and what was found: the address or fqdn as given, the PTR, and the forward record that did or did not confirm it.",
+      "type": "object"
+    },
+    "fqdn": {
+      "description": "The agent's canonical hostname, forward-confirmed against the address. Positive verdicts only.",
+      "type": "string"
+    },
+    "is_whisper_agent": {
+      "description": "The verdict. False is an ANSWER, not a failure: the address or name is simply not a Whisper agent, and the evidence says which leg of the chain is missing.",
+      "type": "boolean"
+    },
+    "jws_ok": {
+      "description": "Whether a verifiable signed identity document can be produced for this agent.",
+      "type": "boolean"
+    },
+    "operator": {
+      "description": "The opaque handle of the account that owns this agent.",
+      "type": "string"
+    },
+    "tenant": {
+      "description": "The tenant handle, which also appears inside the fqdn.",
+      "type": "string"
+    },
+    "verified_at": {
+      "description": "When this verdict was graded, ISO 8601.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "is_whisper_agent",
+    "evidence"
+  ],
+  "type": "object"
+}

AddedSep 25, 2026
RemovedSep 25, 2026
AddedSep 25, 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=true and destructiveHint=false, but the description adds substantial behavioral detail beyond that: it explains the full trust-chain verification steps, states that a negative result returns is_whisper_agent with evidence rather than an error, and notes that no API key is required. This gives the agent a strong model of the tool's actual behavior.

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 front-loaded with the core question, then adds method, return semantics, auth requirements, and an example—each sentence earns its place. The example call is compact and immediately actionable. It is longer than two sentences, but nothing feels redundant or ornamental.

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?

For a verification tool with an output schema and read-only annotations, the description is complete: it defines the input scope, the verification method, the output flag, the treatment of negative results, and the lack of an API key requirement. An agent has enough context to call this tool correctly without needing to open the output schema.

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?

The schema already describes the input string as a broad 'domain, IP address, ASN or file hash', so baseline is 3. The description adds value by narrowing the practical input to IPv6 addresses or hostnames and by providing a concrete example call with a full IPv6 address. There is slight tension with the schema's broader indicator list, but the description still materially clarifies the parameter.

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 leads with a specific question—'Is this IPv6 address or hostname a real Whisper agent, and whose?'—which names the verb, resource, and scope. It then details a concrete method (reverse DNS, forward AAAA, DANE-EE pin) that clearly distinguishes this from the sibling tools like whisper_rdap or whisper_lookupTlsFingerprint.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for when to use the tool: to determine whether an IPv6 address or hostname is a real Whisper agent and to attribute it. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5, but the intended scenario is unmistakable.

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

All Whisper tools Inspect

Try in Browser

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.