XGuard — Payment Decision & Discovery

Name: XGuard — Payment Decision & Discovery
Author: moelayyan90

Server Details

Payment decisions, durable evidence, x402 resource discovery and live gateway status for AI agents.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 58.1% over 40 days
Last Tested: 2026-09-26 18:17
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: moelayyan90/XGuard
GitHub Stars: 0
Server Listing: XGuard Secretless Agent Gateway

TDQS

B3.3/5.0

Scored 2026-09-21 07:40 across 8 tools

Disambiguation3/5

Most tools occupy distinct lifecycle stages (discover, quote, preflight, get_result, verify_receipt, status), but xguard_execute and xguard_secretless_call both describe executing/calling provider operations, and their descriptions only partially clarify which flow to use. The overlap makes misselection possible.

Naming Consistency3/5

All tools share the xguard_ prefix and snake_case, but the naming pattern is inconsistent: discover/execute/get_result/verify_receipt are imperative verb phrases, while preflight/quote/status/secretless_call are nouns or modifier-noun phrases. The set is readable but lacks a uniform verb_noun convention.

Tool Count4/5

With 8 tools, the count is within the ideal 3-15 range and covers the payment decision lifecycle without feeling bloated. However, the overlapping execution tools keep it from being perfectly scoped.

Completeness4/5

The surface covers discovery, pricing/quoting, preflight validation, execution, result recovery, receipt verification, and status, so the core lifecycle is present. Notable gaps like listing past transactions or managing credits may be outside the stated scope.

Available Tools

8 tools

xguard_discoverA

Read-onlyIdempotent

Inspect

Find the paid API catalog and buying instructions, plus explicit provider operations and input schemas.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior3/5

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the tool returns a catalog and input schemas, which is useful but does not disclose additional behavioral traits such as authentication requirements, rate limits, or what happens if the paid catalog is empty. With annotations already covering safety, a score of 3 is appropriate.

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?

The description is a single, well-structured sentence that front-loads the core action ('Find the paid API catalog and buying instructions') and then lists additional outputs. There is no filler or redundant wording, making it highly concise without loss of meaning.

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?

Given that the tool has no parameters, annotations cover safety traits, and there is no output schema, the description sufficiently states what the tool returns. It could mention a prerequisite (e.g., authentication required to access the catalog) but for a discovery tool with no inputs, this is a minor omission. The tool is otherwise complete for an agent to call correctly.

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 has zero parameters, so there is nothing to explain. Per the rubric, a tool with 0 parameters receives a baseline of 4. The description adds no parameter information, which is expected and adequate.

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 clearly states the tool's purpose: it finds the paid API catalog, buying instructions, provider operations, and input schemas. It specifies a concrete resource and what it returns, but it does not explicitly differentiate this discovery tool from the sibling tools (e.g., xguard_execute, xguard_quote), which is a minor gap in clarity.

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

Usage Guidelines2/5

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

The description gives no guidance on when to use this tool versus alternatives. It does not say whether to use this before calling other tools, or to discover what APIs are available. The absence of usage context or routing instructions leaves the agent to infer when xguard_discover is the right choice among its many siblings.

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

xguard_executeC

Destructive

Inspect

Execute an explicit scoped provider operation, or a supported public-source outcome. intent:demo is free. Never infer a mutation from ambiguous text.

ParametersJSON Schema

Name	Required	Description	Default
`input`	No
`intent`	No
`operation`	No
`capability`	No
`idempotency_key`	No

TDQS

C2.6/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false; the description adds a useful behavioral guardrail ('never infer a mutation') and a cost hint ('intent:demo is free'). However, it does not disclose what side effects may occur, what resources are affected, or any permission/authorization requirements.

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?

