Read current software facts with primary-source evidence and verification timestamps.
Scored across 6 tools
Most tools have clearly distinct roles: capabilities discovery, fact lookup, preflight validation, quote retrieval, paid fetch, and paid extraction. The main overlap is between xguard.web.fetch and xguard.extract, both paid public-HTTPS access tools, and between preflight and pricing.quote as optional payment-flow helpers.
All tools share the xguard prefix, but the suffixes mix bare nouns, bare verbs, and dot-separated resource/action patterns such as fact.get, pricing.quote, and web.fetch. The convention is readable but not consistent enough to be predictable.
Six tools is well within the ideal range and each covers a recognizable part of the paid-fetch workflow: discovery, safety, quoting, fetching, extraction, and free fact lookup. The surface is compact without feeling arbitrarily thin.
The surface covers the core lifecycle for safely discovering, quoting, paying for, and performing fetches, plus extraction and free fact lookup. Minor gaps remain, such as no fact search/list operation and no explicit receipt or status lookup beyond retrying the paid call.
Return the enabled and disabled XGuard tools, their security boundary, and canonical discovery URLs. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so safety is covered. The description does add useful non-obvious context: it returns disabled tools as well as enabled ones, and it is free, which matters given a pricing.quote sibling exists. It stops short of describing output shape, auth requirements, or ordering, so it is modest added value rather than rich disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler, and the payload contents are front-loaded ahead of the cost note. 'Free.' is terse but carries real decision value for an agent weighing sibling tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and no output schema, the description carries the return-value burden and does list the returned items. It is nearly complete, missing only whether discovery must precede other calls and what format the URLs or boundary data take.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 and there is no parameter meaning the description needs to compensate for. Nothing in the schema is left unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb ('Return') and enumerates exactly what comes back: enabled and disabled tools, their security boundary, and canonical discovery URLs. That is clearly distinct from xguard.preflight, xguard.pricing.quote, and xguard.web.fetch, though it does not explicitly name those siblings as alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance; the agent must infer from 'canonical discovery URLs' that this is a starting point. It never states whether this should be called before xguard.preflight or how it relates to the other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract main text, titles, metadata and links from 1–3 public HTTPS pages into one deduplicated, attributed result. No JavaScript rendering, private pages or web search. Up to 6,000 text characters per page; partial source coverage is explicit. Price: 0.012 USDC on Base. Uses x402 v2 HTTP payment headers: retry identical arguments and idempotency key with Payment-Signature and X-XGuard-Quote; the authorization is for the canonical HTTP API resource. No source is fetched before payment.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | ||
| idempotency_key | Yes | ||
| max_amount_atomic | Yes | Explicit spending cap in 6-decimal USDC atomic units. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations: discloses the exact price (0.012 USDC on Base), the x402 v2 payment-header handshake, that the caller must retry with identical arguments and idempotency key, the per-page 6,000-character cap, explicit partial-coverage reporting, and the key guarantee that no source is fetched before payment. That is exactly the auth/cost/side-effect context an agent needs before calling a paid, open-world tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the operation, then constraints, then price, then payment mechanics — no filler sentences, and each clause carries actionable information. The payment sentence is a dense compound packing several facts ('canonical HTTP API resource'), which costs some readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and three required parameters, the description supplies pricing, payment protocol, limits, and a rough shape of the result (deduplicated, attributed, partial coverage explicit). Missing only failure/error and per-URL failure behavior, which is a minor gap for a paid extraction call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
At 33% schema coverage the description must compensate, and it largely does: it adds the public-page restriction and URL count semantics for `urls`, ties the price to `max_amount_atomic` as a spending cap, and explains `idempotency_key` via the identical-arguments retry rule. It stops short of describing key reuse conflicts or uniqueness behavior, so not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (extract) and specific resources (main text, titles, metadata, links) scoped to 1–3 public HTTPS pages and a deduplicated, attributed result. The exclusion of web search and JS rendering sharpens scope, but no sibling is named, so the agent must infer why this beats xguard.web.fetch or xguard.fact.get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear when-not conditions (no JavaScript rendering, no private pages, no web search) and describes the retry path after a payment challenge. However, with five sibling tools it never names an alternative or the condition that routes to it, leaving tool selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one free published software fact by canonical ID. Returns the primary source, verification status and timestamp. Use xguard.web.fetch for a separate paid fetch of a public URL.
| Name | Required | Description | Default |
|---|---|---|---|
| factId | Yes | Canonical fact ID, for example npm/react/latest-version |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new context: the fact is free (cost contrast against the paid sibling) and the response carries a primary source, verification status and timestamp — useful for judging trustworthiness of the returned fact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with zero filler: purpose first, return contents second, routing to the sibling last. Nothing is repeated from the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description carries the burden of describing returns, and it does so at a high level (source, verification status, timestamp). For a one-parameter read tool that is close to sufficient; it omits the ID-miss behavior and any note on response shape, which is what keeps it below a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single required parameter and the schema already documents it at 100% coverage, including the canonical ID pattern, an example ('npm/react/latest-version') and a length cap. The description's 'canonical ID' phrasing is consistent but adds nothing the schema lacks; with one fully documented parameter the baseline of 3 applies, not higher.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Read one free published software fact by canonical ID') and names the exact thing it is not ('xguard.web.fetch for a separate paid fetch'). An agent can distinguish it from siblings without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the alternative tool and the axis that separates them: free fact lookup versus paid public-URL fetch. It does not cover failure cases (unknown ID, verification failed) or when to reach for xguard.preflight instead, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free, read-only safety gate for xguard.web.fetch. Validates the public HTTPS target, SSRF policy, DNS reachability and selected payment path without contacting the target or attempting payment. On allow, call xguard.web.fetch directly; it creates the signed quote and returns the mandatory x402 v2 PaymentRequired result.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, openWorldHint), the description discloses the side-effect profile that matters: it is free, does not contact the target, and does not attempt payment, despite performing DNS reachability checks. It also explains the downstream behavior of xguard.web.fetch, which creates the signed quote and returns the mandatory x402 v2 PaymentRequired result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences with no filler, front-loading the identity of the tool and then the validation scope and routing rule. The final clause about the x402 v2 PaymentRequired result is useful but slightly dense; overall it is efficient and well ordered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the sprawling multi-envelope input schema and the absence of an output schema, the description covers the essential gate semantics and the hand-off to fetch. It leaves the failure/deny path and the contents of a preflight success result implicit, which is a modest gap for a tool whose main value is a pass/fail verdict.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema enumerates the accepted envelopes plus x-xguard-accepted-shapes examples, so the schema carries the parameter semantics. The description adds no parameter-level meaning such as which fields drive the payment-path selection or how network/testnet affect the check, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource: a 'read-only safety gate for xguard.web.fetch' that validates the HTTPS target, SSRF policy, DNS reachability and payment path. It explicitly names the sibling it guards, so an agent can distinguish it from xguard.web.fetch, xguard.capabilities and xguard.pricing.quote 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the workflow rule 'On allow, call xguard.web.fetch directly', which tells the agent this tool precedes fetch and is not itself the fetch. However, it never says what to do when the preflight denies, nor whether preflight is mandatory or optional before every fetch, so the guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an optional signed quote for xguard.web.fetch. Call xguard.web.fetch directly to receive the price in an HTTP 402 challenge.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=false, so the safety profile is covered. The description adds that the quote is signed and optional and that unmetered pricing arrives via an HTTP 402 challenge, but it omits whether the quote expires, whether fetching it requires payment or auth, and how the signature ties to the subsequent fetch call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the purpose followed immediately by the alternative. No restated schema content and no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A read-only quote tool with no output schema needs the description to explain the quote's lifecycle, and that is missing: nothing says how long a quote is valid, whether it is reusable, or what the agent should do with the signed payload afterward. The available/alternative framing is present, but the operational follow-through is not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, and the description adds only that the target is xguard.web.fetch. That is mildly helpful given the schema's seven alternative envelope shapes and numerous deprecated aliases, but it does not clarify which shape an agent should prefer or how method/testnet interact with the quote.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Get an optional signed quote") scoped to a named sibling capability, xguard.web.fetch, so an agent can distinguish it from the fetch tool itself. It stops short of saying what the quote contains or what the signature authorizes, which keeps it from being fully self-explanatory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear when-not-to-use route: call xguard.web.fetch directly to get the price in an HTTP 402 challenge. However, it never states the condition under which this tool IS worth calling (pre-authorizing payment, avoiding a 402 round-trip, obtaining a price before committing), so the positive selection criterion is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one public HTTPS resource after x402 v2 payment and on-chain settlement verification. Retry the identical MCP call with Payment-Signature and X-XGuard-Quote. A completed retry returns the prior receipt.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld, but the description adds genuinely new behavioral facts: a payment and on-chain settlement step precedes the fetch, an unquoted call yields a 402 with an auto-created quote, and a completed retry returns a prior receipt rather than re-executing. The notable omission is that a real monetary cost is implied without quantifying it or pointing at the pricing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences, front-loaded with the purpose and precondition before the retry mechanics. Slight redundancy with the input-schema description, which repeats the 402-and-retry flow almost verbatim, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five accepted envelope shapes and a dozen URL aliases, the description does not orient the agent on which shape to send, and with no output schema it only hints at the return value ('receipt'). The critical commercial fact — that the call costs money and therefore needs a quote from a sibling tool first — is implied rather than stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value the schema cannot express by naming the two required HTTP headers (Payment-Signature, X-XGuard-Quote) and tying 'quote' back to xguard.pricing.quote, but it says nothing about the accepted envelopes, the many deprecated URL aliases, max_bytes truncation, or method/mode choices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Fetch one public HTTPS resource') plus the gating precondition (x402 v2 payment and on-chain settlement verification), which is far more than the title alone. It does not name the sibling tools (xguard.pricing.quote, xguard.preflight) that naturally precede it, so the agent must infer that a quote comes from elsewhere.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete invocation-flow guidance: call, receive 402, then retry the identical call with Payment-Signature and X-XGuard-Quote. That tells the agent how to proceed after failure, but there is no when-to-use vs. when-not guidance relative to the sibling quote/preflight tools, and no statement about what to do if settlement fails.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
xguard.extractxguard.fact.getxguard_discoverxguard_executexguard_get_resultxguard_preflightxguard_quotexguard_secretless_callxguard_statusxguard_verify_receiptxguard.capabilitiesxguard.preflightxguard.pricing.quotexguard.web.fetchxguard_execute34 fields changedInput schema / additionalPropertiesPrevious value: -falseNew value: +trueInput schema / descriptionRemoved 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."Input schema / properties / actionRemoved value: -{
- "type": "string"
-}Input schema / properties / argumentsRemoved value: -{
- "oneOf": [
- {
- "type": "object"
- },
- {
- "description": "JSON-encoded object, as used by tool calls",
- "type": "string"
- }
- ]
-}Input schema / properties / callsRemoved value: -{
- "const": 1
-}Input schema / properties / capability / enumRemoved value: -[
- "extract-preview",
- "web-extraction",
- "product-offers",
- "feed-digest"
-]Input schema / properties / commandRemoved value: -{
- "type": "string"
-}Input schema / properties / desired_actionRemoved value: -{
- "type": "string"
-}Input schema / properties / functionRemoved value: -{
- "additionalProperties": false,
- "properties": {
- "arguments": {
- "type": [
- "string",
- "object"
- ]
- },
- "name": {
- "type": "string"
- }
- },
- "required": [
- "name",
- "arguments"
- ],
- "type": "object"
-}Input schema / properties / htmlRemoved value: -{
- "maxLength": 12288,
- "type": "string"
-}Input schema / properties / httpRemoved value: -{
- "type": "object"
-}Input schema / properties / idempotency_keyAdded value: +{
+ "type": "string"
+}Input schema / properties / intent / oneOfRemoved value: -[
- {
- "maxLength": 3000,
- "type": "string"
- },
- {
- "type": "object"
- }
-]Input schema / properties / intent / typeAdded value: +[
+ "string",
+ "object"
+]Input schema / properties / limitRemoved value: -{
- "maximum": 30,
- "minimum": 1,
- "type": "integer"
-}Input schema / properties / max_age_secondsRemoved value: -{
- "default": 0,
- "maximum": 60,
- "minimum": 0,
- "type": "integer"
-}Input schema / properties / nameRemoved value: -{
- "type": "string"
-}Input schema / properties / networkRemoved value: -{
- "enum": [
- "eip155:8453",
- "eip155:84532",
- "base",
- "base-sepolia"
- ],
- "type": "string"
-}Input schema / properties / operation / descriptionRemoved value: -"Resolved read-only OpenAPI operation with URL, method and desired action; no remote spec fetching."Input schema / properties / operation / typePrevious value: -"object"New value: +"string"Input schema / properties / quantityRemoved value: -{
- "const": 1
-}Input schema / properties / queryRemoved value: -{
- "maxLength": 200,
- "type": "string"
-}Input schema / properties / requestsRemoved value: -{
- "const": 1
-}Input schema / properties / sourcesRemoved 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"
-}Input schema / properties / taskRemoved value: -{
- "type": "object"
-}Input schema / properties / testnetRemoved value: -{
- "default": false,
- "type": "boolean"
-}Input schema / properties / toolRemoved value: -{
- "type": "string"
-}Input schema / properties / toolIdRemoved value: -{
- "type": "string"
-}Input schema / properties / tool_idRemoved value: -{
- "type": "string"
-}Input schema / properties / typeRemoved value: -{
- "const": "function"
-}Input schema / properties / unitsRemoved value: -{
- "const": 1
-}Input schema / properties / urlRemoved value: -{
- "format": "uri",
- "type": "string"
-}Input schema / properties / urlsRemoved value: -{
- "items": {
- "format": "uri",
- "type": "string"
- },
- "maxItems": 3,
- "type": "array"
-}Output 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: +nullxguard_preflightxguard_quotexguard_secretless_callxguard_statusxguard_verify_receiptxguard_execute11 fields changedInput schema / properties / arguments / oneOfAdded value: +[
+ {
+ "type": "object"
+ },
+ {
+ "description": "JSON-encoded object, as used by tool calls",
+ "type": "string"
+ }
+]Input schema / properties / arguments / typeRemoved value: -"object"Input schema / properties / callsAdded value: +{
+ "const": 1
+}Input schema / properties / functionAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "arguments": {
+ "type": [
+ "string",
+ "object"
+ ]
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "arguments"
+ ],
+ "type": "object"
+}Input schema / properties / networkAdded value: +{
+ "enum": [
+ "eip155:8453",
+ "eip155:84532",
+ "base",
+ "base-sepolia"
+ ],
+ "type": "string"
+}Input schema / properties / quantityAdded value: +{
+ "const": 1
+}Input schema / properties / requestsAdded value: +{
+ "const": 1
+}Input schema / properties / toolIdAdded value: +{
+ "type": "string"
+}Input schema / properties / tool_idAdded value: +{
+ "type": "string"
+}Input schema / properties / typeAdded value: +{
+ "const": "function"
+}Input schema / properties / unitsAdded value: +{
+ "const": 1
+}xguard_execute3 fields changedOutput schema / anyOfAdded 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"
+ }
+]Output schema / propertiesRemoved value: -{
- "capability": {
- "type": "string"
- },
- "cost": {
- "type": "object"
- },
- "intent": {
- "type": "object"
- },
- "ok": {
- "const": true
- },
- "receipt": {
- "type": [
- "object",
- "null"
- ]
- },
- "result": {
- "type": "object"
- },
- "verification": {
- "type": "object"
- }
-}Output schema / requiredRemoved value: -[
- "ok",
- "intent",
- "capability",
- "result",
- "verification",
- "cost",
- "receipt"
-]xguard_discover4 fields changedInput schema / properties / limitRemoved value: -{
- "default": 10,
- "description": "Maximum results to return (1-100; default 10).",
- "maximum": 100,
- "minimum": 1,
- "type": "integer"
-}Input schema / properties / payToRemoved value: -{
- "description": "Filter by exact payment-recipient address.",
- "type": "string"
-}Input schema / properties / queryRemoved value: -{
- "description": "Search phrase; omit to list recent resources.",
- "type": "string"
-}Input schema / properties / typeRemoved value: -{
- "description": "Optional resource kind: http or mcp.",
- "enum": [
- "http",
- "mcp"
- ],
- "type": "string"
-}xguard_executexguard_get_resultxguard_resource_detailsxguard_statusxguard_discoverxguard_resource_detailsxguard_statusRead-only release evidence for coding agents: findings, deliveries, source and runtime data.
Physical-world evidence and operability checks with provenance and explicit data gaps.
Read-only, sourced access facts for wealth tech products, vendor MCP servers and Form ADV columns.
Facts agents verified, with sources and how sure each is. A lookup can save a web search.
Add one secure layer between your agents and this server.