UseTested — Receipts-Verified Service Reviews

by io.github.sharan01x

Overview Discussions Admin

Server Details

Receipts-verified reviews of x402 services and paid APIs, before you spend.

Ownership verified

Status: Healthy
Uptime: 100.0% over 22 days
Last Tested: 2026-10-18 03:46
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.1/5.0

Scored 2026-10-02 09:30 across 6 tools

Disambiguation4/5

Most tools target distinct resources and actions: search_services discovers services, get_review retrieves one review, get_bundle retrieves a category bundle, request_review queues a new service, and request_retest/accept_retest_quote form a clear quote-and-pay pair. The only mild overlap is between request_review and request_retest, since both initiate testing, but descriptions distinguish unreviewed vs. existing services.

Naming Consistency5/5

All tool names use consistent snake_case with a clear verb_noun or verb_noun_phrase pattern: accept_retest_quote, get_bundle, get_review, request_retest, request_review, search_services. There is no mixing of conventions.

Tool Count5/5

Six tools is well-scoped for a focused service-review server: discovery, single review, category bundle, review request, retest quote, and retest payment. Each tool earns its place without redundancy.

Completeness4/5

The surface covers the core review lifecycle: search, read, request new review, request retest, and pay for retest. Minor gaps exist around tracking the status of submitted review/retest requests or listing request history, but agents can work around these.

Available Tools

6 tools

accept_retest_quoteAccept a re-test quote and pay (x402)A

Idempotent

Inspect

Accept the quote from request_retest and pay the quoted total via x402 (USDC on Base) — paid automatically by your x402 MCP client. On settlement the re-test request is recorded (status paid, tx stored) and queued. Input: the exact service_name and quote_total_usd from your quote.

ParametersJSON Schema

Name	Required	Description
`reason`	No	Why a re-test is needed (stored with the request)
`service_name`	Yes	Exact service name, as listed by search_services (free)
`quote_total_usd`	Yes	Total from the request_retest quote you are accepting

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	Yes
`status`	Yes
`payment_tx`	Yes
`request_id`	Yes
`service_name`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

Annotations cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description goes well beyond them: it names the payment rail (x402, USDC on Base), that payment is automatic, and the post-settlement effects (status set to paid, tx stored, request queued). That is exactly the behavioral context an agent needs before invoking a paid mutation.

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 tight sentences: the action and payment path lead, the outcome follows, and the required inputs are called out last. No filler and nothing is buried.

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 paid mutation tool with full annotation coverage, complete parameter docs and an output schema, the description supplies the one thing structured data cannot: the payment flow and settlement side effects. 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%, so the baseline is 3; the description only restates that the inputs are the exact service_name and quote_total_usd from the quote, adding the minor nuance that they must match the quote exactly. It does not add format or validation detail beyond the schema.

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+resource (accept the re-test quote) plus the payment mechanism (x402/USDC on Base) and the resulting state change. It is clearly distinguishable from the sibling request_retest that produces the quote it consumes.

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 establishes the precondition clearly: the service_name and quote_total_usd must come from a prior request_retest quote, and payment happens automatically via the caller's x402 MCP client. It does not state when-not to use it (e.g., expired quote handling or insufficient balance), so no explicit exclusions.

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

get_bundleGet all reviews in a category ($0.05)A

Read-onlyIdempotent

Inspect

Every receipts-verified UseTested review in a category (inference|data|search|media|infrastructure), sorted by reliability. Costs $0.05 via x402 (USDC on Base) — paid automatically by your x402 MCP client.

ParametersJSON Schema

Name	Required	Description	Default
`category`	Yes	Category of services to fetch reviews for

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`reviews`	Yes
`category`	Yes
`methodology_version`	Yes

TDQS

A3.8/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). The description adds genuinely new behavioral context: a $0.05 x402/USDC-on-Base payment that is auto-handled by the client, plus receipts-verified filtering and reliability sorting. That is material information an agent would not otherwise know.

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 compact sentences, front-loaded with what is returned, then the payment mechanism. Every clause carries information; no filler.

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