The description is short and every sentence adds some value: the purpose statement, the free-demo hint, and the mutation caution. The first sentence is ambiguous, but the structure is front-loaded and compact.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, open-world tool with 5 unrequired parameters, no output schema, and 7 siblings, the description provides almost no information needed to invoke it correctly. There is no parameter guidance, no sibling differentiation, and no explanation of what a 'public-source outcome' is.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate for the 5 undocumented parameters. It only hints at 'intent:demo' and the need for explicit operations, leaving operation, capability, input, and idempotency_key undefined. This is insufficient for an agent to construct a valid call.

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

Purpose3/5

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

States it executes an operation or outcome, but 'scoped provider operation' and 'supported public-source outcome' are vague and jargon-heavy. It does not differentiate from siblings like xguard_secretless_call or xguard_preflight, leaving the agent to guess what this tool specifically covers.

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

Usage Guidelines2/5

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

Offers a caution about not inferring mutations and notes intent:demo is free, but gives no explicit guidance on when to use this tool versus alternatives, no prerequisites, and no examples. The 'never infer a mutation' rule is a safety guardrail, not a usage selector.

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

xguard_get_resultA

Read-onlyIdempotent

Inspect

Recover a paid public outcome with its payment identifier and original signed quote without execution or another payment.

ParametersJSON Schema

Name	Required	Description	Default
`quote`	Yes
`payment_identifier`	Yes

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds that recovery does not trigger execution or a new payment, which is useful, but it does not disclose additional behavioral details such as failure modes or conditions for a quote being valid.

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?

The description is a single front-loaded sentence with no filler. Every phrase carries meaning: 'paid', 'with its payment identifier and original signed quote', and 'without execution or another payment' all add necessary constraints.

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?

For a read-only retrieval tool with two required string parameters and no output schema, the description covers the key invocation decision: the outcome is already paid and should be recovered without re-executing. It could add more about return value shape or preconditions like obtaining the signed quote, but the description is sufficiently complete for correct invocation.

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 0%, so the description carries the burden of explaining the parameters. It does name both required inputs ('payment identifier' and 'original signed quote'), mapping to payment_identifier and quote, and adds the nuance that the quote must be signed. However, it does not describe formats, provenance, or how these values are obtained.

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?

The description uses a specific verb ('Recover') and a specific resource ('a paid public outcome'), and states the exact inputs ('payment identifier and original signed quote'). It also distinguishes the operation from execution or another payment, which differentiates it from siblings like xguard_execute and xguard_quote.

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?

The phrase 'without execution or another payment' conveys when to use this tool: only to retrieve an already-paid outcome, not to initiate or pay for execution. It does not explicitly name alternative sibling tools, but the contextual constraint is clear enough for routing.

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

xguard_preflightA

Read-onlyIdempotent

Inspect

Inspect validation, scope and remaining capability budget without reserving, billing or executing. Execution rechecks everything.

ParametersJSON Schema

Name	Required	Description	Default
`input`	No
`intent`	No
`operation`	No
`capability`	No
`idempotency_key`	No

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description aligns with these and adds valuable context: that results are not guaranteed through execution ('Execution rechecks everything'), implying preflight results may become stale. No contradiction with annotations.

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?

Two efficient sentences. The first front-loads the core function and its exclusions; the second adds a critical caveat about result validity. Zero wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 unannotated parameters, a nested 'input' object, and no output schema, this description is inadequate. An agent cannot determine what to pass in 'input', what 'operation' or 'capability' mean, or what a response looks like. The high-level purpose is clear but operational detail is missing.

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

Parameters2/5

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

Schema description coverage is 0% across 5 parameters (input, intent, operation, capability, idempotency_key). The description mentions 'validation, scope and remaining capability budget' as high-level concepts but never maps them to parameters or explains what values are expected. With zero schema coverage, the description was expected to compensate but doesn't.

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?

The description uses a specific verb ('Inspect') with clear resources (validation, scope, capability budget) and explicitly states what it does NOT do (reserving, billing, executing). This differentiates it from siblings like xguard_execute and xguard_quote without ambiguity.

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?

The 'without reserving, billing or executing' clause makes the when-to-use clear: for side-effect-free inspection. 'Execution rechecks everything' implies execution is a separate step, but the description doesn't explicitly name the alternative tool (xguard_execute) or state exclusion conditions as directly as it could.

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

