Skip to main content
Glama

Agent Verification Utility

by dev.kgninja.agent-economy
OverviewDiscussionsAdmin

Server Details

Deterministic JSON checks with signed evidence and x402-paid execution

Ownership verified
Status
Healthy
Uptime
100.0% over 55 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.3/5.0

Scored across 5 tools

Disambiguation4/5

The tools have distinct purposes: describe provides information, get_revenue_goal_status reads a goal, prepare and quote both involve precheck after payment, and verify_evidence runs checks. However, quote_verify_evidence and prepare_verify_evidence_purchase are nearly identical in steps and outputs, differing only in final artifact (quote vs HTTP request), which could confuse agents. Descriptions help clarify the difference but overlap remains.

Naming Consistency4/5

Names follow a verb_noun pattern (describe_verify_evidence, get_revenue_goal_status, prepare_verify_evidence_purchase, quote_verify_evidence). One slight deviation is get_revenue_goal_status which uses get_ + noun phrase, but it's still consistent with snake_case. Overall, naming is predictable and consistent.

Tool Count5/5

Five tools are well-scoped for an agent verification utility: one describes the service, one reads revenue status, two prepare for a paid verification (quote and prep), and one executes verification. This covers the lifecycle without redundancy or bloat.

Completeness5/5

The tool surface covers the full lifecycle: information (describe), free precheck (implied via quote/prepare), quoting, purchase preparation, and final paid verification. There is no obvious missing operation for the stated purpose of deterministic evidence verification with payment.

Available Tools

5 tools
describe_verify_evidenceDescribe Agent Verification UtilityA
Read-onlyIdempotent
Inspect

Describe when deterministic verification is useful, when it is not, free request validation, recipes, limits, and the explicit paid MCP path.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, and the description adds topical context (free request validation, recipes, limits, paid MCP path) that clarifies what the tool exposes. It does not contradict annotations, though it does not detail additional behavior like return format or whether any computation occurs.

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 a single sentence, front-loaded with the verb 'Describe' and efficiently lists all covered topics in a comma-separated list. There is no wasted verbiage or repetition.

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 zero-parameter, read-only informational tool with no output schema, the description adequately covers the essential context: when verification is or isn't useful, validation, recipes, limits, and the premium paid path. The sibling tools provide operational context, and this description stands alone as complete.

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?

The input schema has zero parameters, so a baseline of 4 applies. The description does not need to explain parameters since none exist, and no additional semantics are missing.

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 the specific verb 'describe' and clearly identifies the resource: the Agent Verification Utility. It enumerates distinct facets (usefulness, non-usefulness, validation, recipes, limits, paid MCP path), distinguishing it from operational siblings like verify_evidence and commercial ones like quote_verify_evidence.

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

Usage Guidelines3/5

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

The description implies its use for learning about deterministic verification, but it does not explicitly state when to choose it over the sibling tools (e.g., 'use verify_evidence to verify, use this tool for guidance'). No exclusions or alternative tool recommendations are given.

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

get_revenue_goal_statusGet Revenue Goal StatusA
Read-onlyIdempotent
Inspect

Read the active revenue goal, measured funnel, contribution margin, and the next bounded improvement recommendation. This tool never changes price, spends funds, or sends messages.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds specific context about what it reads (active revenue goal, funnel, margin, recommendation) and reassures about no side effects, exceeding annotation basics.

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 concise and front-loaded: the first sentence states the core purpose and key outputs, the second sentence adds a safety clarification. No redundancy.

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 zero-parameter, read-only tool with rich annotations, the description is complete—it specifies exactly what data is read and what side effects are absent, making it fully understandable in context.

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?

The tool has zero parameters, so the schema is fully covered by default. The description adds value by describing the data and output focus, which is appropriate for a no-parameter tool.

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 identifies the tool as a read operation ('Read the active revenue goal') with specific resources and outputs, and it is distinct from the sibling tools focused on verify_evidence.

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?

The description provides clear context that this is a safe, read-only operation and explicitly lists side effects it avoids ('never changes price, spends funds, or sends messages'), though it does not name alternatives or exclusions.

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

prepare_verify_evidence_purchasePrepare HTTP PurchaseA
Idempotent
Inspect

Prepare an HTTP purchase request for deterministic JSON verification after a successful free precheck; a prior quote tool call is optional. After a successful free precheck at POST /validate-request, supply the unchanged intent and its precheck_receipt.receipt_digest. Creates or reuses a persisted quote and records observability events; no payment, signing or paid verification is performed. The bound quote ties request/evidence digests, precheck digest, spend policy, quoted amount, network, asset, recipient and expiry together. Server availability, fresh cost basis and conservative contribution-margin thresholds must pass. Returns JSON text and structuredContent containing quote, request (POST /verify-evidence, content-type and X-Quote-ID headers, unchanged intent body), expected_first_status=402 and expected_payment_header=PAYMENT-REQUIRED. It does not send this request. Application failures return isError=true with JSON error.code, message, retryable and optional details (for example PRECHECK_STALE, PRICE_CAP_EXCEEDED, IDEMPOTENCY_KEY_CONFLICT, IDEMPOTENCY_KEY_EXPIRED or UNPROFITABLE_TRANSACTION); invalid argument shapes are rejected by MCP schema validation. Re-run precheck after request/policy changes; do not pay on refusal. Next send the returned request to obtain a challenge, check binding, amount, network, asset, payTo and expiry against local policy, then authorize payment separately. Use quote_verify_evidence when only quote terms are needed.

ParametersJSON Schema
NameRequiredDescriptionDefault
intentYesRequired prechecked purchase intent: request, spend_policy and precheck_receipt_digest are all required, with no defaults or optional fields. Preserve the request and policy used in the successful free POST /validate-request.
idempotency_keyYesRequired 16-128 characters from A-Z, a-z, 0-9, underscore or hyphen. Reuse with the unchanged intent to reuse an unexpired quote; changed bindings return IDEMPOTENCY_KEY_CONFLICT. An expired key returns IDEMPOTENCY_KEY_EXPIRED; use a new key.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is clear. The description adds crucial context beyond annotations: no payment/signing occurs, creates or reuses a persisted quote, records observability events, server availability and margin thresholds must pass, application failures return isError=true with specific error codes, and it explains the next steps.

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 dense and front-loads the key purpose. While long, every sentence earns its place by conveying necessary behavioral and procedural details. However, it could be slightly more structured with bullet points or shorter sentences for readability.

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 (nested objects, 2 required params, no output schema), the description covers all essential aspects: inputs needed, what the tool does, what it returns (including expected_first_status and expected_payment_header), error behaviors, and next steps. It's complete for an agent to call it correctly.

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 description coverage is 100%, so the schema already documents parameters thoroughly. The description adds meaning by explaining that the precheck_receipt_digest ties to the successful precheck, that the intent must be unchanged, and that idempotency_key reuse with unchanged intent reuses an unexpired quote, which goes beyond the schema's parameter descriptions.

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+resource: prepares an HTTP purchase request for deterministic JSON verification. Clearly distinguishes from siblings by explicitly naming quote_verify_evidence as the alternative when only quote terms are needed, and distinguishes from verify_evidence by stating it does not send the request.

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?

Explicitly describes when to use: after a successful free precheck, with a prior quote tool call being optional. Names the alternative (quote_verify_evidence) and the condition that selects it. Instructs to re-run precheck after changes and not to pay on refusal.

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

quote_verify_evidenceQuote VerificationA
Idempotent
Inspect

Obtain a free bound quote for deterministic checks on supplied JSON before deciding to purchase. After a successful free precheck at POST /validate-request, supply the unchanged intent and its precheck_receipt.receipt_digest. Creates or reuses a persisted quote and records observability events; no payment, signing or paid verification is performed. The bound quote ties request/evidence digests, precheck digest, spend policy, quoted amount, network, asset, recipient and expiry together. Server availability, fresh cost basis and conservative contribution-margin thresholds must pass. Returns the quote as JSON text and structuredContent: quote_id, request_hash, price (atomic USDC, 6 decimals), expires_at, economic_guard, purchase instructions and paid_verification_binding in state quoted, not a paid receipt. Application failures return isError=true with JSON error.code, message, retryable and optional details (for example PRECHECK_STALE, PRICE_CAP_EXCEEDED, IDEMPOTENCY_KEY_CONFLICT, IDEMPOTENCY_KEY_EXPIRED or UNPROFITABLE_TRANSACTION); invalid argument shapes are rejected by MCP schema validation. Re-run precheck after request/policy changes; do not pay on refusal. Next use prepare_verify_evidence_purchase with the same key and intent for the HTTP purchase request, or explicitly authorize the separate paid verify_evidence flow.