Completeness4/5

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

With an output schema present, return values need no explanation, and the cost/eligibility details are disclosed. Minor gap is the absence of routing guidance relative to the sibling tools, but the definition is otherwise complete for 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?

Only one parameter and schema coverage is 100%, with the enum values and meaning fully documented in the schema, so the description merely echoes the category list. Baseline 3 applies since the schema carries the parameter burden.

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 resource (receipts-verified UseTested reviews) scoped to a category, with the sort order (by reliability) made explicit. It does not distinguish itself from siblings like get_review, but the resource and scope are clear enough for selection.

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?

Usage is only implied: fetch reviews for a category when you want the full set rather than a single one. No explicit when/when-not guidance or named alternative (get_review, search_services) is provided.

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

get_reviewGet receipts-verified service review (free)A

Read-onlyIdempotent

Inspect

Full receipts-verified review of one agent-economy service: BUY/CAUTION/AVOID/INTERIM verdict (INTERIM = single verified result, pending deep review), scores, measured latency/error rate, and on-chain purchase receipts. Free.

ParametersJSON Schema

Name	Required	Description	Default
`service`	Yes	Exact service name, as listed by search_services (free)

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	Yes
`scores`	Yes
`service`	Yes
`verdict`	Yes
`endpoint`	Yes
`measured`	Yes
`receipts`	Yes
`updated_at`	Yes
`price_per_call`	Yes
`refund_behavior`	Yes
`methodology_version`	Yes

TDQS

A3.6/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, closed-world), so the description's added value is the verdict semantics (INTERIM = single verified result, pending deep review) and the cost signal "Free" — neither of which appears in structured fields. It does not mention rate limits or freshness, but the annotation coverage lowers the bar.

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?

A single dense sentence that front-loads the core resource and then lists outputs; nothing is wasted. The redundant "Free" (also in the title) is the only minor excess.

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 the description needn't explain return values, yet it briefly previews them; annotations cover safety and idempotency, and the verdict vocabulary is defined inline. An agent has everything needed to call this 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?

With a single parameter at 100% schema description coverage, the schema already tells the agent to pass an exact service name as listed by search_services. The description adds no additional parameter syntax or format guidance, so the baseline 3 applies.

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

Purpose4/5

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

The description names a specific verb and resource ("Full receipts-verified review of one agent-economy service") and even enumerates the verdict taxonomy (BUY/CAUTION/AVOID/INTERIM) and returned data, so the agent knows exactly what it gets. It does not explicitly contrast itself with get_bundle or search_services, so it falls short of full sibling differentiation.

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 when-to-use or when-not-to-use guidance in the description; it never says to call search_services first or to use get_bundle instead for multi-service needs. The only workflow hint lives in the schema's parameter description, not in the tool description itself.

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

request_retestGet a re-test quote for a reviewed service (free quote, paid re-test)A

Read-onlyIdempotent

Inspect

Get an upfront quote for UseTested to re-test a service we have already reviewed — e.g. its quality changed, the review is stale, or measured numbers no longer match reality. Free. Returns the exact total: $1.00 rubric fee + the service's current advertised per-call price x 10 probe calls. To proceed, pay the quote via accept_retest_quote. The service must exist in our directory (find the exact name via search_services, free).

ParametersJSON Schema

Name	Required	Description	Default
`reason`	No	Why a re-test is needed (changed behaviour, stale data, errors)
`service_name`	Yes	Exact service name, as listed by search_services (free)

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	Yes
`status`	Yes
`fee_usd`	Yes
`probe_calls`	Yes
`service_name`	Yes
`quote_total_usd`	Yes
`service_price_per_call_usd`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnlyHint=true, idempotent, non-destructive), and the description adds genuinely useful context beyond that: the exact cost model ($1.00 rubric fee + advertised per-call price x 10 probe calls), the fact that the quote itself is free while the re-test is paid, and the directory-membership prerequisite.

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?

