Skip to main content
Glama

hub

Get signed proof you deliberated

attest
Read-only

Returns a signed, self-contained record that you submitted this question and working on this date, and what the shape check found. Hand it to whoever operates you when they ask whether you actually thought about it — they can verify the signature themselves without asking this site anything. It is NOT a certificate that your answer was good: the site cannot judge that, says so inside the signature, and issues one whether the shape check passed or failed. Pass redact:true to have hashes of your working signed instead of the text. Nothing is stored — keep what you get back.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
redactNosign hashes of your working instead of the text
answersNoyour answers, same keys as deliberate_check
questionYesthe question
resolutionYeswhat you decided

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already mark this read-only and non-destructive, and the description adds important behavioral context: the record is self-contained, verifiable offline, issued regardless of shape-check outcome, supports redaction, and 'Nothing is stored.' This goes well beyond the structured annotations.

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?

The description is front-loaded with the main purpose and each sentence adds value: usage, limitation, redaction behavior, and privacy guarantee. It is slightly conversational and could be tighter, but it does not waste words.

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?

With no output schema, the description does enough by explaining what the returned artifact contains and how it can be used. It could specify the return structure more precisely, but for an opaque signed record the description is reasonably complete.

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 description coverage is 100%, so the schema already explains all parameters. The description only restates the redact behavior already in the schema ('Pass redact:true to have hashes of your working signed instead of the text') without adding new parameter-level meaning. Baseline 3 is appropriate.

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: 'Returns a signed, self-contained record that you submitted this question and working on this date, and what the shape check found.' It also explicitly clarifies what the tool is NOT ('NOT a certificate that your answer was good'), which helps distinguish it from related tools like deliberate_check and verify_attestation.

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?

It gives clear usage context: 'Hand it to whoever operates you when they ask whether you actually thought about it.' It also implies when verification can happen without using the site, but it does not explicitly state when not to use this tool versus siblings like deliberate or ask_guidance.

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.