Skip to main content
Glama

Wever Labs Agent Products

by io.github.CodeWever
OverviewDiscussionsAdmin

Proof Inbox

wever_proof-inbox
Destructive

Paid URL: 0.10 USDC per call on Base; 10 signed-wallet free calls shared over rolling 30 days. Read the backend 402 body for x402 terms. Store, list and retrieve durable verification proofs in a private authenticated wallet inbox. Operating boundary: Store, list and retrieve durable verification proofs in a private authenticated wallet inbox. Fresh signed wallet proof is required even for paid calls. Handoff permissions require recipient enforcement. Stored evidence is not automatically verified. Scores are bounded evidence summaries, not global reputation. POST /api/proof-inbox. Existing product credentials, signed mandates, and single-use action grants remain required where applicable. This adapter grants no authority and never supplies server credentials. Wallet-authenticated durable trust service. Signed records attest only to the stated evidence and permission scope. See /api/trust-contract for the public verification key and bounded contract.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeYes
limitNo
proofNo
offsetNo
proof_idNo
idempotency_keyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed15 schema fields changed
    • changedInput schema / additionalProperties
      Previous value: -trueNew value: +false
    • removedInput schema / description
      Removed value: -"The existing product POST body. Supply its documented mode, arguments, and required signed authority or grant. The product validates its full contract."
    • removedInput schema / maxProperties
      Removed value: -64
    • removedInput schema / minProperties
      Removed value: -1
    • addedInput schema / oneOf
      Added value: +[
+  {
+    "additionalProperties": false,
+    "properties": {
+      "idempotency_key": {
+        "pattern": "^[a-zA-Z0-9_-]{1,96}(?![\\s\\S])",
+        "type": "string"
+      },
+      "mode": {
+        "const": "store"
+      },
+      "proof": {
+        "additionalProperties": false,
+        "properties": {
+          "content": {
+            "maxLength": 24000,
+            "minLength": 1,
+            "type": "string"
+          },
+          "kind": {
+            "enum": [
+              "receipt_passport",
+              "handoff_pack",
+              "evidence"
+            ]
+          },
+          "label": {
+            "maxLength": 160,
+            "minLength": 1,
+            "type": "string"
+          }
+        },
+        "required": [
+          "kind",
+          "content",
+          "label"
+        ],
+        "type": "object"
+      }
+    },
+    "required": [
+      "mode",
+      "idempotency_key",
+      "proof"
+    ],
+    "type": "object"
+  },
+  {
+    "additionalProperties": false,
+    "properties": {
+      "limit": {
+        "maximum": 25,
+        "minimum": 1,
+        "type": "integer"
+      },
+      "mode": {
+        "const": "list"
+      },
+      "offset": {
+        "maximum": 255,
+        "minimum": 0,
+        "type": "integer"
+      }
+    },
+    "required": [
+      "mode",
+      "offset",
+      "limit"
+    ],
+    "type": "object"
+  },
+  {
+    "additionalProperties": false,
+    "properties": {
+      "mode": {
+        "const": "retrieve"
+      },
+      "proof_id": {
+        "pattern": "^[a-f0-9]{64}(?![\\s\\S])",
+        "type": "string"
+      }
+    },
+    "required": [
+      "mode",
+      "proof_id"
+    ],
+    "type": "object"
+  }
+]
    • addedInput schema / properties / idempotency_key
      Added value: +{
+  "pattern": "^[a-zA-Z0-9_-]{1,96}(?![\\s\\S])",
+  "type": "string"
+}
    • addedInput schema / properties / limit
      Added value: +{
+  "maximum": 25,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / mode / enum
      Added value: +[
+  "store",
+  "list",
+  "retrieve"
+]
    • removedInput schema / properties / mode / maxLength
      Removed value: -128
    • removedInput schema / properties / mode / minLength
      Removed value: -1
    • removedInput schema / properties / mode / type
      Removed value: -"string"
    • addedInput schema / properties / offset
      Added value: +{
+  "maximum": 255,
+  "minimum": 0,
+  "type": "integer"
+}
    • addedInput schema / properties / proof
      Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "content": {
+      "maxLength": 24000,
+      "minLength": 1,
+      "type": "string"
+    },
+    "kind": {
+      "enum": [
+        "receipt_passport",
+        "handoff_pack",
+        "evidence"
+      ]
+    },
+    "label": {
+      "maxLength": 160,
+      "minLength": 1,
+      "type": "string"
+    }
+  },
+  "required": [
+    "kind",
+    "content",
+    "label"
+  ],
+  "type": "object"
+}
    • addedInput schema / properties / proof_id
      Added value: +{
+  "pattern": "^[a-f0-9]{64}(?![\\s\\S])",
+  "type": "string"
+}
    • addedInput schema / required
      Added value: +[
+  "mode"
+]
  2. First observed

TDQS

C2.9/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, openWorldHint=true, and idempotentHint=false, so the safety profile is partly covered. The description adds genuinely non-structured behavior: cost (0.10 USDC per call on Base, 10 free calls/30 days), a mandatory fresh signed wallet proof even for paid calls, recipient enforcement for handoffs, and the caveat that stored evidence is not auto-verified. These are useful operational facts not derivable from annotations.

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

Conciseness2/5

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

The text is a dense block of pricing, legal boilerplate, and repeating boundary statements ('Store, list and retrieve durable verification proofs in a private authenticated wallet inbox' appears twice). It is not front-loaded on the action; pricing leads. Much of the content is disclaimer filler that does not help invocation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex multi-mode tool with 6 parameters, nested proof objects, 0% schema coverage, and no output schema, the description leaves core mechanics unexplained: what each mode returns, pagination behavior, idempotency semantics, and how a proof_id is obtained. It covers cost/auth caveats but not enough for an agent to call all three modes correctly.

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

Parameters2/5

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

Schema description coverage is 0% across 6 parameters with nested objects and enums, so the description carries the full explanatory burden and largely fails it. It loosely maps 'store, list and retrieve' onto the mode enum, but says nothing about idempotency_key, offset/limit pagination, proof_id format, or the kind/content/label fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb set and resource: 'Store, list and retrieve durable verification proofs in a private authenticated wallet inbox.' That is concrete and matches the three schema modes. It does not differentiate itself from siblings like proof-relay or receipt-passport, which share the proofs domain, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus proof-relay, receipt-passport, or agent-handoff-pack, all of which touch similar proof/handoff artifacts. The pricing line and the repeated 'operating boundary' sentence describe what the service is, not when an agent should select it over an alternative.

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

All Wever Labs Agent Products 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