Agent Revenue Network

AI-Agent Execution Verification · Security & Functional Verification

verify_execution

Read-onlyIdempotent

Discover deterministic acceptance checking for an automated task or agent execution across nine explicit functional, security, privacy, copyright, regulatory, transaction-integrity, abuse, regression and economics gates. All nine caller-supplied booleans must be true; paid execution returns the candidate id, pass/fail status and failed gate names. Use only after trusted verifiers supply all nine booleans because ARN does not scan code, audit systems or certify compliance. For sustained CI volume, Release Guard offers 2,500 successful checks over 30 days and breaks even with 0.01-USDC pay-per-call at 1,900 checks. This free MCP discovery call does not execute the advertised capability and does not charge; it returns the exact x402 endpoint, price and payment guide for execution.

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": {
      "candidate": "<candidate>",
      "checks": "<checks>"
    },
    "name": "verify_execution"
  }
}

Input Schema

Name	Required	Description	Default
`checks`	Yes	Explicit boolean outcomes from trusted upstream verifiers. Every gate must be true to approve.
`candidate`	Yes	Candidate metadata. candidate.id is returned when present; candidate contents are not independently inspected.

Output Schema

Name	Required	Description
`price`	Yes
`method`	Yes	HTTP method for paid execution.
`endpoint`	Yes	Canonical absolute ARN HTTP URL to POST the same tool arguments to for paid execution.
`protocol`	Yes	Payment protocol required by the HTTP execution endpoint.
`instruction`	Yes	How to execute the capability after receiving the payment requirement.
`paymentGuide`	Yes	Public setup guide with a working x402 v2 Base-mainnet client example.
`paymentRequired`	Yes	Always true for paid ARN capabilities exposed over MCP.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 20, 2026

changedOutput schema / properties / endpoint / description

Previous value: -"ARN HTTP path to POST the same tool arguments to for paid execution."New value: +"Canonical absolute ARN HTTP URL to POST the same tool arguments to for paid execution."

addedOutput schema / properties / endpoint / format
```
Added value: +"uri"
```

addedOutput schema / properties / method

Added value: +{
+  "const": "POST",
+  "description": "HTTP method for paid execution.",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "paymentRequired",
-  "protocol",
-  "endpoint",
-  "price",
-  "paymentGuide",
-  "instruction"
-]New value: +[
+  "paymentRequired",
+  "protocol",
+  "method",
+  "endpoint",
+  "price",
+  "paymentGuide",
+  "instruction"
+]

Changed2 schema fields changedOct 8, 2026

addedOutput schema / properties / paymentGuide

Added value: +{
+  "description": "Public setup guide with a working x402 v2 Base-mainnet client example.",
+  "format": "uri",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "paymentRequired",
-  "protocol",
-  "endpoint",
-  "price",
-  "instruction"
-]New value: +[
+  "paymentRequired",
+  "protocol",
+  "endpoint",
+  "price",
+  "paymentGuide",
+  "instruction"
+]

Changed8 schema fields changedOct 2, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

addedInput schema / description

Added value: +"Input for evaluating previously computed execution-gate evidence."

addedInput schema / properties / candidate / description

Added value: +"Candidate metadata. candidate.id is returned when present; candidate contents are not independently inspected."

addedInput schema / properties / checks / additionalProperties
```
Added value: +false
```

addedInput schema / properties / checks / description

Added value: +"Explicit boolean outcomes from trusted upstream verifiers. Every gate must be true to approve."

addedInput schema / properties / checks / properties

