Skip to main content
Glama

invinoveritas

by com.babyblueviper
OverviewDiscussionsAdmin

verify_proof

Read-onlyIdempotent

Checks a signed invinoveritas proof without trusting whoever handed it over: recomputes the event id, checks the Schnorr signature, and confirms the signing key is invinoveritas's published key. Optionally pass expect_artifact_hash (sha256 of the content you received) to confirm the proof covers that exact content. Accepts the full event, or an event_id to look up. Returns {valid, checks, proof_payload}. Free, no sign-in. Docs: https://api.babyblueviper.com/verify

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
eventNoThe signed proof event {id,pubkey,created_at,kind,tags,content,sig} the counterparty handed you (from a /prove or /review sign=true response).
event_idNoAlternatively, the Nostr event id alone (from a /review sign=true, /prove, or /witness proof) — fetches the durably-stored full event, independent of relay retention, and verifies it.
proof_idNoAlternatively, a stored attestation proof_id to fetch + verify.
verifier_signatureNoOptional (added 2026-08-16) — an EIP-191 personal_sign signature over 'invinoveritas-verify-proof:<event_id>', signed by the key controlling the address in expect_intended_verifier (eip155 CAIP-10 namespace only). Cryptographically PROVES presenter identity rather than just asserting it — sets checks.intended_verifier_authenticated.
expect_artifact_hashNoOptional sha256 hex of the output you received — asserts the proof is ABOUT that exact artifact.
expect_intended_verifierNoOptional (added 2026-08-16) — asserts the proof's declared intended_verifier matches you, the consumption-identity check alongside expect_artifact_hash's content-identity check. A match confirms the issuer's declared intent, not that delivery was actually restricted to you.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / expect_intended_verifier
      Added value: +{
+  "description": "Optional (added 2026-08-16) — asserts the proof's declared intended_verifier matches you, the consumption-identity check alongside expect_artifact_hash's content-identity check. A match confirms the issuer's declared intent, not that delivery was actually restricted to you.",
+  "type": "string"
+}
    • addedInput schema / properties / verifier_signature
      Added value: +{
+  "description": "Optional (added 2026-08-16) — an EIP-191 personal_sign signature over 'invinoveritas-verify-proof:<event_id>', signed by the key controlling the address in expect_intended_verifier (eip155 CAIP-10 namespace only). Cryptographically PROVES presenter identity rather than just asserting it — sets checks.intended_verifier_authenticated.",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / event_id
      Added value: +{
+  "description": "Alternatively, the Nostr event id alone (from a /review sign=true, /prove, or /witness proof) — fetches the durably-stored full event, independent of relay retention, and verifies it.",
+  "type": "string"
+}
  3. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already establish read-only, idempotent, and non-destructive behavior, so the description only needs to add context beyond that. It adds useful behavioral detail: verification is done without trusting the presenter, the tool fetches durably-stored events when given an id, and it is free with no sign-in. No contradiction with 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 compact yet information-dense, starting with the core verification behavior, then optional parameters, accepted inputs, return shape, and access requirements. Every sentence earns its place and the docs link is a useful fallback without padding.

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?

For a read-only verification tool with a rich input schema, the description covers the purpose, inputs, return shape, and cost. It does not detail the structure of the checks field or error behavior, but the return shape {valid, checks, proof_payload} plus the docs link provides adequate grounding without an output schema.

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 documents all six parameters thoroughly. The description adds a small amount of semantic context by explaining that expect_artifact_hash confirms the proof covers the received content and by summarizing the two main input modes, but it does not significantly go beyond the schema.

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 opens with a specific verb and resource — 'Checks a signed invinoveritas proof' — and then enumerates the exact verification steps: recomputing the event id, checking the Schnorr signature, and confirming the signing key. This clearly distinguishes verify_proof from siblings like witness or validate by describing what makes this tool unique.

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 provides clear input alternatives ('Accepts the full event, or an event_id to look up') and explains when to use the optional expect_artifact_hash parameter to confirm content coverage. It does not explicitly name sibling tools or state when not to use it, but the usage context is strongly implied by the precise verification description.

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

All invinoveritas toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources