Skip to main content
Glama
Sign In

x402 Pay — USDC API Payment Helper

by com.scriptmasterlabs
OverviewDiscussionsAdmin

Server Details

Pay for APIs with USDC. Read-only x402 payment discovery, verification, evidence, and status.

Ownership verified
Status
Healthy
Uptime
98.6% over 61 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
ChatGPT
–
Claude
–

TDQS

A3.7/5.0

Scored across 5 tools

Disambiguation2/5

check_payment and x402_inspect_challenge are explicitly declared to be the same tool with the same schema, so an agent has no basis to choose between them and may waste calls or double-inspect. The remaining three (check_status, list_paid_apis, payment_info) are reasonably distinct, but a fully redundant pair drags the set down.

Naming Consistency3/5

All names use snake_case, but the verb_noun convention only holds for check_payment/check_status/list_paid_apis, while payment_info is noun-only and x402_inspect_challenge mixes a protocol prefix into the pattern. Readable but not predictable.

Tool Count4/5

Five tools is a sensible, tightly scoped surface for a read-only x402 inspection helper. It loses a point only because one of the five is a duplicate alias, leaving four genuinely distinct operations.

Completeness3/5

The surface covers challenge discovery, config hints, route listing and backend readiness, which is coherent for an inspection-only helper. However, the payment lifecycle is a dead end: there is no tool to sign/settle, verify a receipt, or confirm delivery, so an agent cannot close the loop the domain implies.

Available Tools

5 tools
check_paymentCheck PaymentA
Read-onlyIdempotent
Inspect

Inspect a public HTTPS URL for a fresh x402 v2 HTTP 402 challenge using an unsigned GET with a 10-second network timeout and no redirect following. Returns validated payTo, asset, network, atomic amount, resource and maxTimeoutSeconds; incomplete or non-x402 responses return challenge=null and a reason. Does not sign, settle or verify receipts. Fresh requirements override documented receiver hints; inspect canonical_receiver_match before choosing to pay.

NameRequiredDescriptionDefault
urlYesFull public HTTPS URL to inspect with an unsigned GET. No payment headers; redirects, credentials and private network targets are rejected.

Output Schema

NameRequiredDescription
reasonNo
is_x402YesTrue only for HTTP 402 with complete validated x402 v2 requirements.
challengeYesFresh validated requirements, or null. No synthetic defaults are inserted.
http_statusYesObserved HTTP status; zero means no HTTP response was received.
raw_headersNoAllowlisted response headers only; never cookies or authentication headers.
payment_sentYes
missing_fieldsNo
canonical_receiver_matchNoComparison with documented SML receiver; a mismatch never rewrites upstream requirements.

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare the read-only, idempotent, non-destructive profile, yet the description still adds substantial operational context: unsigned GET, 10-second network timeout, no redirect following, and the failure contract (challenge=null plus a reason). That is exactly the beyond-annotations detail an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences, front-loaded with the action and target, then the return contract, then the boundary and decision hint. No filler; every clause carries information.

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, yet the description still summarizes what comes back (payTo, asset, network, amount, resource, maxTimeoutSeconds) and the null-challenge failure mode, plus explicitly states the non-mutating scope. Nothing needed to call it correctly is missing.

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% on the single parameter, so the baseline is 3. The description's 'unsigned GET / no payment headers' framing largely restates what the schema already documents about rejected redirects and credentials, adding little new meaning.

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

Purpose5/5

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

Names a precise verb and resource: 'Inspect a public HTTPS URL for a fresh x402 v2 HTTP 402 challenge', with the specific transport behavior (unsigned GET). The closing sentence ('Does not sign, settle or verify receipts') draws a sharp boundary that separates it from the payment/verification siblings.

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?

Gives real selection guidance: 'Fresh requirements override documented receiver hints; inspect canonical_receiver_match before choosing to pay.' This tells the agent what to do with the result before acting. It does not name a sibling alternative (e.g. x402_inspect_challenge) or state an explicit when-not-to-use condition, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_statusCheck StatusA
Read-onlyIdempotent
Inspect

Read the current SqueezeOS backend status and payment-readiness evidence. Returns both upstream envelopes and autonomous_spend=false. Use to diagnose readiness before purchase; HTTP availability or readiness flags alone do not establish settled or accepted delivery.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
okYes
coreYes
hostingYes
autonomous_spendYes
payment_readinessYes

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so safety is covered. The description adds genuine interpretive context beyond that: it warns that HTTP availability or readiness flags alone do not establish settled or accepted delivery, which is a real caveat about what the output means.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, purpose front-loaded, no filler. The middle sentence about 'upstream envelopes and autonomous_spend=false' is somewhat cryptic and partly redundant given an output schema exists, but the overall size is appropriate.

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 rich annotations and an output schema present, the description only needs to supply purpose, usage, and interpretive caveats, all of which are covered. Nothing an agent strictly needs to invoke a zero-arg read tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4. There is no parameter surface for the description to explain and none is needed.

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?