Added value: +{
+  "abuse": {
+    "description": "Abuse and misuse checks passed.",
+    "type": "boolean"
+  },
+  "copyright": {
+    "description": "Copyright/licensing checks passed.",
+    "type": "boolean"
+  },
+  "economics": {
+    "description": "Economics gate passed.",
+    "type": "boolean"
+  },
+  "functional": {
+    "description": "Functional acceptance checks passed.",
+    "type": "boolean"
+  },
+  "privacy": {
+    "description": "Privacy checks passed.",
+    "type": "boolean"
+  },
+  "regression": {
+    "description": "Regression checks passed.",
+    "type": "boolean"
+  },
+  "regulatory": {
+    "description": "Applicable regulatory checks passed.",
+    "type": "boolean"
+  },
+  "security": {
+    "description": "Security checks passed.",
+    "type": "boolean"
+  },
+  "transactionIntegrity": {
+    "description": "Payment/transaction integrity checks passed.",
+    "type": "boolean"
+  }
+}

addedInput schema / properties / checks / required

Added value: +[
+  "functional",
+  "security",
+  "privacy",
+  "copyright",
+  "regulatory",
+  "transactionIntegrity",
+  "abuse",
+  "regression",
+  "economics"
+]

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "description": "MCP payment instruction. Calling the MCP tool itself does not charge or execute the paid operation.",
+  "properties": {
+    "endpoint": {
+      "description": "ARN HTTP path to POST the same tool arguments to for paid execution.",
+      "type": "string"
+    },
+    "instruction": {
+      "description": "How to execute the capability after receiving the payment requirement.",
+      "type": "string"
+    },
+    "paymentRequired": {
+      "const": true,
+      "description": "Always true for paid ARN capabilities exposed over MCP.",
+      "type": "boolean"
+    },
+    "price": {
+      "additionalProperties": false,
+      "properties": {
+        "amount": {
+          "description": "Atomic asset amount.",
+          "type": "string"
+        },
+        "asset": {
+          "description": "Settlement asset.",
+          "type": "string"
+        },
+        "display": {
+          "description": "Human-readable current price.",
+          "type": "string"
+        },
+        "network": {
+          "description": "CAIP-2 settlement network identifier.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "amount",
+        "asset",
+        "network",
+        "display"
+      ],
+      "type": "object"
+    },
+    "protocol": {
+      "const": "x402",
+      "description": "Payment protocol required by the HTTP execution endpoint.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "paymentRequired",
+    "protocol",
+    "endpoint",
+    "price",
+    "instruction"
+  ],
+  "type": "object"
+}

First observedOct 2, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations cover safety (readOnlyHint, idempotent, non-destructive), and the description adds the behavior they cannot: this call does not execute the advertised capability, does not charge, and returns the x402 endpoint, price and payment guide. It also discloses that paid execution returns candidate id, pass/fail and failed gate names.

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 essential disclosure (discovery-only, no charge, no execution) is well front-loaded, but the pricing economics sentence ('breaks even with 0.01-USDC pay-per-call at 1,900 checks') is obscure detail that inflates an already dense description for a two-parameter tool.

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 an output schema, a nested nine-boolean input, and the unusual payment/discovery framing, the description is complete: it covers gate semantics, the trusted-verifier precondition, non-execution, and what the paid path returns. An agent has everything needed 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 coverage is 100% so the bar is a baseline 3, and the description goes beyond it by stating the conjunctive rule (all nine caller-supplied booleans must be true) and clarifying that candidate.id is returned when present while candidate contents are not inspected. It adds meaningful semantics without contradicting the schema.

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 names a specific capability (deterministic acceptance checking across nine named gates) and is explicit that this call is a free discovery endpoint rather than the actual executing capability. It distinguishes itself from siblings like release_evidence_diff by scope, though the naming/purpose tension between 'verify_execution' and 'discovery call that does not execute' takes a careful read to resolve.

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?

It gives an explicit precondition ('Use only after trusted verifiers supply all nine booleans'), an explicit exclusion ('ARN does not scan code, audit systems or certify compliance'), and a named alternative for CI volume (Release Guard at 2,500 checks/30 days). Nothing is left to inference about when to reach for this tool.

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

All Agent Revenue Network tools Inspect

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

Need Help?