xguard_quoteA

Read-onlyIdempotent

Inspect

Inspect XGuard credit pricing for a capability, or obtain a signed x402 quote for a public outcome. Does not execute.

ParametersJSON Schema

Name	Required	Description	Default
`input`	No
`intent`	No
`operation`	No
`capability`	No
`idempotency_key`	No

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint true, idempotentHint true, and destructiveHint false, so the safety profile is covered. The description adds useful behavioral context by clarifying that the tool 'Does not execute' and that the output is a signed x402 quote, which goes beyond the structured annotations.

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?

The description is one tight sentence plus a clarifying fragment. Every word contributes: it states the two modes, mentions the signed quote, and explicitly rules out execution. It is front-loaded with the primary action and contains no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and zero parameter descriptions, the description is too thin for a tool with five parameters and nested objects. It does not explain how the two modes map to parameters, what a successful quote response looks like, or what conditions make the signed quote obtainable.

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

Parameters2/5

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

Schema description coverage is 0%, and none of the five parameters (input, intent, operation, capability, idempotency_key) are explained. The description mentions 'capability' and 'public outcome,' which loosely maps to some parameters, but it does not explain how to construct input, intent, or operation, nor the role of idempotency_key.

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?

The description uses specific verbs and resources: 'Inspect XGuard credit pricing for a capability' and 'obtain a signed x402 quote for a public outcome.' It also differentiates from the executing tool by stating 'Does not execute,' so an agent can tell it apart from siblings like xguard_execute.

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?

The description gives clear context: use this tool when you need credit pricing or a signed x402 quote, and it explicitly says the tool does not execute. It does not name sibling alternatives like xguard_execute directly, but the context is clear enough that an agent can infer when to choose this tool over execution tools.

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

xguard_secretless_callB

Destructive

Inspect

Call an allowed provider operation with a capability. Enforces scope, call/credit budget and billing before server-side credential injection. Writes require idempotency_key.

ParametersJSON Schema

Name	Required	Description
`input`	No
`method`	No
`target`	No
`body_json`	No
`operation`	No
`capability`	Yes	Scoped XGuard capability, never an upstream key.
`idempotency_key`	No

TDQS

B3.1/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=true. The description adds useful behavioral context: it enforces scope, call/credit budget, billing, and server-side credential injection, and notes that writes require idempotency_key. However, it does not detail what happens on budget exhaustion, how errors are surfaced, or the nature of the destructive behavior. It does not contradict annotations.

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?

The description is two sentences and front-loads the core action and constraints. It is concise and every sentence adds information. However, it could be slightly more structured by separating the write requirement from the general behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (7 params, anyOf alternatives, enums, no output schema, destructive annotation), the description is incomplete. It does not explain the two invocation modes (operation+input vs target), how to choose between them, what the response looks like, or how failures/budget issues are reported. The annotations cover safety but not operational semantics.

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

Parameters2/5

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

Schema description coverage is only 14%, so the description must compensate for undocumented parameters. The description only mentions idempotency_key for writes and capability as a scoped credential. It does not explain the distinction between operation+input and target, the role of method, body_json, or how the anyOf alternatives should be chosen. This is a significant gap for a 7-parameter tool.

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 states a specific verb ('Call') and resource ('an allowed provider operation with a capability'), and clarifies that it enforces scope, budget, and billing before credential injection. It does not explicitly differentiate from siblings like xguard_execute, but the mention of 'secretless' and capability-based invocation gives reasonable clarity.

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 implies usage context: use this tool to call provider operations with a capability, and mentions that writes require idempotency_key. However, it does not explicitly state when to use this tool versus xguard_execute or xguard_preflight, nor does it provide exclusions or alternatives. The sibling names suggest related tools, but no routing guidance is given.

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

xguard_statusA

Read-onlyIdempotent

Inspect