ParametersJSON Schema
NameRequiredDescriptionDefault
intentYesRequired prechecked purchase intent: request, spend_policy and precheck_receipt_digest are all required, with no defaults or optional fields. Preserve the request and policy used in the successful free POST /validate-request.
idempotency_keyYesRequired 16-128 characters from A-Z, a-z, 0-9, underscore or hyphen. Reuse with the unchanged intent to reuse an unexpired quote; changed bindings return IDEMPOTENCY_KEY_CONFLICT. An expired key returns IDEMPOTENCY_KEY_EXPIRED; use a new key.

TDQS

A4.6/5.0
Behavior5/5

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

Adds substantial context beyond the annotations: it creates or reuses a persisted quote, records observability events, performs no payment/signing/paid verification, and specifies the failure contract (isError=true with error.code, message, retryable, and named codes like PRECHECK_STALE and IDEMPOTENCY_KEY_CONFLICT). It also enumerates the quote binding and its state ('quoted', not a paid receipt).

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?

Front-loaded with the core action and scope, and every sentence carries real information. It is dense and lengthy, folding return-value detail and error codes into one paragraph, but with no output schema that content largely earns its place.

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?

With no output schema, the description fully covers the return contract (quote_id, request_hash, price, expires_at, economic_guard, purchase instructions, binding) and the failure contract. For a quote-creating tool whose annotations already declare non-destructive/idempotent behavior, nothing needed to call it correctly is missing.

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 coverage is 100%, so the schema already documents intent, spend_policy, precheck_receipt_digest and idempotency_key semantics, including the conflict/expiry codes. The description corroborates the precheck flow and the unchanged-intent requirement but adds little syntax or meaning beyond what the schema descriptions already provide; 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?

States a specific verb and resource (obtain a free bound quote), establishes scope (deterministic checks on supplied JSON, no payment or paid verification), and implicitly separates itself from verify_evidence and prepare_verify_evidence_purchase by naming both later. An agent can tell this is the quote step, not the verification step.

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?

Explicitly gates the call on a prior successful free precheck, requires supplying the unchanged intent and its receipt_digest, states when to re-run precheck (after request/policy changes), warns 'do not pay on refusal', and names the next tool (prepare_verify_evidence_purchase) versus the separate paid flow. When/when-not/alternatives are all present.

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

verify_evidenceVerify Evidence (paid)A
Idempotent
Inspect

Run deterministic checks and return Ed25519-signed evidence after one explicitly authorized x402 payment. A free precheck receipt and a matching bound payment requirement are required before signing.

ParametersJSON Schema
NameRequiredDescriptionDefault
intentYes
idempotency_keyYes

TDQS

A4/5.0
Behavior4/5

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

The description adds behavioral context beyond annotations: it requires an explicitly authorized x402 payment, is deterministic, and needs a precheck receipt and bound payment requirement. With annotations already covering idempotency and read-only/destructive hints, this extra context is meaningful and non-contradictory.

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?

Two sentences, front-loaded with the primary action, and no filler. Every sentence adds critical context: what the tool does, payment authorization, and prerequisites.

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

Completeness3/5

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

The description provides essential workflow context (payment, precheck receipt, bound payment) and mentions the signed evidence return, but lacks details about the complex nested parameters and the output structure. Given the rich schema and no output schema, the description is minimally adequate but leaves the agent to infer much from schema alone.

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%, and the description does not explain any parameters directly. It only indirectly hints at precheck_receipt_digest and spend_policy via 'free precheck receipt' and 'bound payment requirement', but the complex nested intent structure (evidence, assertions, idempotency_key) remains unexplained. The description fails to compensate for the 0% schema coverage.

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 states a specific verb ('Run deterministic checks') and resource ('return Ed25519-signed evidence'), and distinguishes itself from siblings by emphasizing the paid x402 payment requirement and prerequisites. It is unambiguous about what the tool does and differs from quote/prepare/describe siblings.

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?