States a specific verb and resource ('Read the current SqueezeOS backend status and payment-readiness evidence'), so the agent knows it is a status-read tool. It does not explicitly distinguish itself from the closely related sibling check_payment, leaving some ambiguity about which readiness endpoint to call.

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 to diagnose readiness before purchase' gives clear usage context, but no when-not conditions and no routing against siblings like check_payment or payment_info, which are adjacent in purpose. The agent must infer the boundary itself.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_paid_apisList Paid ApisA
Read-onlyIdempotent
Inspect

List paid API operations declared by the live SqueezeOS OpenAPI document, bounded by limit. Returns method, path, job and advertised price. Use for route selection, then inspect that resource's fresh 402 challenge; listed prices do not authorize payment.

NameRequiredDescriptionDefault
limitNoMaximum number of declared paid operations to return; not an exhaustive catalog count.

Output Schema

NameRequiredDescription
okYes
countYes
sourceYes
operationsYes

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely non-obvious context: the catalog comes from a live document, results are bounded, and listed prices do not authorize payment. That payment caveat materially affects downstream behavior, though nothing is said about rate limits or catalog staleness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with what the tool lists and what it returns, followed by usage and the payment caveat. No filler or restatement of the title.

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?

For a single-parameter read tool with a full schema, complete annotations and an output schema, the description supplies everything needed: data source, bound, return shape and the critical caveat that listed prices are not authorization to pay.

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 coverage is 100% and the single limit parameter is documented with default, min, max and a note that it is not a catalog count. The description's "bounded by limit" adds no syntax or format detail beyond what the schema already provides, so the baseline 3 applies.

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

Purpose5/5

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

States a specific verb and resource (list paid API operations) and an explicit source (the live SqueezeOS OpenAPI document), plus the returned fields (method, path, job, advertised price). An agent can distinguish it from check_payment/payment_info/x402_inspect_challenge without opening any schema.

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?

"Use for route selection, then inspect that resource's fresh 402 challenge" gives a clear when-to-use and names the follow-up step that corresponds to the sibling x402_inspect_challenge. It stops short of naming the alternative tool directly or stating exclusions, so it is strong but not fully explicit routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

payment_infoPayment InfoA
Read-onlyIdempotent
Inspect

Read the documented SML x402 v2 Base/USDC configuration and receiver before selecting a paid route. Returns configuration and a read-only policy. Fresh resource requirements override these hints; this tool does not sign, spend or prove settlement.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
assetYes
pay_toYes
policyYes
networkYes
productYes
protocolYes
asset_contractYes

TDQS

A4/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 behavior, and the description adds real value beyond them: it explicitly disclaims signing, spending, and settlement proving, and discloses that the returned hints may be stale relative to fresh resource requirements. No auth or rate-limit context, but the scope limitations are the right disclosure for this tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense sentences, front-loaded with what is read and returned, then the override caveat. No filler, though the x402/Base/USDC jargon load makes it slightly heavy for a zero-parameter read.

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 need no prose explanation, and the description still covers the two things the schema cannot: the staleness caveat and the explicit non-signing/non-settlement boundary. Complete for a zero-param read tool, with only cross-tool routing left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4 per the rubric. The description correctly adds no parameter guidance and there are no parameters to clarify.

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?

States a specific verb (Read) and resource (SML x402 v2 Base/USDC configuration and receiver) and clarifies what it returns (configuration plus a read-only policy). It doesn't name any sibling explicitly, but the phrase 'before selecting a paid route' positions it against check_payment/list_paid_apis in the workflow.

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?

Gives clear usage timing ('before selecting a paid route') and an important exclusion rule ('Fresh resource requirements override these hints'), which tells the agent when not to trust this output. It stops short of naming which sibling to call instead for signing, spending, or settlement proof.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

x402_inspect_challengeX402 Inspect ChallengeA
Read-onlyIdempotent
Inspect

Inspect a fresh x402 v2 challenge without sending payment. Compatible alias of check_payment with the same schema, 10-second unsigned probe and result. Use before a paid resource call; do not use as a signer, receipt verifier or settlement proof. Non-402 and incomplete challenges remain null rather than receiving invented defaults.

NameRequiredDescriptionDefault
urlYesFull public HTTPS URL to inspect with an unsigned GET. No payment headers; redirects, credentials and private network targets are rejected.

Output Schema

