Synthex Forge — x402 Paid Agent Services

Check Licence Status

check_licence_status

Read-onlyIdempotent

Licence Check. use it rather than check_compliance_status for licence status, not compliance status; an object with 19 fields including algorithm, answerCore. $0.1 USDC.

Input Schema

Name	Required	Description
`dataset`	Yes	The dataset the question is about, e.g. 'OANDA v20 candles'.
`intended_use`	Yes	What you intend to do with the data. One of: analyse, embed, aggregate, display, redistribute, resell, train.
`jurisdiction`	No	The jurisdiction the use happens in, e.g. 'EU'. Recorded on the signed record; corpus v1 does not vary by jurisdiction.
`licence_spdx`	No	The licence under which the data is held, as an SPDX id (MIT, Apache-2.0, GPL-3.0, CC-BY-NC-4.0, proprietary-vendor-tos, ...). OPTIONAL: if omitted, the dataset is matched against the corpus aliases; an unmatched dataset returns verdict 'unknown' with a named coverage gap — never a guess.

Output Schema

Name	Required	Description
`basis`	No	The `basis` field of the response.
`key_id`	No	The `key_id` field of the response.
`clauses`	No	The `clauses` field of the response.
`verdict`	Yes	The decision this tool returned.
`issuedAt`	No	The `issuedAt` field of the response.
`algorithm`	No	The `algorithm` field of the response.
`signature`	Yes	The Ed25519 signature over the evidence core, base64-encoded.
`answerCore`	No	The `answerCore` field of the response.
`conditions`	No	The `conditions` field of the response.
`obligations`	No	The `obligations` field of the response.
`share_alike`	No	The `share_alike` field of the response.
`publicKeyHex`	No	The `publicKeyHex` field of the response.
`rules_sha256`	No	The `rules_sha256` field of the response.
`corpusVersion`	No	The `corpusVersion` field of the response.
`coverage_gaps`	No	The `coverage_gaps` field of the response.
`output_sha256`	Yes	SHA-256 hex digest of the canonical evidence core.
`attribution_required`	No	The `attribution_required` field of the response.
`commercial_use_allowed`	No	The `commercial_use_allowed` field of the response.
`redistribution_allowed`	No	The `redistribution_allowed` field of the response.

Schema Changelog

Changes observed during successful MCP inspections.

Changed21 schema fields changedOct 31, 2026

addedOutput schema / properties / algorithm

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

addedOutput schema / properties / answerCore

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

addedOutput schema / properties / attribution_required

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

addedOutput schema / properties / basis

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

addedOutput schema / properties / clauses

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

addedOutput schema / properties / commercial_use_allowed

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

addedOutput schema / properties / conditions

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

addedOutput schema / properties / corpusVersion

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

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

addedOutput schema / properties / key_id

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

addedOutput schema / properties / obligations

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

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

addedOutput schema / properties / redistribution_allowed

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

addedOutput schema / properties / rules_sha256

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

addedOutput schema / properties / share_alike

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

addedOutput schema / properties / signature

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

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: +[
+  "output_sha256",
+  "signature",
+  "verdict"
+]

AddedOct 31, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description adds two genuinely new facts beyond that: a price of $0.1 USDC and the response shape (19 fields including algorithm/answerCore), which is useful for cost-aware planning.

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?

It is short and the routing rule is front-loaded, but 'Licence Check.' is redundant with the name/title and the '19 fields including algorithm, answerCore' fragment is noisy when a full output schema exists. The phrasing is clipped to the point of being cryptic.

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, return values needn't be explained, and the description still flags cost and the existence of a verdict-bearing object. Combined with schema coverage of the unknown/corpus-gap behavior, an agent has enough to invoke it correctly; only pricing/rate semantics beyond the flat fee are unaddressed.

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 all four parameters (including the optional licence_spdx alias-matching and the unknown-verdict behavior) are already documented in the schema. The description adds no parameter-level detail, so the baseline 3 applies.

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 identifies the resource (licence status) and explicitly separates it from the nearest sibling, `check_compliance_status`. The verb is only 'Check' and the opening 'Licence Check' largely restates the tool name, so it stops short of a fully specific verb+resource statement, but the sibling contrast makes the purpose unambiguous.

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 an explicit routing rule: use this rather than `check_compliance_status` when the question is licence status, not compliance status. There is no guidance on when licence checking is not appropriate or what to do alongside `verify_licence_status`, but the primary selection decision is covered.

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.