Synthex Forge — x402 Paid Agent Services

Create Bio Audit Receipt

create_bio_audit_receipt

Destructive

BioTrust Service 06 — mint ONE signed, offline-verifiable receipt. use it rather than verify_bio_audit for bio audit receipt, not bio audit; an object with 18 fields including check_type, created_at. $0.25 USDC.

Input Schema

Name	Required	Description
`inputs`	No	The inputs this operation operates on. See the schema for its type and whether it is required.
`subject`	No	The subject the operation is applied to — an id, a URL or a name, depending on the operation.
`check_type`	No	The check type this operation operates on. See the schema for its type and whether it is required.
`requested_at`	No	The requested at this operation operates on. See the schema for its type and whether it is required.
`policy_version`	No	Version of the policy the decision is bound to.
`service_version`	No	The service version this operation operates on. See the schema for its type and whether it is required.
`outcome_category`	No	The outcome category this operation operates on. See the schema for its type and whether it is required.

Output Schema

Name	Required	Description
`kind`	No	The `kind` field of the response.
`error`	No	The machine-readable error code, when the operation failed.
`detail`	Yes	Human-readable explanation of the verdict.
`receipt`	No	The `receipt` field of the response.
`subject`	No	The `subject` field of the response.
`signature`	Yes	The Ed25519 signature over the evidence core, base64-encoded.
`signed_by`	No	The key id that signed the answer.
`check_type`	No	The `check_type` field of the response.
`created_at`	No	The `created_at` field of the response.
`receipt_id`	No	The `receipt_id` field of the response.
`requested_at`	No	The `requested_at` field of the response.
`subject_hash`	No	The `subject_hash` field of the response.
`inputs_sha256`	No	The `inputs_sha256` field of the response.
`output_sha256`	Yes	SHA-256 hex digest of the canonical evidence core.
`policy_version`	No	The `policy_version` field of the response.
`service_version`	No	The `service_version` field of the response.
`outcome_category`	No	The `outcome_category` field of the response.
`methodology_version`	No	Version of the method that produced the answer.

Schema Changelog

Changes observed during successful MCP inspections.

Changed20 schema fields changedOct 31, 2026

addedOutput schema / properties / check_type

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

addedOutput schema / properties / created_at

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

addedOutput schema / properties / detail

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

addedOutput schema / properties / error

Added value: +{
+  "description": "The machine-readable error code, when the operation failed.",
+  "type": "string"
+}

addedOutput schema / properties / inputs_sha256

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

addedOutput schema / properties / kind

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

addedOutput schema / properties / methodology_version

Added value: +{
+  "description": "Version of the method that produced the answer.",
+  "type": "string"
+}

addedOutput schema / properties / outcome_category

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

addedOutput schema / properties / output_sha256

Added value: +{
+  "description": "SHA-256 hex digest of the canonical evidence core.",
+  "type": "string"
+}

addedOutput schema / properties / policy_version

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

addedOutput schema / properties / receipt

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

addedOutput schema / properties / receipt_id

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

addedOutput schema / properties / requested_at

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

addedOutput schema / properties / service_version

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

Added value: +{
+  "description": "The key id that signed the answer.",
+  "type": "string"
+}

removedOutput schema / properties / status

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

addedOutput schema / properties / subject

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

addedOutput schema / properties / subject_hash

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

addedOutput schema / required

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

AddedOct 31, 2026

TDQS

B3.3/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, and openWorldHint=false. The description adds genuinely useful context the annotations don't carry: a price point ('$0.25 USDC') and the property 'offline-verifiable'. However, it never explains what the destructiveHint=true implies (irreversibility, resource consumption) nor any auth/permission prerequisites, so behavioral disclosure is partial.

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?

Three dense, front-loaded sentences with no filler, which is good, but the middle sentence is syntactically mangled ('use it rather than `verify_bio_audit` for bio audit receipt, not bio audit') and forces the reader to re-parse. The field-count and price fragments are tacked on rather than integrated.

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?

An output schema exists, so omitting return-value explanation is fine, and annotations carry the safety profile. But with 7 all-optional parameters and no required inputs, the definition never clarifies which inputs actually matter to mint a meaningful receipt, leaving a real gap for a tool that costs money per call.

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 the baseline is 3, and the description does not expand on any parameter (it only names `check_type`, which is a field of the returned object, not input guidance). The schema's own descriptions are largely boilerplate ('See the schema for its type and whether it is required'), so no added semantic value is provided at either layer.

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 verb+resource are specific: 'mint ONE signed, offline-verifiable receipt' tells an agent exactly what is produced and that it is a single artifact. It also names a sibling (`verify_bio_audit`) to distinguish against, though the phrase 'for bio audit receipt, not bio audit' is garbled and blunts the differentiation.

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 attempts a routing statement ('use it rather than `verify_bio_audit`') but the qualifier 'for bio audit receipt, not bio audit' is ambiguous and gives no clear condition for when minting is appropriate versus verifying. Usage is implied by the 'mint vs verify' framing rather than stated as a concrete when/when-not rule.

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.