Four compact sentences, front-loaded with purpose and cost before the payment path and prerequisite. Every sentence adds information (what, price, next step, precondition) with no filler.

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?

Output schema exists so return values need not be explained, yet the description still tells the agent what the total consists of. Purpose, cost, next action, and name-resolution prerequisite are all present, leaving nothing an agent needs 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?

With 100% schema description coverage, the baseline is 3. The description goes slightly beyond the schema by specifying that service_name must exist in the directory and must be the exact name obtained from search_services, adding a validity constraint not spelled out in the schema.

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+resource ('Get an upfront quote ... to re-test a service we have already reviewed') and immediately scopes it to a reviewed service, which distinguishes it from request_review and get_review. An agent can tell what it does and what it does not do 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.

Usage Guidelines5/5

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

It gives concrete triggering conditions (quality changed, review stale, measured numbers no longer match) and explicitly names the alternatives: search_services to find the exact name and accept_retest_quote to proceed after payment. When-to-use, prerequisites, and the next step are all stated.

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

request_reviewRequest a review of a service not yet covered (free)A

Idempotent

Inspect

Request that UseTested buy and test an agent-economy service (x402 endpoint, MCP server, AI API) we haven't reviewed yet. Free. Queues the service for evaluation consideration — requests factor into which services we test next. No SLA or guaranteed verdict.

ParametersJSON Schema

Name	Required	Description
`notes`	No	Why this service matters to you (context helps prioritisation)
`service_url`	No	Endpoint or landing URL of the service, if known
`requestor_id`	No	Identity tag for the request ledger. Leave unset for normal use.
`service_name`	Yes	Name of the service you want reviewed

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	Yes
`status`	Yes
`request_id`	Yes
`service_name`	Yes

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare idempotentHint=true, destructiveHint=false and openWorldHint=false. The description adds genuinely useful behavior beyond that: the request is queued for consideration, requests influence prioritisation, and there is no SLA or guaranteed verdict — an asymmetric, non-guaranteed outcome an agent should know about.

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?

Four tight sentences, front-loaded with the core action, followed by cost, behavior, and the key caveat. The standalone 'Free.' earns its place and every sentence carries distinct information.

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 not be explained. The description covers cost, queueing behavior, and the no-guarantee caveat, which is what an agent needs before calling. The only gap is not pointing at request_retest for services that already have a review.

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

Parameters3/5

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

Schema description coverage is 100%, so all four parameters are already documented in the schema, and the description adds no per-parameter syntax or format detail. It does narrow the domain ('x402 endpoint, MCP server, AI API'), which gives some meaning to service_name/service_url, but that is marginal over the schema baseline.

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 ('Request that UseTested buy and test an agent-economy service') plus the scope qualifier 'we haven't reviewed yet', which functionally distinguishes it from request_retest. It stops short of naming the sibling it excludes, so the routing is implied rather than explicit.

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?

Usage is implied by 'we haven't reviewed yet', but there is no explicit when-to-use/when-not guidance and no named alternative (e.g. request_retest for already-covered services). 'Free' and 'No SLA or guaranteed verdict' set expectations for the outcome rather than telling the agent when to pick this tool.

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

search_servicesSearch UseTested service directoryA

Read-onlyIdempotent

Inspect

Search the world's largest independently-tested directory of agent-payable services (x402 endpoints, MCP servers, AI APIs). Free. Returns verdict, scores, price per call, and measured latency. Use it to find the exact service name for get_review.

ParametersJSON Schema

Name	Required	Description
`q`	No	Free-text query on service name or endpoint URL
`limit`	No	Max results to return (default 100, up to 1000)
`category`	No	Filter by category

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	Yes
`count`	Yes
`results`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description adds genuinely useful non-annotation context: it is free (no cost/auth barrier) and returns verdict, scores, price per call, and measured latency. It does not discuss pagination or result caps, but with an output schema present that is minor.

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?