The description explicitly states prerequisites ('A free precheck receipt and a matching bound payment requirement are required before signing'), making it clear when this tool should be invoked. It does not name alternatives or exclusions, but the workflow context is strong enough for an agent to understand ordering relative to prepare/quote siblings.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updates
    • Changedprepare_verify_evidence_purchase16 fields changed
      • addedInput schema / properties / idempotency_key / description
        Added value: +"Required 16-128 characters from A-Z, a-z, 0-9, underscore or hyphen. Reuse with the unchanged intent to reuse an unexpired quote; changed bindings return IDEMPOTENCY_KEY_CONFLICT. An expired key returns IDEMPOTENCY_KEY_EXPIRED; use a new key."
      • addedInput schema / properties / intent / description
        Added value: +"Required prechecked purchase intent: request, spend_policy and precheck_receipt_digest are all required, with no defaults or optional fields. Preserve the request and policy used in the successful free POST /validate-request."
      • addedInput schema / properties / intent / properties / precheck_receipt_digest / description
        Added value: +"Required sha256: followed by 64 lowercase hex characters, copied from precheck_receipt.receipt_digest of the successful free precheck. Recomputed against request, policy and current discovery contract; mismatches return PRECHECK_STALE."
      • addedInput schema / properties / intent / properties / request / description
        Added value: +"Required complete bounded verification request, unchanged from precheck; no optional fields or defaults."
      • addedInput schema / properties / intent / properties / request / properties / assertions / description
        Added value: +"Required 1-16 deterministic assertions. Each operation accepts only its documented fields. Precheck validates input, not assertion truth."
      • changedInput schema / properties / intent / properties / request / properties / assertions / items / oneOf
        Previous value: -[
-  {
-    "additionalProperties": false,
-    "properties": {
-      "expected_hex": {
-        "pattern": "^[a-f0-9]{64}$",
-        "type": "string"
-      },
-      "op": {
-        "const": "sha256_equals",
-        "type": "string"
-      }
-    },
-    "required": [
-      "op",
-      "expected_hex"
-    ],
-    "type": "object"
-  },
-  {
-    "additionalProperties": false,
-    "properties": {
-      "op": {
-        "const": "json_pointer_exists",
-        "type": "string"
-      },
-      "path": {
-        "maxLength": 512,
-        "type": "string"
-      }
-    },
-    "required": [
-      "op",
-      "path"
-    ],
-    "type": "object"
-  },
-  {
-    "additionalProperties": false,
-    "properties": {
-      "expected": {},
-      "op": {
-        "const": "json_pointer_equals",
-        "type": "string"
-      },
-      "path": {
-        "maxLength": 512,
-        "type": "string"
-      }
-    },
-    "required": [
-      "op",
-      "path",
-      "expected"
-    ],
-    "type": "object"
-  },
-  {
-    "additionalProperties": false,
-    "properties": {
-      "expected_type": {
-        "enum": [
-          "null",
-          "boolean",
-          "number",
-          "string",
-          "array",
-          "object"
-        ],
-        "type": "string"
-      },
-      "op": {
-        "const": "json_type_is",
-        "type": "string"
-      },
-      "path": {
-        "maxLength": 512,
-        "type": "string"
-      }
-    },
-    "required": [
-      "op",
-      "path",
-      "expected_type"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "additionalProperties": false,
+    "properties": {
+      "expected_hex": {
+        "description": "Required expected digest as exactly 64 lowercase hex characters, without sha256: prefix.",
+        "pattern": "^[a-f0-9]{64}$",
+        "type": "string"
+      },
+      "op": {
+        "const": "sha256_equals",
+        "description": "Compare SHA-256 of the raw decoded evidence bytes.",
+        "type": "string"
+      }
+    },
+    "required": [
+      "op",
+      "expected_hex"
+    ],
+    "type": "object"
+  },
+  {
+    "additionalProperties": false,
+    "properties": {
+      "op": {
+        "const": "json_pointer_exists",
+        "description": "Check whether the JSON Pointer resolves.",
+        "type": "string"
+      },
+      "path": {
+        "description": "Required RFC 6901 JSON Pointer, at most 512 characters; empty string selects the document root. Escape tilde as ~0 and slash as ~1.",
+        "maxLength": 512,
+        "type": "string"
+      }
+    },
+    "required": [
+      "op",
+      "path"
+    ],
+    "type": "object"
+  },
+  {
+    "additionalProperties": false,
+    "properties": {
+      "expected": {
+        "description": "Required expected JSON value, including null; JSON depth/key/value and safe-integer limits apply."
+      },
+      "op": {
+        "const": "json_pointer_equals",
+        "description": "Compare the selected JSON value with expected.",
+        "type": "string"
+      },
+      "path": {
+        "description": "Required RFC 6901 JSON Pointer, at most 512 characters; empty string selects the document root. Escape tilde as ~0 and slash as ~1.",
+        "maxLength": 512,
+        "type": "string"
+      }
+    },
+    "required": [
+      "op",
+      "path",
+      "expected"
+    ],
+    "type": "object"
+  },
+  {
+    "additionalProperties": false,
+    "properties": {
+      "expected_type": {
+        "description": "Required JSON type: null, boolean, number, string, array or object.",
+        "enum": [
+          "null",
+          "boolean",
+          "number",
+          "string",
+          "array",
+          "object"
+        ],
+        "type": "string"
+      },
+      "op": {
+        "const": "json_type_is",
+        "description": "Check the selected JSON value type.",
+        "type": "string"
+      },
+      "path": {
+        "description": "Required RFC 6901 JSON Pointer, at most 512 characters; empty string selects the document root. Escape tilde as ~0 and slash as ~1.",
+        "maxLength": 512,
+        "type": "string"
+      }
+    },
+    "required": [
+      "op",
+      "path",
+      "expected_type"
+    ],
+    "type": "object"
+  }
+]
      • addedInput schema / properties / intent / properties / request / properties / client_request_id / description
        Added value: +"Required caller request identifier, 1-64 characters from A-Z, a-z, 0-9, dot, underscore, colon or hyphen; included in the request hash."
      • addedInput schema / properties / intent / properties / request / properties / evidence / description
        Added value: +"Required caller-supplied JSON bytes; no remote evidence is fetched."
      • addedInput schema / properties / intent / properties / request / properties / evidence / properties / content_base64 / description
        Added value: +"Required strict standard Base64 of UTF-8 JSON; 4-87384 encoded characters and at most 65536 decoded bytes. JSON limits: depth 32, object keys 2048, values 8192; integers must be JavaScript safe integers."
      • addedInput schema / properties / intent / properties / request / properties / evidence / properties / media_type / description
        Added value: +"Required literal application/json."
      • addedInput schema / properties / intent / properties / spend_policy / description
        Added value: +"Required caller spending limits and allowed terms; preserve from precheck. All five fields required; no defaults."
      • addedInput schema / properties / intent / properties / spend_policy / properties / asset / description
        Added value: +"Required USDC contract address, 0x plus 40 hex characters; must match current advertised asset."
      • addedInput schema / properties / intent / properties / spend_policy / properties / max_amount_atomic / description
        Added value: +"Required positive decimal integer string in atomic USDC units (1000000 = 1 USDC), at most 16 digits and within JavaScript safe-integer range. No leading zero; must cover the current quoted price."
      • addedInput schema / properties / intent / properties / spend_policy / properties / network / description
        Added value: +"Required eip155:8453 (Base) or eip155:84532 (Base Sepolia); must match current advertised terms."
      • addedInput schema / properties / intent / properties / spend_policy / properties / pay_to / description
        Added value: +"Required allowed payment recipient, 0x plus 40 hex characters; must match current advertised payTo."
      • addedInput schema / properties / intent / properties / spend_policy / properties / policy_version / description
        Added value: +"Required literal agent-economy/precheck-policy/2.0."
    • Changedquote_verify_evidence16 fields changed
      • addedInput schema / properties / idempotency_key / description
        Added value: +"Required 16-128 characters from A-Z, a-z, 0-9, underscore or hyphen. Reuse with the unchanged intent to reuse an unexpired quote; changed bindings return IDEMPOTENCY_KEY_CONFLICT. An expired key returns IDEMPOTENCY_KEY_EXPIRED; use a new key."
      • addedInput schema / properties / intent / description
        Added value: +"Required prechecked purchase intent: request, spend_policy and precheck_receipt_digest are all required, with no defaults or optional fields. Preserve the request and policy used in the successful free POST /validate-request."
      • addedInput schema / properties / intent / properties / precheck_receipt_digest / description
        Added value: +"Required sha256: followed by 64 lowercase hex characters, copied from precheck_receipt.receipt_digest of the successful free precheck. Recomputed against request, policy and current discovery contract; mismatches return PRECHECK_STALE."
      • addedInput schema / properties / intent / properties / request / description
        Added value: +"Required complete bounded verification request, unchanged from precheck; no optional fields or defaults."
      • addedInput schema / properties / intent / properties / request / properties / assertions / description
        Added value: +"Required 1-16 deterministic assertions. Each operation accepts only its documented fields. Precheck validates input, not assertion truth."
      • changedInput schema / properties / intent / properties / request / properties / assertions / items / oneOf
        Previous value: -[
-  {
-    "additionalProperties": false,
-    "properties": {
-      "expected_hex": {
-        "pattern": "^[a-f0-9]{64}$",
-        "type": "string"
-      },
-      "op": {
-        "const": "sha256_equals",
-        "type": "string"
-      }
-    },
-    "required": [
-      "op",
-      "expected_hex"
-    ],
-    "type": "object"
-  },
-  {
-    "additionalProperties": false,
-    "properties": {
-      "op": {
-        "const": "json_pointer_exists",
-        "type": "string"
-      },
-      "path": {
-        "maxLength": 512,
-        "type": "string"
-      }
-    },
-    "required": [
-      "op",
-      "path"
-    ],
-    "type": "object"
-  },
-  {
-    "additionalProperties": false,
-    "properties": {
-      "expected": {},
-      "op": {
-        "const": "json_pointer_equals",
-        "type": "string"
-      },
-      "path": {
-        "maxLength": 512,
-        "type": "string"
-      }
-    },
-    "required": [
-      "op",
-      "path",
-      "expected"
-    ],
-    "type": "object"
-  },
-  {
-    "additionalProperties": false,
-    "properties": {
-      "expected_type": {
-        "enum": [
-          "null",
-          "boolean",
-          "number",
-          "string",
-          "array",
-          "object"
-        ],
-        "type": "string"
-      },
-      "op": {
-        "const": "json_type_is",
-        "type": "string"
-      },
-      "path": {
-        "maxLength": 512,
-        "type": "string"
-      }
-    },
-    "required": [
-      "op",
-      "path",
-      "expected_type"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "additionalProperties": false,
+    "properties": {
+      "expected_hex": {
+        "description": "Required expected digest as exactly 64 lowercase hex characters, without sha256: prefix.",
+        "pattern": "^[a-f0-9]{64}$",
+        "type": "string"
+      },
+      "op": {
+        "const": "sha256_equals",
+        "description": "Compare SHA-256 of the raw decoded evidence bytes.",
+        "type": "string"
+      }
+    },
+    "required": [
+      "op",
+      "expected_hex"
+    ],
+    "type": "object"
+  },
+  {
+    "additionalProperties": false,
+    "properties": {
+      "op": {
+        "const": "json_pointer_exists",
+        "description": "Check whether the JSON Pointer resolves.",
+        "type": "string"
+      },
+      "path": {
+        "description": "Required RFC 6901 JSON Pointer, at most 512 characters; empty string selects the document root. Escape tilde as ~0 and slash as ~1.",
+        "maxLength": 512,
+        "type": "string"
+      }
+    },
+    "required": [
+      "op",
+      "path"
+    ],
+    "type": "object"
+  },
+  {
+    "additionalProperties": false,
+    "properties": {
+      "expected": {
+        "description": "Required expected JSON value, including null; JSON depth/key/value and safe-integer limits apply."
+      },
+      "op": {
+        "const": "json_pointer_equals",
+        "description": "Compare the selected JSON value with expected.",
+        "type": "string"
+      },
+      "path": {
+        "description": "Required RFC 6901 JSON Pointer, at most 512 characters; empty string selects the document root. Escape tilde as ~0 and slash as ~1.",
+        "maxLength": 512,
+        "type": "string"
+      }
+    },
+    "required": [
+      "op",
+      "path",
+      "expected"
+    ],
+    "type": "object"
+  },
+  {
+    "additionalProperties": false,
+    "properties": {
+      "expected_type": {
+        "description": "Required JSON type: null, boolean, number, string, array or object.",
+        "enum": [
+          "null",
+          "boolean",
+          "number",
+          "string",
+          "array",
+          "object"
+        ],
+        "type": "string"
+      },
+      "op": {
+        "const": "json_type_is",
+        "description": "Check the selected JSON value type.",
+        "type": "string"
+      },
+      "path": {
+        "description": "Required RFC 6901 JSON Pointer, at most 512 characters; empty string selects the document root. Escape tilde as ~0 and slash as ~1.",
+        "maxLength": 512,
+        "type": "string"
+      }
+    },
+    "required": [
+      "op",
+      "path",
+      "expected_type"
+    ],
+    "type": "object"
+  }
+]
      • addedInput schema / properties / intent / properties / request / properties / client_request_id / description
        Added value: +"Required caller request identifier, 1-64 characters from A-Z, a-z, 0-9, dot, underscore, colon or hyphen; included in the request hash."
      • addedInput schema / properties / intent / properties / request / properties / evidence / description
        Added value: +"Required caller-supplied JSON bytes; no remote evidence is fetched."
      • addedInput schema / properties / intent / properties / request / properties / evidence / properties / content_base64 / description
        Added value: +"Required strict standard Base64 of UTF-8 JSON; 4-87384 encoded characters and at most 65536 decoded bytes. JSON limits: depth 32, object keys 2048, values 8192; integers must be JavaScript safe integers."
      • addedInput schema / properties / intent / properties / request / properties / evidence / properties / media_type / description
        Added value: +"Required literal application/json."
      • addedInput schema / properties / intent / properties / spend_policy / description
        Added value: +"Required caller spending limits and allowed terms; preserve from precheck. All five fields required; no defaults."
      • addedInput schema / properties / intent / properties / spend_policy / properties / asset / description
        Added value: +"Required USDC contract address, 0x plus 40 hex characters; must match current advertised asset."
      • addedInput schema / properties / intent / properties / spend_policy / properties / max_amount_atomic / description
        Added value: +"Required positive decimal integer string in atomic USDC units (1000000 = 1 USDC), at most 16 digits and within JavaScript safe-integer range. No leading zero; must cover the current quoted price."
      • addedInput schema / properties / intent / properties / spend_policy / properties / network / description
        Added value: +"Required eip155:8453 (Base) or eip155:84532 (Base Sepolia); must match current advertised terms."
      • addedInput schema / properties / intent / properties / spend_policy / properties / pay_to / description
        Added value: +"Required allowed payment recipient, 0x plus 40 hex characters; must match current advertised payTo."
      • addedInput schema / properties / intent / properties / spend_policy / properties / policy_version / description
        Added value: +"Required literal agent-economy/precheck-policy/2.0."
  2. 5 tool updates
    • First observeddescribe_verify_evidence
    • First observedget_revenue_goal_status
    • First observedprepare_verify_evidence_purchase
    • First observedquote_verify_evidence
    • First observedverify_evidence

Related MCP Connectors

Related MCP Servers

  • zkVerify

    zkarchitect
    A
    license
    A
    quality
    B
    maintenance
    Enables AI agents to fetch and independently verify on-chain data such as account balances and contract code hashes using Merkle proofs and ECDSA signatures, with x402 payment integration.
    3
    MIT

  • Attest402

    paulos-sudo
    F
    license
    Not graded
    quality
    B
    maintenance
    MCP server for creating cryptographically signed and timestamped evidence of public web/API responses, with offline verification of attestations and paid access via x402.
    -

  • Headless Oracle

    LembaGang
    A
    license
    Not graded
    quality
    C
    maintenance
    Ed25519-signed market-state receipts for 28 exchanges: is the venue open right now, as a receipt any agent can verify without trusting the operator, fail-closed (unknown is reported as closed). MCP tools: get_market_status, get_market_schedule, list_exchanges, get_payment_options. Free tier 500 calls a day with an instant key; x402 pay-per-call at 0.001 USDC on Base; Builder 99 USDC a month
    MIT
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