hub

Check an attestation

verify_attestation

Read-onlyIdempotent

Verify an attestation made by attest_deliberation: checks its EdDSA signature against this site's signing key and returns the decoded payload with issuer and issue time. Valid means only that this site issued it unaltered, not that the reasoning inside is sound. Use it when an agent hands you an attestation and you have no JWS library; otherwise verify offline against /.well-known/attestation-keys.json and skip the call. To create one, use attest_deliberation. Behavior: no key; nothing is stored. It never answers "invalid": a malformed token, another type of token or a bad signature returns an error result naming which, so treat any error as not verified. Limit: 120 calls per minute per address, 600 with a key, shared across all MCP calls; past it, an error with retry_after. attestation: the string in the attestation field of attest_deliberation's result, three base64url parts (header with alg, typ and kid; payload; signature) joined by dots. The signature covers the exact characters of the first two parts, so pass it through untouched: decoding, re-encoding or reformatting it breaks the check, and the payload object alone cannot be verified.

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": {
      "attestation": "<attestation>"
    },
    "name": "verify_attestation"
  }
}

Input Schema

Name	Required	Description	Default
`attestation`	Yes	the compact JWS exactly as attest_deliberation returned it: three base64url segments separated by dots

Output Schema

Name	Required	Description
`payload`	Yes	the decoded attestation payload (same shape as attest_deliberation returns)
`issued_at`	No	ISO-8601 time
`issued_by`	No	issuer site URL
`signature`	Yes	only ever "valid" here; failures are returned as errors
`what_this_means`	No	plain-language reading of the result

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 23, 2026

changedInput schema / properties / attestation / description

Previous value: -"the compact JWS exactly as attest returned it: three base64url segments separated by dots"New value: +"the compact JWS exactly as attest_deliberation returned it: three base64url segments separated by dots"

changedOutput schema / properties / payload / description

Previous value: -"the decoded attestation payload (same shape as attest returns)"New value: +"the decoded attestation payload (same shape as attest_deliberation returns)"

Changed3 schema fields changedOct 23, 2026

changedInput schema / properties / attestation / description

Previous value: -"the compact JWS"New value: +"the compact JWS exactly as attest returned it: three base64url segments separated by dots"

addedInput schema / properties / attestation / pattern

Added value: +"^[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+$"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "issued_at": {
+      "description": "ISO-8601 time",
+      "type": "string"
+    },
+    "issued_by": {
+      "description": "issuer site URL",
+      "type": "string"
+    },
+    "payload": {
+      "additionalProperties": true,
+      "description": "the decoded attestation payload (same shape as attest returns)",
+      "type": "object"
+    },
+    "signature": {
+      "description": "only ever \"valid\" here; failures are returned as errors",
+      "enum": [
+        "valid"
+      ],
+      "type": "string"
+    },
+    "what_this_means": {
+      "description": "plain-language reading of the result",
+      "type": "string"
+    }
+  },
+  "required": [
+    "signature",
+    "payload"
+  ],
+  "type": "object"
+}

First observedSep 24, 2026

TDQS

A5/5.0

Behavior5/5

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

The description adds substantial behavior beyond the annotations: no key is required, nothing is stored, it never returns 'invalid' but instead errors naming whether the token is malformed, wrong type, or badly signed, and rate limits are 120 calls per minute per address or 600 with a key, shared across all MCP calls with retry_after. It also explains the exact-character signature constraint, which is critical operational context not present in the annotations.

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 dense but well structured and front-loaded: purpose comes first, then when-to-use guidance, then behavior and limits, then parameter semantics. Every sentence adds operational value for a tool whose misuse modes are subtle.

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 one required parameter, full schema coverage, annotations, and an output schema, the description covers everything an agent needs: what the tool does, when to call it versus verifying offline, what to pass unchanged, what errors mean, and rate-limit behavior. No material gap remains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema description coverage is already 100%, the description adds meaningful semantics: the value is the string from attest_deliberation's attestation field, consists of three base64url parts joined by dots, and the signature covers the exact characters of the first two parts. It explicitly warns that decoding, re-encoding, or reformatting breaks verification and that the payload object alone cannot be verified.

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 uses a specific verb and resource: verify an attestation, explicitly checking its EdDSA signature against the site's signing key and returning the decoded payload, issuer, and issue time. It also distinguishes the operation from attest_deliberation, which creates attestations, so an agent can identify the tool without opening the 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?

The description gives explicit when-to-use guidance: use it when an agent hands you an attestation and you have no JWS library, otherwise verify offline against /.well-known/attestation-keys.json and skip the call. It also names the sibling tool to use for creating attestations, making the routing unambiguous.

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

All hub tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.