UseTested — Receipts-Verified Service Reviews

Server Details

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

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
Last Tested: 2026-09-27 16:39
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A3.9/5.0

Scored 2026-09-27 16:45 across 3 tools

Disambiguation4/5

The three tools have mostly distinct roles: search_services finds services, get_review returns one full review, and get_bundle returns all reviews in a category. There is some overlap because search_services also surfaces verdict and scores, but the descriptions clarify the difference between a summary search result and a full paid review.

Naming Consistency5/5

All tool names follow a clean snake_case verb_noun pattern: search_services, get_review, get_bundle. The verbs are predictable for their actions (search vs get), and no naming conventions are mixed.

Tool Count4/5

Three tools is a lean but reasonable surface for a read-only review directory. Each tool serves a clear purpose—search, single review, category bundle—though the set is small enough that it borders on minimal.

Completeness4/5

The surface covers the core read-only workflow: discover services, inspect one review, and retrieve category-level bundles. It lacks an explicit browse-all or category-listing operation, but the category enumeration in get_bundle and search_services make the domain largely navigable.

Available Tools

3 tools

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 verdict, 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.7/5.0

Behavior4/5

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

Annotations already establish the safety profile (readOnly, idempotent, non-destructive, closed-world), so the lower bar applies. The description usefully adds what the review actually contains — verdict tiers, scores, measured latency/error rate, on-chain purchase receipts — which tells the agent what evidence backs the result.

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 front-loaded sentence that packs the scope and the return contents with no filler. Minor redundancy between "receipts-verified" and "on-chain purchase receipts," and "Free" duplicates the title, but it stays tight.

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 and rich annotations covering the safety profile, the description need not explain return formatting. Combined with the schema's parameter documentation, the definition is complete enough to invoke correctly; only sibling routing and prerequisites are absent.

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 exists and the schema documents it at 100% coverage, including the exact-name requirement and the search_services reference. The description adds nothing beyond restating the single target as "one agent-economy service," 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?

States a specific verb and resource (get a review of one agent-economy service) and enumerates the payload: BUY/CAUTION/AVOID verdict, scores, latency/error rate, on-chain receipts. The choice of "one" service implicitly separates it from get_bundle, but neither sibling is named, so differentiation is left to inference.

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?

There is no explicit when-to-use or when-not-to-use guidance, nor any routing to get_bundle or search_services. The repeated "Free" label and the schema's pointer to "as listed by search_services" hint at a lookup-after-search workflow, but the description itself only implies the context.

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 UseTested directory of agent-economy 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	Default
`q`	No	Free-text query on service name or endpoint URL
`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 read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description still adds value by stating the call is Free and describing what is returned (verdict, scores, price per call, measured latency), which goes beyond the annotation set.

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, front-loaded with the resource and scope, then cost, then return fields, then routing. No filler and every sentence carries information.

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

Completeness5/5

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

With an output schema covering return values, full parameter documentation, and rich annotations, the description only needed to add scope and routing — which it does. Nothing an agent needs to select or invoke this tool 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 both the free-text query and the category enum are already documented. The description does not add syntax, matching behavior, or defaults beyond what the schema provides, so the baseline 3 applies.

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

Purpose5/5

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

Names a specific verb (Search) and resource (UseTested directory of agent-economy services), enumerated with concrete examples (x402 endpoints, MCP servers, AI APIs). It also names the downstream sibling get_review, letting an agent place it in the workflow without opening schemas.

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

Usage Guidelines4/5

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

Gives an explicit use case: 'Use it to find the exact `service` name for get_review', which is a clear chaining instruction. It stops short of stating when NOT to use it or how it relates to get_bundle, so it is strong but not exhaustive.

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.

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
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
41
aegis B
com.borisinc
Trust layer for the x402 economy - check any service before you pay. Scores, discovery, routing.
Payments & Billing E-commerce & Retail Agent Orchestration
2

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 13 days 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 2 days ago (2026-09-26 02:02 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 4 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 4 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?