Read observed execution/MCP metrics and configuration; empty observations do not imply uptime.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare the tool read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds a useful non-obvious behavioral caveat—'empty observations do not imply uptime'—which helps the agent interpret sparse or empty results correctly. That extra semantic warning is meaningful and not redundant with annotations.

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?

The description is a single sentence with no filler. It front-loads the action and resource before adding the interpretive caveat, making it easy to parse quickly.

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?

For a zero-parameter, annotation-rich read tool, the description covers the main semantic risk with the uptime caveat and identifies what the tool reads. It does not describe output format, but no output schema exists and the annotations already cover the operation's safety profile.

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 has zero parameters and an empty input schema, so there is nothing the description must explain about argument meaning. The baseline of 4 for no-parameter tools applies, and the description appropriately spends no space on parameters.

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 uses a specific verb ('Read and a clearly identified resource ('observed execution/MCP metrics and configuration'), which sets it apart from execution-oriented siblings like xguard_execute. It does not explicitly name alternative tools, but the resource scope is distinct enough that an agent can recognize its purpose.

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

Usage Guidelines2/5

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

There is no explicit guidance about when to use this tool versus sibling tools such as xguard_discover or xguard_get_result. The caveat about empty observations gives interpretation guidance after the fact, but it does not tell the agent when this tool is the right choice.

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

xguard_verify_receiptA

Read-onlyIdempotent

Inspect

Verify a ProofRail proof and optionally its bound x402 receipt and result digest. Signature validity does not prove source truth.

ParametersJSON Schema

Name	Required	Description	Default
`proof`	Yes
`receipt`	No
`result_sha256`	No

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a valuable caveat: 'Signature validity does not prove source truth.' This is important behavioral context beyond the annotations, warning the agent about a common misinterpretation of verification results.

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?

Two sentences with no wasted words. The core action is front-loaded, and the critical caveat is delivered in a short second sentence. Every word earns its place.

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?

For a read-only verification tool with strong annotations, the description is mostly complete. However, with no output schema and 0% parameter coverage, the agent is left without details on what the verification result looks like or how the optional receipt/digest parameters interact with the proof. The caveat about source truth is helpful but does not fully compensate for the missing return-value and parameter semantics.

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 0%, so the description carries the burden of explaining parameters. It mentions 'proof', 'receipt', and 'result digest' but does not explain the format or relationship between them beyond the schema's types. The description adds some semantic context (e.g., receipt and digest are bound to the proof) but not enough to fully compensate for the 0% schema coverage.

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 states a specific verb ('Verify') and resource ('a ProofRail proof'), and mentions the optional bound x402 receipt and result digest. It does not explicitly distinguish itself from siblings, but the verb 'verify' plus the ProofRail-specific resource is clear enough to separate it from execution/discovery tools.

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 implies when to use the tool: when you need to verify a ProofRail proof and optionally its bound receipt/digest. It does not explicitly state when not to use it or name alternatives, but the context is reasonably clear given the sibling names.

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.

6 tool updatesSep 20, 2026

Changedxguard_execute34 fields changed

changedInput schema / additionalProperties
```
Previous value: -falseNew value: +true
```

removedInput schema / description

Removed value: -"Use intent:'demo' for a free result. Paid outcomes accept supported English/Arabic intents with public sources. Unknown jobs return repair guidance; this is not a general-purpose language model."

removedInput schema / properties / action

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

removedInput schema / properties / arguments

Removed value: -{
-  "oneOf": [
-    {
-      "type": "object"
-    },
-    {
-      "description": "JSON-encoded object, as used by tool calls",
-      "type": "string"
-    }
-  ]
-}

removedInput schema / properties / calls
```
Removed value: -{
-  "const": 1
-}
```

removedInput schema / properties / capability / enum

Removed value: -[
-  "extract-preview",
-  "web-extraction",
-  "product-offers",
-  "feed-digest"
-]

removedInput schema / properties / command

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

removedInput schema / properties / desired_action
```
Removed value: -{
-  "type": "string"
-}
```

removedInput schema / properties / function

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "arguments": {
-      "type": [
-        "string",
-        "object"
-      ]
-    },
-    "name": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "name",
-    "arguments"
-  ],
-  "type": "object"
-}

