Skip to main content
Glama

Get signed proof you deliberated

attest_deliberation
Read-onlyIdempotent

Sign a record that you deliberated: a compact JWS (EdDSA; header typ spk-attestation+jwt with a kid) whose payload holds your question, answers and resolution (or their SHA-256 hashes), the issue time and the result of the same shape check as check_deliberation. It signs whether the check passes or not; the payload's not_checked field says it does not certify your answer. Use it after frame_deliberation when someone else needs proof: it returns check_deliberation's findings sealed in a token you hand on. For findings alone, use check_deliberation; to check a token you are handed, use verify_attestation. Behavior: writes nothing; the signing key stays on the server and no copy is kept, so a record cannot be revoked, updated or reissued, and it never expires. Anyone can verify it offline with the public key at /.well-known/attestation-keys.json (match the kid). No key needed. Limit: 120 calls per minute per address, 600 with a key, shared across all MCP calls; past it, an error with retry_after. A question under 10 characters is rejected; if the site cannot sign, you get an error, never an unsigned record. Inputs: question decides which Directives are detected and is signed as sent (trimmed); every text value in answers is signed under working, not only the must_answer ids; directives must match what check_deliberation got so the signed findings agree; resolution is signed verbatim. redact=true swaps the question, each answer and the resolution for sha256: of the trimmed text, so the text stays with you and whoever holds it can prove a match.

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": {
      "question": "<question>",
      "resolution": "<resolution>"
    },
    "name": "attest_deliberation"
  }
}

Input Schema

NameRequiredDescriptionDefault
redactNofalse (default): the record carries your question, answers and resolution in clear; true: it carries SHA-256 hashes of them instead, so the text stays with you and a reader can only confirm a match
answersNoyour answers keyed by the must_answer ids from frame_deliberation (tension, cost, falsifier, human_knowledge, directive-N); these are what gets signed, or hashed when redact=true
questionYesthe question you deliberated, same text as before
directivesNooptional: the same directives you passed to check_deliberation, if any, so the signed check covers the same Directives
resolutionYeswhat you decided, one or two sentences; signed verbatim

Output Schema

NameRequiredDescriptionDefault
noteNokeep it: the site stored nothing
storedNoalways false
payloadYes
attestationYesthe record as a compact JWS: three base64url segments separated by dots; this is what you keep and hand on
verify_withNoURL of the public keys

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only say read-only/idempotent; the description adds substantial behavior: nothing is persisted, the key stays server-side, records can't be revoked, updated or reissued and never expire, offline verification via /.well-known/attestation-keys.json, rate limits (120/min, 600 with key, error with retry_after), and a guaranteed failure mode (error rather than unsigned record). It also discloses that signing occurs even when the check fails, with not_checked indicating no certification of the answer.

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 definition, then explicitly labeled 'Behavior:' and 'Inputs:' blocks, so it is easy to scan despite its length. A few clauses restate the redact parameter already documented in the schema, which keeps it from being maximally tight.

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 signing tool with an output schema, this covers everything an agent needs: what gets sealed, what is and isn't certified, verification path and key matching, quotas, and failure behavior. The only small inconsistency is the 10-character rejection versus schema minLength 1, but the description surfaces the stricter runtime rule rather than hiding it.

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?

Schema coverage is 100% (baseline 3), but the description adds real semantics beyond it: question is trimmed and drives Directive detection, every text value in answers is signed under working and not just must_answer ids, resolution is signed verbatim, and redact substitutes sha256:<hex> of the trimmed text. These are behavioral consequences the JSON Schema cannot express.

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 artifact: it signs a compact JWS (EdDSA, typ spk-attestation+jwt with kid) whose payload holds the question, answers, resolution, issue time and the check result. It explicitly separates itself from check_deliberation (findings alone) and verify_attestation (checking a handed token), so an agent can route without opening a 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 the triggering condition — use after frame_deliberation when someone else needs proof — and names both alternatives with the condition that selects each. It also states prerequisites (directives must match what check_deliberation got) and the 10-character minimum question.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.