NameRequiredDescription
reasonNo
is_x402YesTrue only for HTTP 402 with complete validated x402 v2 requirements.
challengeYesFresh validated requirements, or null. No synthetic defaults are inserted.
http_statusYesObserved HTTP status; zero means no HTTP response was received.
raw_headersNoAllowlisted response headers only; never cookies or authentication headers.
payment_sentYes
missing_fieldsNo
canonical_receiver_matchNoComparison with documented SML receiver; a mismatch never rewrites upstream requirements.

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, yet the description still adds real behavioral context: a 10-second unsigned probe, no payment headers, and null-rather-than-invented-defaults for non-402 or incomplete challenges. It stops short of stating rate limits or permission requirements, so it is strong but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then alias relationship, then allowed/forbidden usage, then result semantics — a logical ordering with no filler sentences. The phrase '10-second unsigned probe and result' is slightly compressed, but nothing is wasted.

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, so return-value detail is not required, yet the description still covers the key edge case (null for non-402/incomplete challenges). Combined with a fully documented single parameter and safety annotations, an agent has everything needed to call it 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% for the single 'url' parameter, which already documents HTTPS-only, unsigned GET, and rejection of redirects/credentials/private targets. The description adds no parameter syntax or format detail beyond that, so the baseline of 3 applies.

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

Purpose5/5

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