removedInput schema / properties / html

Removed value: -{
-  "maxLength": 12288,
-  "type": "string"
-}

removedInput schema / properties / http

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

addedInput schema / properties / idempotency_key
```
Added value: +{
+  "type": "string"
+}
```

removedInput schema / properties / intent / oneOf

Removed value: -[
-  {
-    "maxLength": 3000,
-    "type": "string"
-  },
-  {
-    "type": "object"
-  }
-]

addedInput schema / properties / intent / type

Added value: +[
+  "string",
+  "object"
+]

removedInput schema / properties / limit

Removed value: -{
-  "maximum": 30,
-  "minimum": 1,
-  "type": "integer"
-}

removedInput schema / properties / max_age_seconds

Removed value: -{
-  "default": 0,
-  "maximum": 60,
-  "minimum": 0,
-  "type": "integer"
-}

removedInput schema / properties / name

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

removedInput schema / properties / network

Removed value: -{
-  "enum": [
-    "eip155:8453",
-    "eip155:84532",
-    "base",
-    "base-sepolia"
-  ],
-  "type": "string"
-}

removedInput schema / properties / operation / description

Removed value: -"Resolved read-only OpenAPI operation with URL, method and desired action; no remote spec fetching."

changedInput schema / properties / operation / type
```
Previous value: -"object"New value: +"string"
```
removedInput schema / properties / quantity
```
Removed value: -{
-  "const": 1
-}
```

removedInput schema / properties / query

Removed value: -{
-  "maxLength": 200,
-  "type": "string"
-}

removedInput schema / properties / requests
```
Removed value: -{
-  "const": 1
-}
```

removedInput schema / properties / sources

Removed value: -{
-  "items": {
-    "oneOf": [
-      {
-        "format": "uri",
-        "pattern": "^https://",
-        "type": "string"
-      },
-      {
-        "additionalProperties": false,
-        "properties": {
-          "fallbacks": {
-            "items": {
-              "format": "uri",
-              "type": "string"
-            },
-            "maxItems": 1,
-            "type": "array"
-          },
-          "url": {
-            "format": "uri",
-            "type": "string"
-          }
-        },
-        "required": [
-          "url"
-        ],
-        "type": "object"
-      }
-    ]
-  },
-  "maxItems": 3,
-  "type": "array"
-}

removedInput schema / properties / task

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

removedInput schema / properties / testnet

Removed value: -{
-  "default": false,
-  "type": "boolean"
-}

removedInput schema / properties / tool

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

removedInput schema / properties / toolId

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

removedInput schema / properties / tool_id

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

removedInput schema / properties / type

Removed value: -{
-  "const": "function"
-}

removedInput schema / properties / units
```
Removed value: -{
-  "const": 1
-}
```

removedInput schema / properties / url

Removed value: -{
-  "format": "uri",
-  "type": "string"
-}

removedInput schema / properties / urls

Removed value: -{
-  "items": {
-    "format": "uri",
-    "type": "string"
-  },
-  "maxItems": 3,
-  "type": "array"
-}

changedOutput schema / (root)

