Synthex Forge — x402 Paid Agent Services

Run Bureau Audit

run_bureau_audit

Read-onlyIdempotent

x402 Bureau — full conformance audit of any endpoint. use it rather than check_bureau_receipt for bureau audit, not bureau receipt; an object with 31 fields including algorithm, blocked. $0.25 USDC.

Input Schema

Name	Required	Description	Default
`url`	Yes	The URL to fetch, verify or route to.

Output Schema

Name	Required	Description
`id`	No	The `id` field of the response.
`ts`	No	The `ts` field of the response.
`note`	No	A note on how the answer was produced.
`title`	No	The `title` field of the response.
`value`	No	The `value` field of the response.
`clause`	No	The `clause` field of the response.
`detail`	Yes	Human-readable explanation of the verdict.
`sha256`	No	The `sha256` field of the response.
`target`	No	The `target` field of the response.
`blocked`	No	The `blocked` field of the response.
`network`	No	The `network` field of the response.
`outcome`	No	The `outcome` field of the response.
`verdict`	Yes	The decision this tool returned.
`evidence`	No	The `evidence` field of the response.
`severity`	No	The `severity` field of the response.
`algorithm`	No	The `algorithm` field of the response.
`instrument`	No	The `instrument` field of the response.
`public_key`	No	The `public_key` field of the response.
`recognised`	No	The `recognised` field of the response.
`supersedes`	No	The `supersedes` field of the response.
`finding_ids`	No	The `finding_ids` field of the response.
`observed_at`	No	The `observed_at` field of the response.
`signed_over`	No	The `signed_over` field of the response.
`coverage_gaps`	No	The `coverage_gaps` field of the response.
`report_sha256`	No	The `report_sha256` field of the response.
`signature_alg`	No	The `signature_alg` field of the response.
`guards_against`	No	The `guards_against` field of the response.
`standard_version`	No	The `standard_version` field of the response.
`network_recognised`	No	The `network_recognised` field of the response.
`network_verifiable`	No	The `network_verifiable` field of the response.
`independently_verifiable`	No	The `independently_verifiable` field of the response.

Schema Changelog

Changes observed during successful MCP inspections.

Changed33 schema fields changedOct 31, 2026

addedOutput schema / properties / algorithm

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

addedOutput schema / properties / blocked

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

addedOutput schema / properties / clause

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

addedOutput schema / properties / coverage_gaps

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

addedOutput schema / properties / detail

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

addedOutput schema / properties / evidence

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

addedOutput schema / properties / finding_ids

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

addedOutput schema / properties / guards_against

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

addedOutput schema / properties / id

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

addedOutput schema / properties / independently_verifiable

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

addedOutput schema / properties / instrument

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

addedOutput schema / properties / network

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

addedOutput schema / properties / network_recognised

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

addedOutput schema / properties / network_verifiable

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

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

addedOutput schema / properties / outcome

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

addedOutput schema / properties / public_key

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

addedOutput schema / properties / recognised

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

addedOutput schema / properties / report_sha256

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

addedOutput schema / properties / severity

Added value: +{
+  "description": "The `severity` 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_alg

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

addedOutput schema / properties / signed_over

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

addedOutput schema / properties / standard_version

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

removedOutput schema / properties / status

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

addedOutput schema / properties / supersedes

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

addedOutput schema / properties / target

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

addedOutput schema / properties / title

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

addedOutput schema / properties / ts

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

addedOutput schema / properties / value

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

addedOutput schema / properties / verdict

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

addedOutput schema / required

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

AddedOct 31, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Beyond the annotations (readOnly=true, idempotent=true, destructive=false), the description adds genuinely useful disclosure — the price ($0.25 USDC) and the output field count ('31 fields including algorithm, blocked'); the read-only framing is consistent with the annotations. However, 'audit any endpoint' implies external URL access while the annotation says openWorldHint=false, a tension worth noting; and it says nothing about failure behavior or what an audit does when the endpoint is unreachable, so it's decent but not complete.

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?

Purpose and the sibling-alternative are front-loaded, which is good. But the sentence is punctuated oddly (a semicolon joining 'not bureau receipt' with 'an object with 31 fields...') and the '31 fields including algorithm, blocked' snippet is redundant with the output schema and cryptic; the description reads as assembled fragments rather than a clean statement.

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?

An output schema exists, so return values needn't be spelled out — and the description correctly focuses on purpose, cost, and the sibling it replaces. For a one-parameter, read-only, idempotent tool with full annotation coverage, that's essentially enough to invoke it correctly; only the missing failure/degenerate-case guidance keeps it from a 5.

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?

The single `url` parameter has 100% schema coverage, so the schema already documents its meaning ('the URL to fetch, verify or route to'). The description adds no syntax, format, or example detail beyond identifying the endpoint being audited; baseline 3 is appropriate when the schema does the heavy lifting.

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 concrete verb and resource — 'full conformance audit of any endpoint' — and explicitly distinguishes this tool from its sibling check_bureau_receipt, so an agent can tell the two apart. However, the trailing fragment 'an object with 31 fields including algorithm, blocked' is confusing (it describes output, not purpose) and the phrasing is somewhat fragmented, keeping it below 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?

It gives explicit routing guidance: 'use it rather than `check_bureau_receipt` for bureau audit, not bureau receipt,' which names the competing tool and the condition that selects this one. What's missing is any guidance on when this tool should NOT be used (e.g., preconditions), but the alternative routing is unusually clear for this dimension.

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.