Synthex Forge — x402 Paid Agent Services

Verify Edge Evidence

verify_edge_evidence

Read-onlyIdempotent

recompute the digest and verify the signature of an answer. use it rather than verify_edge_replication for edge evidence, not edge replication; an object with 13 fields including algorithm, basis.

Input Schema

Name	Required	Description
`signature`	Yes	The Ed25519 signature (hex).
`answerCore`	Yes	The answerCore object returned by POST /v1/edge/prior.
`output_sha256`	No	The output_sha256 returned alongside the answer (optional; when supplied it is compared against a freshly recomputed digest).

Output Schema

Name	Required	Description
`note`	No	A note on how the answer was produced.
`basis`	No	The `basis` field of the response.
`found`	No	The `found` field of the response.
`verdict`	Yes	The decision this tool returned.
`algorithm`	No	The `algorithm` field of the response.
`reproduced`	No	The `reproduced` field of the response.
`publicKeyHex`	No	The `publicKeyHex` field of the response.
`signature_ok`	No	The `signature_ok` field of the response.
`signature_error`	No	The `signature_error` field of the response.
`registry_version`	No	The `registry_version` field of the response.
`sha256_recomputed`	No	The `sha256_recomputed` field of the response.
`sha256_reproduced`	No	The `sha256_reproduced` field of the response.
`output_sha256_match`	No	The `output_sha256_match` field of the response.

Schema Changelog

Changes observed during successful MCP inspections.

Changed15 schema fields changedOct 31, 2026

addedOutput schema / properties / algorithm

Added value: +{
+  "description": "The `algorithm` field of the response.",
+  "type": "object"
+}

addedOutput schema / properties / basis

Added value: +{
+  "description": "The `basis` field of the response.",
+  "type": "object"
+}

addedOutput schema / properties / found

Added value: +{
+  "description": "The `found` field of the response.",
+  "type": "object"
+}

addedOutput schema / properties / note

Added value: +{
+  "description": "A note on how the answer was produced.",
+  "type": "string"
+}

addedOutput schema / properties / output_sha256_match

Added value: +{
+  "description": "The `output_sha256_match` field of the response.",
+  "type": "object"
+}

addedOutput schema / properties / publicKeyHex

Added value: +{
+  "description": "The `publicKeyHex` field of the response.",
+  "type": "object"
+}

addedOutput schema / properties / registry_version

Added value: +{
+  "description": "The `registry_version` field of the response.",
+  "type": "object"
+}

addedOutput schema / properties / reproduced

Added value: +{
+  "description": "The `reproduced` field of the response.",
+  "type": "object"
+}

addedOutput schema / properties / sha256_recomputed

Added value: +{
+  "description": "The `sha256_recomputed` field of the response.",
+  "type": "object"
+}

addedOutput schema / properties / sha256_reproduced

Added value: +{
+  "description": "The `sha256_reproduced` field of the response.",
+  "type": "object"
+}

addedOutput schema / properties / signature_error

Added value: +{
+  "description": "The `signature_error` field of the response.",
+  "type": "object"
+}

addedOutput schema / properties / signature_ok

Added value: +{
+  "description": "The `signature_ok` field of the response.",
+  "type": "object"
+}

removedOutput schema / properties / status

Removed value: -{
-  "type": "string"
-}

addedOutput schema / properties / verdict

Added value: +{
+  "description": "The decision this tool returned.",
+  "type": "string"
+}

addedOutput schema / required
```
Added value: +[
+  "verdict"
+]
```

AddedOct 31, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds that the digest is recomputed and compared, but never says what a mismatch produces (error vs. false flag) — the single most important behavioral question for a verifier. The '13 fields' remark adds no verifiable behavior.

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 action is front-loaded and the sibling disambiguation follows usefully, so the opening earns its place. But the closing clause '; an object with 13 fields including algorithm, basis' is a dangling fragment with no clear referent and reads as leftover schema note rather than guidance.

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?

With an output schema present the return shape need not be described, annotations cover safety, and all three parameters are fully documented in the schema. The remaining gap is the mismatch/error semantics and the role of the optional output_sha256 beyond what the schema states, which is modest for a verifier.

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 signature, answerCore and output_sha256 are already documented at the field level, making 3 the baseline. The description's only addition is a loose hint that answerCore carries an algorithm and basis field among 13, which is too vague to change caller behavior.

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?

States a concrete compound action on a concrete resource: recompute the digest and verify the Ed25519 signature of an answer. It also names the sibling it is not (verify_edge_replication), so an agent can discriminate. The trailing fragment 'an object with 13 fields including algorithm, basis' blurs the object being described, keeping it 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 Guidelines4/5

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

Explicitly routes the agent: use this rather than `verify_edge_replication` for edge evidence, not edge replication. That is a named alternative plus the discriminating condition. It stops short of 5 because it gives no precondition (e.g. that answerCore must come from get_edge_prior / POST /v1/edge/prior) and no failure-path guidance.

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

All Synthex Forge — x402 Paid Agent Services 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.