Previous value: -{
-  "anyOf": [
-    {
-      "properties": {
-        "capability": {
-          "type": "string"
-        },
-        "cost": {
-          "type": "object"
-        },
-        "intent": {
-          "type": "object"
-        },
-        "ok": {
-          "const": true
-        },
-        "receipt": {
-          "type": [
-            "object",
-            "null"
-          ]
-        },
-        "result": {
-          "type": "object"
-        },
-        "verification": {
-          "type": "object"
-        }
-      },
-      "required": [
-        "ok",
-        "intent",
-        "capability",
-        "result",
-        "verification",
-        "cost",
-        "receipt"
-      ],
-      "type": "object"
-    },
-    {
-      "properties": {
-        "accepts": {
-          "minItems": 1,
-          "type": "array"
-        },
-        "resource": {
-          "type": "object"
-        },
-        "x402Version": {
-          "const": 2
-        }
-      },
-      "required": [
-        "x402Version",
-        "resource",
-        "accepts"
-      ],
-      "type": "object"
-    },
-    {
-      "properties": {
-        "error": {
-          "type": [
-            "string",
-            "object"
-          ]
-        }
-      },
-      "required": [
-        "error"
-      ],
-      "type": "object"
-    },
-    {
-      "properties": {
-        "error_code": {
-          "type": "string"
-        },
-        "ok": {
-          "const": false
-        }
-      },
-      "required": [
-        "ok",
-        "error_code"
-      ],
-      "type": "object"
-    }
-  ],
-  "type": "object"
-}New value: +null

Addedxguard_preflight
Addedxguard_quote
Addedxguard_secretless_call
Addedxguard_status
Addedxguard_verify_receipt

1 tool updateSep 16, 2026

Changedxguard_execute11 fields changed

addedInput schema / properties / arguments / oneOf

Added value: +[
+  {
+    "type": "object"
+  },
+  {
+    "description": "JSON-encoded object, as used by tool calls",
+    "type": "string"
+  }
+]

removedInput schema / properties / arguments / type
```
Removed value: -"object"
```
addedInput schema / properties / calls
```
Added value: +{
+  "const": 1
+}
```

addedInput schema / properties / function

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "arguments": {
+      "type": [
+        "string",
+        "object"
+      ]
+    },
+    "name": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "name",
+    "arguments"
+  ],
+  "type": "object"
+}

addedInput schema / properties / network

Added value: +{
+  "enum": [
+    "eip155:8453",
+    "eip155:84532",
+    "base",
+    "base-sepolia"
+  ],
+  "type": "string"
+}

addedInput schema / properties / quantity
```
Added value: +{
+  "const": 1
+}
```
addedInput schema / properties / requests
```
Added value: +{
+  "const": 1
+}
```
addedInput schema / properties / toolId
```
Added value: +{
+  "type": "string"
+}
```
addedInput schema / properties / tool_id
```
Added value: +{
+  "type": "string"
+}
```

addedInput schema / properties / type

Added value: +{
+  "const": "function"
+}

addedInput schema / properties / units
```
Added value: +{
+  "const": 1
+}
```

1 tool updateSep 14, 2026

Changedxguard_execute3 fields changed

addedOutput schema / anyOf

Added value: +[
+  {
+    "properties": {
+      "capability": {
+        "type": "string"
+      },
+      "cost": {
+        "type": "object"
+      },
+      "intent": {
+        "type": "object"
+      },
+      "ok": {
+        "const": true
+      },
+      "receipt": {
+        "type": [
+          "object",
+          "null"
+        ]
+      },
+      "result": {
+        "type": "object"
+      },
+      "verification": {
+        "type": "object"
+      }
+    },
+    "required": [
+      "ok",
+      "intent",
+      "capability",
+      "result",
+      "verification",
+      "cost",
+      "receipt"
+    ],
+    "type": "object"
+  },
+  {
+    "properties": {
+      "accepts": {
+        "minItems": 1,
+        "type": "array"
+      },
+      "resource": {
+        "type": "object"
+      },
+      "x402Version": {
+        "const": 2
+      }
+    },
+    "required": [
+      "x402Version",
+      "resource",
+      "accepts"
+    ],
+    "type": "object"
+  },
+  {
+    "properties": {
+      "error": {
+        "type": [
+          "string",
+          "object"
+        ]
+      }
+    },
+    "required": [
+      "error"
+    ],
+    "type": "object"
+  },
+  {
+    "properties": {
+      "error_code": {
+        "type": "string"
+      },
+      "ok": {
+        "const": false
+      }
+    },
+    "required": [
+      "ok",
+      "error_code"
+    ],
+    "type": "object"
+  }
+]