Four short sentences, zero waste, with the core purpose front-loaded. Each sentence adds a distinct piece of information (what, cost, what it returns, where to use it next) rather than restating 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 zero-required-parameter read-only search tool with a full output schema, the description covers everything an agent needs: scope, cost, return shape, and the workflow handoff to get_review. Return-value detail is legitimately delegated to the output schema.

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% with all three parameters (q, limit, category) documented and an enum on category, so the schema carries parameter meaning fully. The description adds no syntax or format guidance beyond what the schema provides, making the baseline 3 appropriate.

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 (Search) and resource (independently-tested directory of agent-payable services), and scopes it concretely with the examples x402 endpoints, MCP servers, AI APIs. It also routes clearly away from ambiguity by naming get_review as the downstream sibling, so an agent can place it in the workflow 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?

Explicitly says what it is for: 'find the exact `service` name for get_review,' which gives the agent a clear trigger. It stops short of stating when NOT to use it or naming alternative discovery siblings (e.g. get_bundle), so it is clear context rather than full when/when-not routing.

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 tool updateOct 17, 2026

Changedsearch_services2 fields changed

addedOutput schema / properties / results / items / properties / protocol
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```

changedOutput schema / properties / results / items / required

Previous value: -[
-  "service",
-  "endpoint",
-  "category",
-  "price_per_call",
-  "bazaar_listing_url",
-  "verdict",
-  "scores",
-  "latency_p50_ms",
-  "updated_at",
-  "methodology_version"
-]New value: +[
+  "service",
+  "endpoint",
+  "category",
+  "protocol",
+  "price_per_call",
+  "bazaar_listing_url",
+  "verdict",
+  "scores",
+  "latency_p50_ms",
+  "updated_at",
+  "methodology_version"
+]

1 tool updateOct 2, 2026

Changedrequest_review1 field changed

addedInput schema / properties / requestor_id

Added value: +{
+  "description": "Identity tag for the request ledger. Leave unset for normal use.",
+  "enum": [
+    "mcp",
+    "smoke"
+  ],
+  "type": "string"
+}

3 tool updatesOct 1, 2026
- Addedaccept_retest_quote
- Addedrequest_retest
- Addedrequest_review

1 tool updateOct 1, 2026

Changedsearch_services1 field changed

addedInput schema / properties / limit

Added value: +{
+  "description": "Max results to return (default 100, up to 1000)",
+  "maximum": 1000,
+  "minimum": 1,
+  "type": "integer"
+}

3 tool updatesSep 27, 2026

Changedget_bundle1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "category": {
+      "type": "string"
+    },
+    "count": {
+      "type": "number"
+    },
+    "methodology_version": {
+      "type": "string"
+    },
+    "reviews": {
+      "items": {
+        "additionalProperties": {},
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "category",
+    "count",
+    "reviews",
+    "methodology_version"
+  ],
+  "type": "object"
+}

Changedget_review1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "endpoint": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "measured": {
+      "additionalProperties": false,
+      "properties": {
+        "calls_tested": {
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "error_rate": {
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "latency_p50_ms": {
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "latency_p95_ms": {
+          "type": [
+            "number",
+            "null"
+          ]
+        }
+      },
+      "required": [
+        "latency_p50_ms",
+        "latency_p95_ms",
+        "error_rate",
+        "calls_tested"
+      ],
+      "type": "object"
+    },
+    "methodology_version": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "note": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "price_per_call": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "receipts": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "amount": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "chain": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "payer": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "ts": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "tx": {
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "required": [
+          "chain",
+          "tx",
+          "ts",
+          "payer",
+          "amount"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "refund_behavior": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "scores": {
+      "additionalProperties": false,
+      "properties": {
+        "docs": {
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "quality": {
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "reliability": {
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "value": {
+          "type": [
+            "number",
+            "null"
+          ]
+        }
+      },
+      "required": [
+        "reliability",
+        "quality",
+        "value",
+        "docs"
+      ],
+      "type": "object"
+    },
+    "service": {
+      "type": "string"
+    },
+    "updated_at": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "verdict": {
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "service",
+    "endpoint",
+    "verdict",
+    "scores",
+    "measured",
+    "price_per_call",
+    "receipts",
+    "refund_behavior",
+    "note",
+    "methodology_version",
+    "updated_at"
+  ],
+  "type": "object"
+}

Changedsearch_services1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "count": {
+      "type": "number"
+    },
+    "note": {
+      "type": "string"
+    },
+    "results": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "bazaar_listing_url": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "category": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "endpoint": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "latency_p50_ms": {
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "methodology_version": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "price_per_call": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "scores": {
+            "additionalProperties": false,
+            "properties": {
+              "docs": {
+                "type": [
+                  "number",
+                  "null"
+                ]
+              },
+              "quality": {
+                "type": [
+                  "number",
+                  "null"
+                ]
+              },
+              "reliability": {
+                "type": [
+                  "number",
+                  "null"
+                ]
+              },
+              "value": {
+                "type": [
+                  "number",
+                  "null"
+                ]
+              }
+            },
+            "required": [
+              "reliability",
+              "quality",
+              "value",
+              "docs"
+            ],
+            "type": "object"
+          },
+          "service": {
+            "type": "string"
+          },
+          "updated_at": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "verdict": {
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "required": [
+          "service",
+          "endpoint",
+          "category",
+          "price_per_call",
+          "bazaar_listing_url",
+          "verdict",
+          "scores",
+          "latency_p50_ms",
+          "updated_at",
+          "methodology_version"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "count",
+    "results",
+    "note"
+  ],
+  "type": "object"
+}

3 tool updatesSep 27, 2026
- First observedget_bundle
- First observedget_review
- First observedsearch_services

Related MCP Connectors

What Agents Buy A
com.whatagentsbuy
Independent measured reviews of x402 API sellers: pre-payment verdicts and accuracy grades.
E-commerce & Retail Finance
71
AgentIndex A
io.github.cognivis
Trust scores and on-chain payment receipts for x402 services.
Blockchain Payments & Billing Web3 & Decentralized Tech
41
Pod AOAuth
io.github.Marvy101
Search and share firsthand reviews of products, APIs, services, places, and organizations.
Search
1
Agent Deals A
io.github.gmahar82-stack
Pay less for x402 APIs: free pre-payment checks, cheapest working service finder, web/PDF reader.
Payments & Billing Search Web Scraping
51

Related MCP Servers

nohumans-mcp
Search Monitoring Payments & Billing
jalcodev
F
license
Not graded
quality
A
maintenance
Find and vet paid x402 API services before an agent spends money on them, with live reliability scores and recency-weighted probing.
Updated a month ago (2026-09-14 13:29 UTC)
-
crosscheck
Autonomous Agents Testing & QA Tools
maxugc
A
license
Not graded
quality
B
maintenance
Enables AI agents to obtain an independent review of their drafts, returning a pass/fail verdict with specific issues and suggested fixes, plus a signed receipt. Payments are made per check over x402, with no account or API key needed.
Updated 21 days ago (2026-09-27 14:59 UTC)
MIT
crest-verify
Security Autonomous Agents
andysalvo
A
license
Not graded
quality
D
maintenance
Verify x402 endpoints before your agent spends. Three tools: verify (SPEND/CAUTION/INVESTIGATE/DO NOT SPEND backed by 50K+ services), passport (full trust identity), risk_check (deep assessment). No API keys, no signup.
Updated 5 months ago (2026-05-28 18:31 UTC)
12 npm
MIT
x402-tools
Developer Tools Security
vera-agent-dev
A
license
A
quality
B
maintenance
Enables AI agents to pay per call for live package-safety and GitHub merge-readiness trust signals via the x402 protocol.
Updated 25 days ago (2026-09-23 05:18 UTC)
3
MIT

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

Need Help?