Skip to main content
Glama

Get signed proof of what a page said

attest_page
Read-only

Prove what a web page said, at a time, in a way someone who distrusts you can check.

Renders the page and returns a signed, timestamped record of it: the text and its SHA-256, the HTTP status, the response headers, the serving IP, and the TLS certificate the site presented. Optionally a screenshot and its hash. All of it hashed into one claim and signed, so any single altered byte breaks the signature.

Use it when a page might change or be denied later: terms of service before you agree, a price before you act on it, a policy you are relying on, a claim a competitor published, a listing that can be edited.

Verification is free, needs no account, and does not depend on this service continuing to exist — the math is public and verify_attestation explains how to redo it yourself. We keep no copy, so the response you receive IS the evidence. Store it.

$0.05 USDC per call over x402. A render that fails costs nothing.

When to use: You may later need to prove what a page said at a moment: terms, a price, a claim. Use instead: screenshot_page or read_page when you only need to see or read it. Parameters: url: absolute https URL. screenshot: true adds an image to the evidence (larger response), default false. Returns: a signed, timestamped attestation (text, hashes, status, headers, IP, TLS certificate). Keep it: no copy is stored.

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": {
      "url": "<url>"
    },
    "name": "attest_page"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesAbsolute https:// URL of the page to attest to. Anything a dispute could turn on: terms of service, a price, a published policy, a competitor's claim, a listing that may be edited later.
paymentNoBase64 x402 payment payload. Omit it to receive a quote instead of an attestation; sign that and call again.
screenshotNoDefault false in MCP. A screenshot makes the evidence much stronger, but the image comes back inline as roughly 55,000 characters of base64. With it false the attestation is text-only and internally complete: it claims no screenshot and commits to no hash you cannot check. Set true when the visual appearance is the thing in dispute and you can afford the bytes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A5/5.0
Behavior5/5

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

Beyond the `readOnlyHint`, the description provides deep operational transparency. It details the exact components contained in the attestation (SHA-256, IP, TLS certificate, etc.), mandates that the user must store the response (we keep no copy), and specifies the cost structure, all of which are critical for agent decision-making.

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, while long due to the tool's complexity, is perfectly structured. It starts with a clear value proposition, details the mechanism, provides usage guidance, discusses behavioral constraints, and finishes with practical details (cost, alternatives). Every paragraph serves a distinct, valuable purpose.

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 the complexity of generating legal/technical proof, the definition is exceptionally complete. It covers not only *how* to call it, but also *why* it is necessary, *what* the output entails, and *what* the cost is, making it fully self-contained for the agent.

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 the schema is 100% covered, the description significantly enhances semantic understanding. For `screenshot`, it provides a critical warning about the output size consequence (55,000 characters of base64), allowing the agent to make an informed cost/utility tradeoff based on the parameter value.

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 clearly defines the tool's purpose as generating a signed, verifiable proof of a page's content at a specific moment. It achieves maximum clarity by explicitly directing the agent to use alternatives like `read_page` or `screenshot_page` when proof is not required, distinguishing it sharply from sibling tools.

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 tool provides multiple explicit use cases (ToS, price, claim) and clear behavioral triggers for its use. Furthermore, it explicitly tells the agent when *not* to use it (i.e., when simple reading or viewing suffices), which is extremely valuable 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.