Synthex Forge — x402 Paid Agent Services

Verify Catalog Recheck

verify_catalog_recheck

Read-onlyIdempotent

independently re-check a registered verify-catalog receipt's. part of the surface; an object with 14 fields including as_of, basis.

Input Schema

Name	Required	Description
`body`	No	The request body the operation operates on.
`sha256`	No	The SHA-256 hex digest of the artifact being verified.
`signature`	No	The Ed25519 signature to verify, base64-encoded.

Output Schema

Name	Required	Description
`note`	No	A note on how the answer was produced.
`as_of`	No	The date the answer is computed as of.
`basis`	No	The `basis` field of the response.
`valid`	Yes	Whether the artifact verified.
`detail`	Yes	Human-readable explanation of the verdict.
`source`	No	The `source` field of the response.
`verdict`	Yes	The decision this tool returned.
`hash_valid`	No	The `hash_valid` field of the response.
`verifiedAt`	No	The `verifiedAt` field of the response.
`verifiedBy`	No	The `verifiedBy` field of the response.
`signature_valid`	No	The `signature_valid` field of the response.
`recomputed_sha256`	No	The `recomputed_sha256` field of the response.
`recomputed_sha256_as_of`	No	The `recomputed_sha256_as_of` field of the response.
`recomputed_sha256_source`	No	The `recomputed_sha256_source` field of the response.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 2, 2026

addedInput schema / properties / body / description

Added value: +"The request body the operation operates on."

addedInput schema / properties / sha256 / description

Added value: +"The SHA-256 hex digest of the artifact being verified."

addedInput schema / properties / signature / description

Added value: +"The Ed25519 signature to verify, base64-encoded."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "as_of": {
+      "description": "The date the answer is computed as of.",
+      "type": "string"
+    },
+    "basis": {
+      "description": "The `basis` field of the response.",
+      "type": "object"
+    },
+    "detail": {
+      "description": "Human-readable explanation of the verdict.",
+      "type": "string"
+    },
+    "hash_valid": {
+      "description": "The `hash_valid` field of the response.",
+      "type": "object"
+    },
+    "note": {
+      "description": "A note on how the answer was produced.",
+      "type": "string"
+    },
+    "recomputed_sha256": {
+      "description": "The `recomputed_sha256` field of the response.",
+      "type": "object"
+    },
+    "recomputed_sha256_as_of": {
+      "description": "The `recomputed_sha256_as_of` field of the response.",
+      "type": "object"
+    },
+    "recomputed_sha256_source": {
+      "description": "The `recomputed_sha256_source` field of the response.",
+      "type": "object"
+    },
+    "signature_valid": {
+      "description": "The `signature_valid` field of the response.",
+      "type": "object"
+    },
+    "source": {
+      "description": "The `source` field of the response.",
+      "type": "object"
+    },
+    "valid": {
+      "description": "Whether the artifact verified.",
+      "type": "boolean"
+    },
+    "verdict": {
+      "description": "The decision this tool returned.",
+      "type": "string"
+    },
+    "verifiedAt": {
+      "description": "The `verifiedAt` field of the response.",
+      "type": "object"
+    },
+    "verifiedBy": {
+      "description": "The `verifiedBy` field of the response.",
+      "type": "object"
+    }
+  },
+  "required": [
+    "detail",
+    "valid",
+    "verdict"
+  ],
+  "type": "object"
+}

AddedNov 1, 2026

TDQS

C2.4/5.0

Behavior2/5

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

Annotations already state readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds little beyond 'independently re-check' and does not explain what registration state is required, what independence means here, or what the recheck validates.

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 description is short but malformed, with an incomplete possessive and a stray 'part of the surface.' It also mentions a 14-field return object that the output schema already covers, so that sentence does not earn its place.

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?

The output schema and annotations carry much of the structured context, but the description remains too garbled to explain the tool's scope, prerequisites, or what the recheck is for. For a verification tool with three parameters, that leaves important context gaps.

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 body, sha256, and signature are already documented in the schema. The description adds no parameter-specific meaning beyond the schema baseline.

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

Purpose3/5

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

The description names a specific verb and resource: 'independently re-check a registered verify-catalog receipt.' However, the sentence is grammatically broken ('receipt's'), and it does not clearly distinguish this tool from nearby verification or registration siblings such as register_verification_catalog.

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?

It implies rechecking a registered receipt but gives no explicit conditions for when to use this tool instead of alternatives, no prerequisites for registration, and no when-not 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.