States a specific verb and resource ('Inspect a fresh x402 v2 challenge') plus the critical scope constraint that no payment is sent. It also identifies itself as a compatible alias of the sibling check_payment, so an agent can differentiate it without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit positive guidance ('Use before a paid resource call') and explicit exclusions ('do not use as a signer, receipt verifier or settlement proof'), plus the alias relationship to check_payment. Both the when and the when-not are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 5 tool updates
    • Changedcheck_payment4 fields changed
      • addedInput schema / properties / url / description
        Added value: +"Full public HTTPS URL to inspect with an unsigned GET. No payment headers; redirects, credentials and private network targets are rejected."
      • addedInput schema / properties / url / format
        Added value: +"uri"
      • addedInput schema / properties / url / pattern
        Added value: +"^https://"
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "allOf": [
+    {
+      "else": {
+        "properties": {
+          "challenge": {
+            "type": "null"
+          }
+        }
+      },
+      "if": {
+        "properties": {
+          "is_x402": {
+            "const": true
+          }
+        }
+      },
+      "then": {
+        "properties": {
+          "challenge": {
+            "additionalProperties": false,
+            "properties": {
+              "amount": {
+                "pattern": "^[0-9]+$",
+                "type": "string"
+              },
+              "asset": {
+                "description": "Asset identifier from the fresh requirements; never replaced with a cached symbol.",
+                "minLength": 1,
+                "type": "string"
+              },
+              "maxTimeoutSeconds": {
+                "maximum": 3600,
+                "minimum": 1,
+                "type": "integer"
+              },
+              "network": {
+                "minLength": 1,
+                "type": "string"
+              },
+              "payTo": {
+                "pattern": "^0x[a-fA-F0-9]{40}$",
+                "type": "string"
+              },
+              "resource": {
+                "description": "Exact resource URL or identifier advertised by the endpoint.",
+                "minLength": 1,
+                "type": "string"
+              },
+              "scheme": {
+                "description": "Payment scheme advertised by the fresh requirement.",
+                "minLength": 1,
+                "type": "string"
+              },
+              "x402Version": {
+                "const": 2
+              }
+            },
+            "required": [
+              "x402Version",
+              "scheme",
+              "payTo",
+              "asset",
+              "network",
+              "amount",
+              "resource",
+              "maxTimeoutSeconds"
+            ],
+            "type": "object"
+          },
+          "http_status": {
+            "const": 402
+          }
+        }
+      }
+    }
+  ],
+  "properties": {
+    "canonical_receiver_match": {
+      "description": "Comparison with documented SML receiver; a mismatch never rewrites upstream requirements.",
+      "type": "boolean"
+    },
+    "challenge": {
+      "description": "Fresh validated requirements, or null. No synthetic defaults are inserted.",
+      "oneOf": [
+        {
+          "additionalProperties": false,
+          "properties": {
+            "amount": {
+              "pattern": "^[0-9]+$",
+              "type": "string"
+            },
+            "asset": {
+              "description": "Asset identifier from the fresh requirements; never replaced with a cached symbol.",
+              "minLength": 1,
+              "type": "string"
+            },
+            "maxTimeoutSeconds": {
+              "maximum": 3600,
+              "minimum": 1,
+              "type": "integer"
+            },
+            "network": {
+              "minLength": 1,
+              "type": "string"
+            },
+            "payTo": {
+              "pattern": "^0x[a-fA-F0-9]{40}$",
+              "type": "string"
+            },
+            "resource": {
+              "description": "Exact resource URL or identifier advertised by the endpoint.",
+              "minLength": 1,
+              "type": "string"
+            },
+            "scheme": {
+              "description": "Payment scheme advertised by the fresh requirement.",
+              "minLength": 1,
+              "type": "string"
+            },
+            "x402Version": {
+              "const": 2
+            }
+          },
+          "required": [
+            "x402Version",
+            "scheme",
+            "payTo",
+            "asset",
+            "network",
+            "amount",
+            "resource",
+            "maxTimeoutSeconds"
+          ],
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "http_status": {
+      "description": "Observed HTTP status; zero means no HTTP response was received.",
+      "maximum": 599,
+      "minimum": 0,
+      "type": "integer"
+    },
+    "is_x402": {
+      "description": "True only for HTTP 402 with complete validated x402 v2 requirements.",
+      "type": "boolean"
+    },
+    "missing_fields": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "payment_sent": {
+      "const": false
+    },
+    "raw_headers": {
+      "additionalProperties": {
+        "type": "string"
+      },
+      "description": "Allowlisted response headers only; never cookies or authentication headers.",
+      "type": "object"
+    },
+    "reason": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "is_x402",
+    "http_status",
+    "challenge",
+    "payment_sent"
+  ],
+  "type": "object"
+}
    • Changedcheck_status1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "autonomous_spend": {
+      "const": false
+    },
+    "core": {
+      "additionalProperties": true,
+      "properties": {
+        "body": {
+          "description": "Exact upstream JSON or a bounded text excerpt; missing evidence is not filled in."
+        },
+        "ok": {
+          "description": "Whether the selected upstream returned HTTP 2xx; not settlement proof.",
+          "type": "boolean"
+        },
+        "payment_required": {
+          "type": "boolean"
+        },
+        "source": {
+          "description": "The queried local upstream path.",
+          "type": "string"
+        },
+        "status_code": {
+          "type": "integer"
+        }
+      },
+      "required": [
+        "ok",
+        "status_code",
+        "source",
+        "body",
+        "payment_required"
+      ],
+      "type": "object"
+    },
+    "hosting": {
+      "type": "string"
+    },
+    "ok": {
+      "type": "boolean"
+    },
+    "payment_readiness": {
+      "additionalProperties": true,
+      "properties": {
+        "body": {
+          "description": "Exact upstream JSON or a bounded text excerpt; missing evidence is not filled in."
+        },
+        "ok": {
+          "description": "Whether the selected upstream returned HTTP 2xx; not settlement proof.",
+          "type": "boolean"
+        },
+        "payment_required": {
+          "type": "boolean"
+        },
+        "source": {
+          "description": "The queried local upstream path.",
+          "type": "string"
+        },
+        "status_code": {
+          "type": "integer"
+        }
+      },
+      "required": [
+        "ok",
+        "status_code",
+        "source",
+        "body",
+        "payment_required"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "ok",
+    "hosting",
+    "core",
+    "payment_readiness",
+    "autonomous_spend"
+  ],
+  "type": "object"
+}
    • Changedlist_paid_apis2 fields changed
      • addedInput schema / properties / limit / description
        Added value: +"Maximum number of declared paid operations to return; not an exhaustive catalog count."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "count": {
+      "type": "integer"
+    },
+    "ok": {
+      "type": "boolean"
+    },
+    "operations": {
+      "items": {
+        "additionalProperties": true,
+        "properties": {
+          "advertised_price": {},
+          "job": {},
+          "method": {
+            "type": "string"
+          },
+          "path": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "method",
+          "path",
+          "job",
+          "advertised_price"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "source": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "ok",
+    "source",
+    "count",
+    "operations"
+  ],
+  "type": "object"
+}
    • Changedpayment_info1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "asset": {
+      "type": "string"
+    },
+    "asset_contract": {
+      "type": "string"
+    },
+    "network": {
+      "type": "string"
+    },
+    "pay_to": {
+      "pattern": "^0x[a-fA-F0-9]{40}$",
+      "type": "string"
+    },
+    "policy": {
+      "type": "object"
+    },
+    "product": {
+      "type": "string"
+    },
+    "protocol": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "product",
+    "protocol",
+    "network",
+    "asset",
+    "asset_contract",
+    "pay_to",
+    "policy"
+  ],
+  "type": "object"
+}
    • Addedx402_inspect_challenge
  2. 4 tool updates
    • First observedcheck_payment
    • First observedcheck_status
    • First observedlist_paid_apis
    • First observedpayment_info

Related MCP Connectors

Related MCP Servers

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.

Resources