removedOutput schema / properties

Removed value: -{
-  "capability": {
-    "type": "string"
-  },
-  "cost": {
-    "type": "object"
-  },
-  "intent": {
-    "type": "object"
-  },
-  "ok": {
-    "const": true
-  },
-  "receipt": {
-    "type": [
-      "object",
-      "null"
-    ]
-  },
-  "result": {
-    "type": "object"
-  },
-  "verification": {
-    "type": "object"
-  }
-}

removedOutput schema / required

Removed value: -[
-  "ok",
-  "intent",
-  "capability",
-  "result",
-  "verification",
-  "cost",
-  "receipt"
-]

5 tool updatesSep 10, 2026

Changedxguard_discover4 fields changed

removedInput schema / properties / limit

Removed value: -{
-  "default": 10,
-  "description": "Maximum results to return (1-100; default 10).",
-  "maximum": 100,
-  "minimum": 1,
-  "type": "integer"
-}

removedInput schema / properties / payTo

Removed value: -{
-  "description": "Filter by exact payment-recipient address.",
-  "type": "string"
-}

removedInput schema / properties / query

Removed value: -{
-  "description": "Search phrase; omit to list recent resources.",
-  "type": "string"
-}

removedInput schema / properties / type

Removed value: -{
-  "description": "Optional resource kind: http or mcp.",
-  "enum": [
-    "http",
-    "mcp"
-  ],
-  "type": "string"
-}

Addedxguard_execute
Addedxguard_get_result
Removedxguard_resource_details
Removedxguard_status

3 tool updatesAug 17, 2026
- First observedxguard_discover
- First observedxguard_resource_details
- First observedxguard_status

Related MCP Connectors

SCVD General Store A
store.scvd
Evidence observatory for agentic commerce: x402 preflight, receipt checks, settlement attestations.
Payments & Billing Autonomous Agents
2113
xportalx B
io.github.virgen101
AI agent gateway with web fetching, data extraction, crypto pricing, and x402 payments
Browser Automation Web Scraping Cryptocurrency
292
revettr-mcp A
io.github.AlexanderLawson17
Counterparty risk scoring for agentic commerce via x402 micropayments.
Finance Blockchain Payments & Billing
323
cred
fyi.cred
Agentic payments.
Payments & Billing Finance
2

Related MCP Servers

BitBooth MCP
Payments & Billing Blockchain Cryptocurrency
Drock91
A
license
Not graded
quality
D
maintenance
Multi-chain x402 payment gateway enabling AI agents to pay per HTTP call with real on-chain settlement across 5 mainnet chains, providing 18 paid endpoints for utilities, data, and security.
Updated 11 days ago (2026-09-16 00:27 UTC)
MIT
Tilde x402 MCP Server
Blockchain Payments & Billing Search
Gordian-Labs
A
license
Not graded
quality
D
maintenance
Enables AI agents to discover and pay for x402-enabled services using natural language, with multi-chain support for Solana and EVM payments.
Updated 10 months ago (2025-11-13 06:10 UTC)
2 npm
1
MIT
pay-mcp
Payments & Billing Blockchain Web3 & Decentralized Tech
pay-skill
A
license
Not graded
quality
B
maintenance
USDC payments for AI agents on Base. Direct transfers, pre-funded tabs, x402 paywall handling, and service discovery.
Updated 6 days ago (2026-09-21 02:10 UTC)
37 npm
MIT
@hpp-io/x402-mcp-bridgeofficial
Cryptocurrency Autonomous Agents Payments & Billing
hpp-io
A
license
Not graded
quality
B
maintenance
Enables AI agents to autonomously pay for and discover services using HPP USDC.e over the x402 protocol, without API keys or manual signing.
Updated a month ago (2026-08-20 01:23 UTC)
54 npm
Apache 2.0

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.

Server Details

Available Tools

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

@hpp-io/x402-mcp-bridgeofficial

Glama MCP Gateway

Resources