Skip to main content
Glama
Sign In

Provian

by ai.provian
OverviewDiscussionsAdmin

verify_presentation

REQUESTER step 2: verify a presentation a counterparty produced against the challenge you issued — pass the SAME challenge_envelope you handed out (it carries audience, challenge, predicates, the addressed presenter and the deadline), or the legacy audience + challenge (+ predicates). Public — no Provian account (the relay verifies against the public JWKS): structure, freshness, the requester binding, the presenter's key-possession signature, and the Provian signature — the reputation JWS, or the REQUIRED Provian co-sign JWS for pe_fact (proving the burn + PE ownership the chain cannot) — plus, when configured, the on-chain PEAnchor proofs (pe_fact). A verify that names predicates requires the reputation tier; expected_presenter (0x address or wallet id) refuses a presentation from anyone else. Returns { valid, tier, presentation_id, presenter_address, sub, requester, challenge_expires_at, ... } — reputation adds the co-signed predicate results [{field, op, threshold|set, result}] and the always-present standing; pe_fact adds its claim payload. { valid: false, reason } on refusal. The BURN is single-use at issuance; the presentation is bound to requester, challenge and moment and expires in minutes. ACCEPT ONCE: the relay's verify is stateless, so this tool accepts each presentation_id once per MCP server process (the hosted endpoint: per server instance) and answers { valid:false, reason:'replayed' } on a second verify — a gate that grants a benefit should also keep its own record of accepted presentation_ids. accept_once:false turns this off.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "verify_presentation"
  }
}

Input Schema

NameRequiredDescriptionDefault
tokenNoThe opaque presentation token the presenter returned (base64url).
audienceNoLegacy: the EXACT audience you issued.
challengeNoLegacy: the EXACT challenge you issued.
predicatesNoLegacy: the EXACT predicates you issued (each must be answered; reputation tier only).
accept_onceNoDefault true: a second verify of the same presentation_id in this process answers replayed.
disclosuresNoLegacy: the EXACT disclosure requests you issued (each must be answered — disclosed or declined; reputation tier only). The result carries `disclosures`: each answer with its election and its relay-checked records.
presentationNoAlternatively, the structured presentation object.
challenge_envelopeNoThe EXACT challenge envelope you issued with present_challenge (object or JSON string). Preferred: it carries every expectation.
expected_presenterNoOptional: the presenter you expect (0x address or wallet id). Derived from a challenge_envelope that names a presenter.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: public/no-account operation via relay-verified public JWKS, the exact checks performed (structure, freshness, requester binding, key-possession signature, Provian signature, required co-sign for pe_fact, optional PEAnchor proofs), tier requirements for predicates, and enforcement of expected_presenter. It also discloses the stateful accept-once gate, its process-scoped lifetime, the 'replayed' refusal, and the single-use burn — behavior an agent could not infer from the signature alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The key routing information is front-loaded, and nearly every clause carries real content, but the definition is delivered as one dense paragraph of em-dash-delimited clauses covering verification internals, return shapes, and replay semantics. Splitting the return/refusal and accept-once material into separate sentences or lines would preserve the value while making it far easier to scan.

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 9-parameter tool with nested objects, mutually exclusive parameter paths, and no output schema, the description supplies everything needed: two valid invocation modes, tier prerequisites, the success payload shape ({ valid, tier, presentation_id, presenter_address, sub, requester, challenge_expires_at }), the refusal shape ({ valid:false, reason }), and the replay case. Nothing material is left to inference.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds genuine meaning: it identifies challenge_envelope as the preferred carrier of all expectations, marks audience/challenge/predicates/disclosures as legacy, states that predicates and disclosures require the reputation tier, and explains that accept_once defaults to true and what disabling it does. expected_presenter's refusal semantics are also spelled out beyond the schema's 'Optional' text.

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 resource ('verify a presentation') plus its position in the flow ('REQUESTER step 2 ... against the challenge you issued'). That framing cleanly separates it from present_challenge (issuance), answer_challenge/present (presenter side) and check_challenge, so an agent can pick it without inspecting 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operative context: use the SAME challenge_envelope you issued, with the legacy audience + challenge + predicates path as fallback, and marks the envelope as 'Preferred'. What's missing is an explicit exclusion or named sibling ('if you have not yet issued a challenge, call present_challenge first', or 'do not use check_challenge for this'), so it falls short of a 5.

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

All Provian 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