Read only x402 catalogue: payability verdicts, prices, drift, host status, signatures. No wallet.
Scored across 8 tools
Most tools have clearly distinct purposes: find_endpoints searches, host_summary summarizes a host, payability_verdict checks one URL, verify_signature performs cryptographic verification. Some potential overlap exists between catalogue_stats and x401_status (both report catalogue-wide metrics) and between host_summary and find_endpoints for host-scoped queries, but the descriptions make the distinctions reasonably clear.
Names are all snake_case, which is consistent, but the verb/noun pattern is mixed: some start with a noun (catalogue_stats, drift_status, host_summary), some with a verb (find_endpoints, verify_signature), and x401_status has a non-standard prefix. The style is readable but not a predictable verb_noun pattern.
Eight tools is a well-scoped set for a catalogue monitoring workbench covering search, summaries, stats, drift, reports, and verification. Each tool appears to earn its place with no obvious redundant operations.
The surface covers discovery (find_endpoints), per-host and per-resource detail (host_summary, payability_verdict), catalogue health (catalogue_stats, x401_status), drift tracking (drift_status), published reports (reports), and signature verification (verify_signature). Minor gaps exist: no direct time-series or historical query tool, and no explicit batch payability check, but core workflows are well covered.
Size and health of the x402 catalogue as of the latest full scan: resources, hosts, verdict counts, and payable endpoints per network.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds meaningful behavioral context by noting the data is from the latest full scan, implying a snapshot that may not reflect live state, and by enumerating the included metric categories. It does not describe the exact response shape, but the annotations lower the burden.
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?
The description is a single sentence with a colon-delimited list of content categories. It is front-loaded with the core purpose and contains no filler or redundant restatement of the tool name.
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 parameterless, read-only stats tool, the description covers the main output dimensions and the snapshot timing. Since there is no output schema, it could list exact field names, but the categories given are enough for an agent to understand what results to expect.
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 has zero parameters and the schema has no properties, so there is no parameter semantics for the description to clarify. The baseline of 4 for a parameterless tool applies, and the description correctly avoids inventing parameter details.
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 clearly identifies the resource and scope: catalogue-wide size and health metrics including resources, hosts, verdict counts, and payable endpoints. It lacks an explicit verb like 'returns' or 'reports', but the noun-phrase framing plus the metric list makes the purpose unambiguous. It also distinguishes itself from sibling tools by emphasizing the whole-catalogue view rather than host, endpoint, or payability specifics.
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?
No guidance is given about when to use this tool versus alternatives such as reports, host_summary, or payability_verdict. The phrase 'as of the latest full scan' hints at snapshot semantics, but there is no explicit when-to-use, when-not-to-use, or pointer to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verdict changes between the two latest full scans (catalogue wide, or for one host), plus the declared model drift watch.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No |
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 clear. The description adds valuable behavioral context by explaining that it compares the two latest full scans and includes the declared model drift watch, going beyond what the annotations alone provide.
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?
The description is a single sentence that packs in the core behavior, scope options, and the extra drift-watch feature without wasted words. It is front-loaded with the primary purpose and remains easy to parse.
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 simple, read-only tool with one optional parameter and rich annotations, the description gives enough context to invoke it correctly. It does not describe the exact return structure, but no output schema exists and the behavior is conceptually clear; the remaining ambiguity around 'model drift watch' is minor.
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?
With 0% schema description coverage, the description carries the full explanatory burden for the host parameter. It does this by indicating that the tool works either catalogue-wide or for one host, implying that an empty host means catalogue-wide and a populated host scopes the result. This compensates well for the bare schema.
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 names a specific deliverable: verdict changes between the two latest full scans, optionally scoped to one host, plus model drift watch. It does not explicitly contrast with sibling tools like payability_verdict or host_summary, but the subject matter is clear and distinct enough.
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?
The phrase 'catalogue wide, or for one host' implies the intended usage scopes, and the read-only nature suggests it is for inspecting drift rather than modifying state. However, there is no explicit guidance about when to prefer this tool over nearby alternatives such as payability_verdict or host_summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the catalogue by host or URL substring. Returns up to limit endpoints (max 50) with their
latest verdict, plus the total match count. Use this first when you do not know the exact resource URL.
Rows with in_latest_scan=false were not in the latest full scan; read last_checked_at for when they were last probed.
Optional network filter (for example eip155:8453 or solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp) and
sort=price for the cheapest first.
last_checked_at is the last time any scan looked at the resource; verdict_since is when the current
verdict was first observed in the unbroken run that leads to it. A scan that did not
contain the resource does not break the run, so verdict_since can span weeks nobody
measured. How current a row is comes from last_checked_at and in_latest_scan, not from
verdict_since alone.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | ||
| limit | No | ||
| query | Yes | ||
| network | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, not open-world), and the description adds substantial context beyond them: the 50-row cap, the presence of a total match count, what in_latest_scan=false means, and the important caveat that verdict_since can span unmeasured weeks so freshness should be judged from last_checked_at plus in_latest_scan. This is exactly the kind of non-obvious behavior an agent needs and cannot get from the schema.
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?
The core purpose, usage hint, and parameter behavior are front-loaded and each sentence is informative. The final paragraph on verdict_since versus last_checked_at is dense and repetitive, but it prevents a genuine misinterpretation, so the length is mostly justified.
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, the description supplies the return contract itself (rows with latest verdict, total match count, freshness fields) and explains the ambiguous columns. It also clarifies the limit ceiling and the special meaning of in_latest_scan=false, leaving no gap an agent would need to fill by trial and error.
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 0%, so the description carries the full burden and does so: `query` is host or URL substring, `limit` is capped at 50, `network` is shown with two concrete format examples (eip155:8453, solana:5eyk...), and `sort=price` is explained as cheapest-first ordering. All four parameters gain meaning beyond their bare titles.
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 opens with a specific verb and resource: 'Search the catalogue by host or URL substring,' and states the return shape (up to `limit` endpoints with latest verdict plus total match count). It is clearly distinguishable from siblings like catalogue_stats or host_summary. It stops short of explicitly naming which sibling to use for exact-URL or aggregate lookups, so it lands at 4 rather than 5.
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?
'Use this first when you do not know the exact resource URL' gives a concrete when-to-use condition, and the network/sort options hint at refinement workflows. However, no alternative sibling is named for the known-URL case or for aggregate stats, so the routing guidance is clear but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summary for a host (no time series): first/last seen, current verdict mix, n_resources, total verdict changes, gone_since if absent from the latest full scan, and a small resources_sample. Sample rows with in_latest_scan=false were not in the latest full scan; read last_checked_at for when they were last probed. n_resources counts every resource ever seen for this host; current_verdict_mix and n_payable_last_full count only the latest full scan. last_checked_at is the last time any scan looked at the resource; verdict_since is when the current verdict was first observed in the unbroken run that leads to it. A scan that did not contain the resource does not break the run, so verdict_since can span weeks nobody measured. How current a row is comes from last_checked_at and in_latest_scan, not from verdict_since alone.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes |
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. On top of that the description discloses genuinely non-obvious semantics: n_resources counts resources ever seen while current_verdict_mix and n_payable_last_full count only the latest full scan, and verdict_since can span unmeasured weeks because a scan missing the resource does not break the run. That is real behavioral context an agent cannot derive from annotations.
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?
With no output schema, the field-by-field explanation is load-bearing rather than padding, and it is front-loaded with the purpose and field inventory before the caveats. A few clauses restate the same latest-full-scan distinction (n_resources vs current_verdict_mix/n_payable_last_full), which costs some tightness, but overall every sentence earns its place.
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?
Because there is no output schema, the description carries the full burden of explaining returned fields and does so thoroughly, including the subtle veracity caveat about verdict_since. The one real hole is the undocumented 'host' argument, which leaves an agent guessing at input format. For an otherwise complex read-only summarizer, it is close to complete.
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 one required parameter, 'host', and schema description coverage is 0%. The description never says what form the host argument takes (hostname, identifier, URL fragment) or how to obtain it, so the single parameter is undocumented in both the schema and the prose. With one parameter and no coverage, the description should have compensated and does not.
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 first clause states a specific verb and resource ('Summary for a host') and explicitly bounds scope with '(no time series)', which is a meaningful disambiguation from time-series siblings. It immediately enumerates the returned fields, so an agent knows exactly what it gets. It does not name a sibling tool to contrast against, but the sibling set (drift_status, payability_verdict, etc.) does not obviously overlap, so this is a minor gap.
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?
Nothing states when to call this versus alternatives like payability_verdict or catalogue_stats, nor any prerequisites such as whether a scan must exist first. The guidance about interpreting last_checked_at vs verdict_since is about reading results, not about choosing the tool. Usage is only implied by the tool's name and scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest payability observation for one exact resource URL (path and query included), with the meaning of the verdict, remediation if it cannot be paid, and the per-network options seen. last_checked_at is the last time any scan looked at the resource; verdict_since is when the current verdict was first observed in the unbroken run that leads to it. A scan that did not contain the resource does not break the run, so verdict_since can span weeks nobody measured. How current a row is comes from last_checked_at and in_latest_scan, not from verdict_since alone.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the safe-read profile (readOnly, idempotent, non-destructive); the description adds real temporal semantics beyond that, explaining that verdict_since can span unmeasured weeks because scans lacking the resource don't break the run, and that currency derives from last_checked_at and in_latest_scan. It does not cover error behavior when the URL is unknown.
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-loads what the tool returns, then immediately qualifies the two timestamp fields whose naive reading would mislead. The density is justified because there is no output schema to explain these fields elsewhere; no sentence is 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?
With one parameter, no output schema, and only read-only annotations, the description responsibly covers both the payload contents and the timestamp interpretation that an agent would otherwise get wrong. What is missing is the not-found/no-data case and any auth or scope prerequisite.
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 coverage is 0% and the only property is a bare 'Url' title, so the description must carry the load. It does so by specifying that the URL must be exact and include path and query, which is meaningful input guidance. It could still state matching rules or failure on no-match.
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 resource and operation: the latest payability observation for one exact resource URL, enumerating what comes back (verdict meaning, remediation, per-network options). It is clearly distinct from siblings like host_summary or find_endpoints in tone, but it never names an alternative to route the agent explicitly.
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?
Usage is implied rather than stated: the parenthetical '(path and query included)' signals this is a per-URL lookup, not a host- or catalogue-level one, which is the key selection constraint against host_summary/catalogue_stats. There is no explicit when-to-use or when-not-to-use statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Published weekly payability reports (from the signed manifest).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds that the reports are weekly and derived from the signed manifest, but it does not describe the response shape or any filtering behavior. This is acceptable but not rich.
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?
The description is a single short phrase with no filler, and the key resource is front-loaded. It could be improved by adding a verb, but it is not bloated.
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 parameter-free, read-only report listing tool, the description provides enough context to invoke it: it returns published weekly payability reports from the signed manifest. The lack of an output schema is mitigated by the clear noun phrase, though the exact report contents are unspecified.
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 has zero parameters and schema description coverage is 100%, so there is nothing for the description to add. Baseline 4 applies for parameter-free tools.
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 identifies a specific resource (weekly payability reports) and its source (signed manifest), but it lacks an explicit verb such as 'list' or 'retrieve.' It is distinguishable from payability_verdict by the word 'reports,' but the intended action is only implied.
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 guidance on when to use this tool versus siblings like payability_verdict or verify_signature. No context is given for choosing reports over alternatives, so the agent must infer the use case from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Offline EIP-191 verify of a signed nsgoods response. Identifies the service from the
manifest (or the optional service arg), strips exactly that service's post-sign fields,
canonicalises (JCS, both ASCII modes), recovers the signer and checks it against the
published manifest signers. Reproduction-attestation (JCS/byte-length) and envelope
(signer/signature, components) shapes are reported as unsupported_shape, not verified here.
Refusals carry a distinct status: malformed_signature (signature is not a 65-byte 0x-prefixed
hex string), schema_rejected (the body carries a signed_by/signature pair but fails the required
field shape for every service the claimed signer covers; recovery was not attempted, checked is
false, reasons lists the failed candidates), signature_mismatch (well-formed but recovers a
different address than signed_by under every candidate service recipe of this signer),
no_flat_recipe (signed_by is a manifest signer but every service it covers uses an envelope shape,
so there is no flat recipe to check; recovery was not attempted, checked is false),
unknown_signer (signed_by is not a manifest signer; recovery was not attempted, checked is false),
unsupported_shape, or the no-signed_by/signature-pair case.
checked is true only when EIP-191 recovery actually ran; every other refusal reports checked false.
| Name | Required | Description | Default |
|---|---|---|---|
| service | No | ||
| response_json | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations declaring readOnlyHint, openWorldHint, and idempotentHint, the description adds substantial behavioral detail: offline processing, canonicalisation, signer recovery, and the full catalog of refusal statuses with exact conditions for each. It even explains when 'checked' is true/false. This goes far beyond the annotations and sets accurate expectations.
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?
The description is dense and long, but every sentence adds critical information about statuses and behavior. It is front-loaded with the core purpose and then expands into necessary edge cases. While a more structured list might improve readability, the substance justifies the length.
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, the description explains the result statuses and the 'checked' flag, which covers most of what an agent needs. It does not explicitly state what a successful verification response looks like (e.g., a status field with 'verified'), which is a minor gap, but the refusal cases are thoroughly documented.
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 0%, so the description carries the burden. It explains `service` as an optional override ('or the optional `service` arg') and `response_json` as the signed nsgoods response. Both parameters are given meaningful context, though the exact format or constraints of response_json are not detailed.
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 opens with 'Offline EIP-191 verify of a signed nsgoods response', a specific verb and resource that distinguishes this tool from all siblings. It clearly states what the tool does and its scope, leaving no ambiguity about its purpose.
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?
The description gives clear context: it handles signed nsgoods responses and can optionally take a service argument. It also explicitly states when it will not verify (unsupported_shape cases), though it does not name alternative tools because none appear to exist. This is clear contextual guidance with exclusions, just short of explicit 'use this instead of X' routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current x401 emitter adoption across the scanned catalogue (from the daily watcher).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 the 'daily watcher' provenance, which is a small behavioral context beyond the annotations. No contradiction.
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?
A single, front-loaded sentence that names the resource, scope, and data source. No wasted words.
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 zero-parameter read-only status tool with strong annotations, the description is nearly complete. It could name the sibling it complements (e.g., drift_status) or describe the output shape, but the absence of an output schema and the simple status nature make this a minor gap.
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 has zero parameters, so there is no parameter semantics burden. The description adds meaning about what the status represents, which is sufficient for a no-argument tool.
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 states a specific resource ('x401 emitter adoption') and a scope ('across the scanned catalogue'), with a source hint ('from the daily watcher'). It is clear enough to distinguish from siblings like drift_status or catalogue_stats, though it does not explicitly name a sibling it is not.
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?
The description implies this is a status/read tool for the scanned catalogue, and the sibling list includes other status-like tools (drift_status, catalogue_stats). It does not explicitly state when to use this vs alternatives, but the 'current ... adoption' phrasing gives reasonable context for a status check.
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.
verify_signature1 field changedInput schema / properties / serviceAdded value: +{
+ "default": "",
+ "title": "Service",
+ "type": "string"
+}find_endpoints1 field changedInput schema / properties / networkAdded value: +{
+ "default": "",
+ "title": "Network",
+ "type": "string"
+}catalogue_statsdrift_statusfind_endpointshost_summarypayability_verdictreportsverify_signaturex401_statusOpen, permissionless discovery marketplace for x402-payable resources. No account or KYC required.
Read-only discovery for exact-commit Agent Skill validation, x402 payment, and signed receipts.
Discover machine-payable APIs, probe x402 payment terms, and run seller operations. Non-custodial.
Read-only on-chain receipt check for x402 payments; confirm settlement before trusting a tx.
Add one secure layer between your agents and this server.
