Read only x402 catalogue: payability verdicts, prices, drift, host status, signatures. No wallet.
Scored across 8 tools
Each tool targets a distinct query grain (catalogue-wide stats, per-host summary, exact-URL verdict, substring search, drift over time), so boundaries are mostly clear. Minor risk that find_endpoints and payability_verdict overlap when an agent has a partial URL, but descriptions steer correctly.
All names use snake_case and are readable; most are noun phrases (catalogue_stats, host_summary), while find_endpoints is verb-led. This is a minor deviation but not confusing.
8 tools is well within the sweet spot and each covers a distinct analytical need for the catalogue domain.
Covers aggregate stats, drift, search, host and endpoint detail, reports, signature verification, and x401 adoption, forming a full read-only analytics surface. No obvious lifecycle gaps for a catalogue monitoring server.
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 currency claim: the last time any scan or reprobe looked at this resource. in_latest_scan means only that the resource was in the latest full scan; a row reprobed the same day can carry in_latest_scan=false and still be current. 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 cover safety (readOnly, idempotent, non-destructive), and the description goes well beyond them: it caps results (max 50), discloses the total match count, and explains the tricky currency semantics of in_latest_scan, last_checked_at, and verdict_since, including the non-obvious caveat that verdict_since can span unmeasured weeks.
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?
Purpose and usage are front-loaded, which is good, but the final block repeats the in_latest_scan/last_checked_at relationship twice and spends five lines on verdict_since semantics that could be compressed. The core call information is buried under an extended caveat paragraph.
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 correctly describes the return shape (up to limit endpoints with latest verdict, plus total match count) and supplies the data-currency semantics an agent needs to interpret rows. Minor omissions: no pagination guidance and incomplete sort/limit defaults.
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%, so the description must carry all parameter meaning and largely does: query (host or URL substring), limit (max 50), network (with example values like eip155:8453), and sort=price for cheapest-first. Gaps remain — the default limit of 25, the default empty sort, and other valid sort values are not documented.
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 sentence gives a precise verb and resource: search the catalogue by host or URL substring. It also frames its own role ('Use this first when you do not know the exact resource URL'), which implicitly separates it from exact-lookup siblings, though no sibling is named 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?
States a clear when-to-use condition ('Use this first when you do not know the exact resource URL') and notes the optional network filter and sort=price shortcut. It stops short of naming alternatives or stating when-not to use it (e.g. when you already have an exact URL, use X instead).
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 currency claim: the last time any scan or reprobe looked at this resource. in_latest_scan means only that the resource was in the latest full scan; a row reprobed the same day can carry in_latest_scan=false and still be current. 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description goes well beyond them by disclosing genuinely non-obvious semantics: that in_latest_scan=false does not mean stale, that n_resources counts all-ever-seen while current_verdict_mix counts only the latest full scan, and that verdict_since can span unmeasured weeks. This is exactly the kind of context an agent cannot infer from structured fields.
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 content-summary is front-loaded and nearly every sentence carries distinct semantic payload about a field that is otherwise undocumented. It is dense and occasionally repetitive (last_checked_at is characterized twice), but there is little true 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 no output schema, the description correctly shoulders the burden of explaining return fields and does so thoroughly for the subtle ones. The remaining gaps are the 'host' argument format and behavior on a host with no records, which leaves the definition slightly short for a lookup tool.
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 single parameter 'host' has 0% schema description coverage and the description never explains what form it takes (hostname, FQDN, IP, inventory ID) or what happens if it is unknown. With total reliance on the schema, the description fails to compensate for the coverage gap.
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 (a host) and enumerates exactly what the summary contains (first/last seen, verdict mix, n_resources, verdict changes, gone_since, resources_sample), and the parenthetical '(no time series)' implicitly distinguishes it from a time-series variant. It is clear without needing to name a sibling 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?
There is no statement of when to reach for this tool versus alternatives such as catalogue_stats, drift_status, or payability_verdict. The field semantics hint at the tool's domain but never give a condition for selection or exclusion.
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 currency claim: the last time any scan or reprobe looked at this resource. in_latest_scan means only that the resource was in the latest full scan; a row reprobed the same day can carry in_latest_scan=false and still be current. 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 already declare the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower, and the description still adds substantial non-obvious behavior: the staleness semantics of in_latest_scan and the warning that verdict_since can span unmeasured weeks. It stops short of a 5 because it says nothing about authorization needs, rate limits, or what happens when no observation exists for a URL.
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?
Purpose is front-loaded in the first clause, followed by the field-semantics caveats in a logical order, and the closing sentence usefully summarizes which fields govern currency. The verdict_since point is made twice in adjacent sentences, which is mild redundancy rather than padding.
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 no parameter descriptions, the description correctly takes on the burden of explaining the returned fields, covering last_checked_at, in_latest_scan, verdict_since, the verdict meaning, remediation, and per-network options. It gestures at several of those (remediation, per-network options) without detail, so an agent still cannot anticipate the full response shape.
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 single 'url' parameter has 0% schema description coverage, so the description must carry the meaning — and it does, specifying the exact form required (path and query included, one exact resource). It does not specify URL normalization, encoding, or error behavior for unmatched URLs.
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 and scope: the latest payability observation for one exact resource URL, with path and query included. That scope statement also separates it from host- or catalogue-level siblings like host_summary and find_endpoints. It does not name any sibling explicitly, so it stops short of a 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?
Usage is only implied through the scoping clause 'one exact resource URL (path and query included)', which tells the agent this is a single-resource lookup rather than a search. There is no explicit when-to-use versus find_endpoints or host_summary, and no stated preconditions. Interpretation guidance is present, but routing guidance is not.
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 cp0x data: referral deals and races, DeFi geo-restrictions, and x402 catalogs.
Add one secure layer between your agents and this server.
