Synthex Forge — x402 Paid Agent Services

Issue Attestation

issue_attestation

Destructive

Sign and SHA-256-hash an arbitrary claim/record into a. use it rather than issue_attestation_receipt for attestation, not attestation receipt; an object with 14 fields including algorithm, attestation. $0.25 USDC.

Input Schema

Name	Required	Description	Default
`claim`	Yes	The claim this operation operates on. See the schema for its type and whether it is required.
`claim_type`	No	The claim type this operation operates on. See the schema for its type and whether it is required.	track-record

Output Schema

Name	Required	Description
`kind`	No	The `kind` field of the response.
`note`	No	A note on how the answer was produced.
`claim`	No	The `claim` field of the response.
`detail`	Yes	Human-readable explanation of the verdict.
`sha256`	No	The `sha256` field of the response.
`signedBy`	No	The `signedBy` field of the response.
`algorithm`	No	The `algorithm` field of the response.
`signature`	Yes	The Ed25519 signature over the evidence core, base64-encoded.
`attestedAt`	No	The `attestedAt` field of the response.
`attestation`	No	The `attestation` field of the response.
`publicKeyHex`	No	The `publicKeyHex` field of the response.
`canonicalSha256`	No	The `canonicalSha256` field of the response.
`reproducibility`	No	The `reproducibility` field of the response.
`verificationHint`	No	The `verificationHint` field of the response.

Schema Changelog

Changes observed during successful MCP inspections.

Changed16 schema fields changedOct 31, 2026

addedOutput schema / properties / algorithm

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

addedOutput schema / properties / attestation

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

addedOutput schema / properties / attestedAt

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

addedOutput schema / properties / canonicalSha256

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

addedOutput schema / properties / claim

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

addedOutput schema / properties / detail

Added value: +{
+  "description": "Human-readable explanation of the verdict.",
+  "type": "string"
+}

addedOutput schema / properties / kind

Added value: +{
+  "description": "The `kind` 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 / publicKeyHex

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

addedOutput schema / properties / reproducibility

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

addedOutput schema / properties / sha256

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

addedOutput schema / properties / signature

Added value: +{
+  "description": "The Ed25519 signature over the evidence core, base64-encoded.",
+  "type": "string"
+}

addedOutput schema / properties / signedBy

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

removedOutput schema / properties / status

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

addedOutput schema / properties / verificationHint

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

addedOutput schema / required

Added value: +[
+  "detail",
+  "signature"
+]

AddedOct 31, 2026

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false, so the safety profile is covered. The description adds genuinely new behavioral context — a $0.25 USDC cost, i.e. a paid/charged operation — which the annotations do not convey. It does not, however, explain why the operation is flagged destructive (permanence of the signed record) or what happens to any prior attestation, so it only partly extends the annotation layer.

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?

It is short, but short here is the result of truncation and compression, not editing: "into a." is a dangling fragment, and the middle clause is a run-on that merges the routing advice with the return-value description. The cost, arguably the most decision-relevant fact, is buried as a trailing fragment.

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?

An output schema exists and is partly echoed (14 fields, algorithm, attestation), annotations cover the mutation/idempotency profile, and the description adds the two things structured data lacks: which sibling to prefer and the price. For a 2-parameter tool this is enough to call correctly.

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 both parameters are documented structurally and this is the baseline. The description says only "arbitrary claim/record" and adds nothing about claim shape or the claim_type default of "track-record" — but with full schema coverage, marginal added meaning is acceptable.

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 verb pair (sign, SHA-256-hash) and resource (arbitrary claim/record) producing an attestation, and explicitly disambiguates from the sibling issue_attestation_receipt. It loses a point because the sentence is truncated ("into a.") and the output noun is only recovered later from "an object with 14 fields".

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?

"use it rather than `issue_attestation_receipt` for attestation, not attestation receipt" does route the agent away from one specific sibling, which is more than nothing. However, it gives no conditions for when an attestation is actually warranted, no mention of the many other attestation siblings (issue_decision_attestation, issue_delivery_attestation, etc.), and the phrasing is circular enough to be only weakly actionable.

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.