Verify x402 payment endpoints before an AI agent pays: scam scan, on-chain checks, trust scores.
Scored across 11 tools
Each tool targets a distinct concern: per-endpoint safety, per-package audit, drift detection, aggregate stats, incidents, leaderboards, and samples. Even the two listing tools (x402_leaderboard and x402_working_services) differ in criteria (top-ranked vs. alive-and-valid), so no ambiguity exists.
Most tools follow a snake_case convention with mcp_ and x402_ prefixes, but a few (check_x402_endpoint, pulsefeed_products) deviate from the prefix pattern and the verb-noun style is inconsistent (check_ vs. noun-first). Still, the names are readable and predictable overall.
11 tools is well within the ideal 3-15 range and each tool serves a clear purpose in the security/ecosystem monitoring domain, making the set feel appropriately scoped without being bloated or thin.
The surface covers individual checks (endpoint, package), change detection, aggregate reports, ecosystem stats, incidents, leaderboards, samples, and product listings. There are no obvious dead ends or missing core operations for the stated purpose.
Before paying an unknown x402 endpoint, check whether it is safe: liveness, trust score (0-100), anomaly flags (receiver address changed between observations, catalog price vs. challenge price, invalid receiver, testnet listed as production, scheme outside the x402 spec), receiver stability and observation-count-qualified uptime — with a pay/avoid verdict. Reads the challenge from both the response body and the v2 PAYMENT-REQUIRED header. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The x402 endpoint URL to verify |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds detailed behavioral traits: it reads the challenge from both response body and header, performs multiple checks, and provides a verdict. No contradictions with 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?
The description is a single sentence but packs substantial information without redundancy. Front-loaded with the key action. Slight improvement could be breaking into multiple sentences for readability, but it remains efficient.
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?
The tool has multiple checks and no output schema. The description mentions a verdict but does not detail the return structure (e.g., exact fields returned or error handling). Given the complexity, more completeness would be beneficial.
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?
Only one parameter 'url' with schema description 'The x402 endpoint URL to verify'. Schema coverage is 100%, so baseline is 3. The description does not provide additional parameter semantics beyond what the schema states, but the parameter is straightforward.
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 states the tool's purpose: checking safety of an unknown x402 endpoint before paying. It lists specific checks (liveness, trust score, anomaly flags, receiver stability, uptime, verdict). This distinguishes it from siblings like x402_changes or x402_data_sample, which have different focuses.
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 explicitly says 'Before paying an unknown x402 endpoint', indicating the primary use case. It does not mention when not to use or provide alternative tools, but the context is sufficiently clear for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Before installing an MCP server or npm package, audit it: does it run an INSTALL SCRIPT (arbitrary code execution at npm i), is it abandoned, does it ship a repository and license, weekly downloads, provenance — with a safe/caution/avoid verdict. ~11% of audited MCP servers run install scripts. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| package | Yes | npm package name of the MCP server, e.g. @scope/name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare safety hints (read-only, open-world, idempotent, non-destructive). The description adds valuable behavioral context: it checks for install scripts, abandonment, repository/license, downloads, provenance, and provides a verdict. No contradictions.
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 two sentences long, front-loaded with the core purpose and details, and every sentence adds value (what it checks, frequency of issue, cost). No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and simple audit functionality, the description covers the main checks and verdict categories. It could hint at output format but overall is sufficiently 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?
With only one parameter and 100% schema coverage, the schema already documents 'package' with example format. The description does not add further semantics beyond the schema, meeting the baseline.
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 explicitly states the tool's purpose: auditing an MCP server or npm package before installation. It uses specific verbs ('audit') and resources (npm package) and distinguishes from siblings by focusing on pre-install safety checks.
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 clearly indicates when to use the tool ('Before installing...'), but does not explicitly mention when not to use it or alternatives among siblings. It provides a strong usage trigger.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The rug pull check. mcp_check_server answers whether a package is safe TODAY; this answers what CHANGED after it was adopted: an install script added in a later version (arbitrary code on npm i that was not there at review time), package ownership swapped, repository removed, package unpublished, build provenance lost. Pass your own dependency list to check it in one call. Derived from a daily external re-audit of the whole MCP package population — an event exists only because a snapshot from before it exists. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Window in days (default 30) | |
| packages | No | npm package names to check, e.g. your installed MCP servers. Omit for the whole ecosystem feed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable context beyond annotations: it is derived from a daily external re-audit, an event exists only when a prior snapshot exists, and the tool is free. It does not contradict any annotation.
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 but every sentence earns its place: it names the tool's purpose, lists concrete drift types, routes to the sibling alternative, explains the data source, and states cost. The key differentiator ('what CHANGED') is front-loaded in the title and first line.
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 2-parameter, fully-optional-parameter tool with rich annotations, this is nearly complete: the agent knows what events are detected, how the tool relates to siblings, and why snapshots matter. It lacks an explicit description of the response shape, which would be moderately helpful since there is no output schema.
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 100%, so the baseline is 3. The description reinforces that packages are npm package names and that users should pass their own dependency list, but it adds no new parameter semantics beyond what the schema already documents. The 'omit for the whole ecosystem feed' guidance is already in the schema description.
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 the tool as 'the rug pull check' and explicitly states it answers what CHANGED after adoption, with concrete examples (install script added, ownership swapped, repository removed, unpublished, provenance lost). It clearly distinguishes itself from the sibling mcp_check_server, which checks current safety rather than drift.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly contrasts this tool with mcp_check_server ('answers whether a package is safe TODAY; this answers what CHANGED after it was adopted'), giving the agent a clear selection rule. It also tells the user to pass their own dependency list to check it in one call, making the intended invocation flow explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
State of MCP Security: how many audited MCP servers run an arbitrary install script, are abandoned, ship no repository or license — with day-over-day deltas and a sample of currently-flagged servers. From a daily audit of the MCP server catalog. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, open-world, idempotent, non-destructive behavior. The description adds valuable context about the data source (daily audit of MCP server catalog), the report contents (counts, deltas, samples), and that it is free. This exceeds the baseline and provides a clear behavioral picture without contradicting 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?
The description is two sentences, with the first sentence densely listing key metrics and the second providing the data source and cost. Every clause adds information, and there is no redundancy with annotations or schema. The structure is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does a good job of explaining what the tool returns (counts, deltas, sample) and its provenance. However, it does not specify the exact return format (e.g., JSON structure) or any caveats about the daily audit. Still, it is sufficiently complete for an overview report tool with rich annotations.
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 the description does not need to explain parameter semantics. The schema coverage is 100% (no properties), and the description appropriately focuses on the report content rather than parameters, earning the baseline of 4.
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 states that the tool provides a state of MCP security, detailing specific metrics (arbitrary install scripts, abandonment, missing repository/license) and outputs (day-over-day deltas, sample of flagged servers). This distinguishes it from sibling tools focused on x402 endpoints, pulsefeed products, etc.
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 when to use the tool (when wanting an overview of MCP security) and notes it's from a daily audit, but it does not explicitly state when not to use it or mention alternatives. The context and sibling names suggest a comparison tool (mcp_check_server) exists, but no direct guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List PulseFeed's products. All data endpoints are FREE since 2026-09-02 (trust checks, track records, datasets, drift history); only on-chain token signals are x402 pay-per-call. Formerly: deep trust check, endpoint track record, bulk trust dataset, and the cross-domain Data API. Includes the client-side spend-cap gotcha for x402-fetch.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, so the description does not need to restate those. It adds useful behavioral context: pricing changed on 2026-09-02, only on-chain signals are pay-per-call, and there is a client-side spend-cap gotcha to be aware of. The gotcha mention is vague but still signals an important caveat.
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 main purpose is front-loaded in the first sentence, and the pricing/historical-name context is packed efficiently. The final phrase about the client-side spend-cap gotcha is cryptic and does not explain what the gotcha is, which slightly reduces clarity without making the description 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 zero-parameter, read-only product-listing tool, the description gives enough context: what is listed, current pricing model, legacy names, and a warning. It does not describe the exact return shape, but no output schema exists and the operation is simple enough that this is 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 input schema has zero parameters, so there is nothing for the description to clarify about parameter meaning. The baseline for 0-parameter tools is 4, and the description does not need to compensate for missing parameter documentation.
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?
Description opens with a specific verb and resource: 'List PulseFeed's products.' It clearly identifies the tool as a catalog/pricing reference, and the pricing note distinguishes it from the x402 sibling endpoints. It does not explicitly name a sibling tool for comparison, 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?
The description implies the tool should be used to learn which PulseFeed products are free versus pay-per-call, and it mentions 'Formerly' names that agents may encounter. However, it never explicitly states when to prefer this tool over the sibling x402 tools, nor does it give exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What changed in the x402 ecosystem recently: services that stopped returning a valid challenge, receiver (payTo) changes, price changes, recoveries, newly-seen services. Derived from compounding time-series that cannot be reconstructed after the fact. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Window in days (default 7) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive. The description adds valuable behavioral context: it is derived from compounding time-series that cannot be reconstructed, warning that missed data is permanently lost, and it states the tool is 'Free' (cost implication). No contradiction with 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?
A single, well-structured sentence that front-loads the core purpose, then enumerates the change categories, and concludes with the crucial caveat and cost note. Zero wasted words, efficient and scannable.
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 no output schema, the description is sufficient. It explains what changes are covered, the data's irrecoverability, and the free nature. It does not specify the output format, but given the simplicity and annotations, this is not a critical omission.
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 sole parameter `days` is fully described in the schema (window in days, default 7), and schema coverage is 100%. The description does not add any additional parameter-level meaning, but given full schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('changed') and resource ('x402 ecosystem') with a clear scope: recent changes in challenges, payTo, prices, recoveries, and new services. This distinguishes it from siblings like x402_incidents (incident reports) and x402_ecosystem_stats (aggregate statistics), making its purpose unmistakable.
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?
Provides clear context: it reports recent changes and notes that the underlying time-series cannot be reconstructed after the fact, implying the tool is for current/recent state and not historical queries. However, it does not explicitly name alternative tools or conditions for when not to use it, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE sample of the PulseFeed Data API: top-10 live x402 services as FULL records (compounding payTo/price history, anomaly flags, on-chain receiver profile), top-10 MCP servers with full audit profile, and 3 live incidents.
| 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, ensuring the agent knows it is safe. The description adds context about the specific data returned (services, servers, incidents), which goes beyond the annotations without contradicting them.
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 efficiently conveys the tool's purpose and output, with no unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and a straightforward output, the description adequately lists the contents. However, it omits the format or structure of the returned data (e.g., JSON). Given the tool's simplicity, this is 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?
There are no parameters, so schema coverage is 100%. The description does not need to elaborate on parameters, and the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a free sample of the PulseFeed Data API, listing specific data components (top-10 x402 services with full records, top-10 MCP servers, and 3 live incidents). This distinguishes it from sibling tools like x402_ecosystem_stats or x402_leaderboard, which likely offer different aggregated or analytical data.
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 term 'FREE sample' implies it is a limited preview for initial exploration, but the description does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live health of the whole x402 agent-payment ecosystem: tracked/alive/dead counts, catalog-accuracy audit (what share of listings called 'healthy' actually work), risk-level distribution, receiver stability and on-chain receiver profiles. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds 'Free' but no additional behavioral context like rate limits or data freshness. With annotations covering safety, the description provides adequate but not rich transparency.
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 one concise sentence with a list of contents followed by 'Free.' It is front-loaded with the main purpose, no wasted words, and is easy to parse quickly.
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, no-output-schema tool with good annotations, the description covers the main metrics. It could mention data update frequency, but given simplicity, it is reasonably 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 are zero parameters, and schema coverage is 100% (trivially). Per guidelines, baseline is 4 for zero-parameter tools. No additional parameter description is needed.
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 states it provides 'Live health of the whole x402 agent-payment ecosystem' and enumerates specific metrics (tracked/alive/dead counts, catalog-accuracy audit, risk-level distribution, etc.), which clearly distinguishes it from sibling tools like check_x402_endpoint or x402_incidents.
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 says 'Free' but offers no explicit guidance on when to use this tool versus alternatives like check_x402_endpoint or x402_leaderboard. The list of contents implies it's for an overview, but lacks when-not or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Anomalies observed in live x402 endpoints by continuous independent measurement: receiver-address changes between observations, catalog price vs. challenge price mismatches, invalid receivers, testnet endpoints listed as production, payment schemes outside the x402 spec — EACH WITH AN ON-CHAIN REFERENCE on Base. Measurements, not accusations of intent. Check before paying anything. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Look-back window in days (default 30) |
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 meaningful behavioral context beyond that: it clarifies that these are measurements, not accusations of intent, and that each anomaly carries an on-chain reference on Base, which shapes expectations about data provenance and tone. It also notes the service is free, which is a usage condition. No contradiction with 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?
The description is informative and well-organized, starting with the core purpose and then expanding with specific examples and a safety note. It is somewhat verbose—the list of anomaly types could be trimmed, and 'Free' at the end is minor—but every sentence adds context about what the tool reports and why it matters. The front-loading of the main clause is effective, so a 4 is 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?
For a read-only incident listing with no output schema, the description adequately conveys the nature of returned data: anomalies with on-chain references on Base. It also includes a practical warning ('Check before paying anything') that guides agent behavior. While it does not specify the exact output structure (e.g., field names), the description gives enough context for an agent to know what to expect and when to use it. Slightly more detail on return format would push it to a 5, but this is sufficient.
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 only parameter 'days' is fully described in the schema (default 30, min/max), giving 100% schema description coverage. The tool description does not mention this parameter at all, so it adds no additional meaning beyond what the schema already provides. Baseline 3 is appropriate because the schema carries the burden and does so completely.
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 clear, specific verb and resource: 'Anomalies observed in live x402 endpoints by continuous independent measurement,' immediately differentiating this tool from generic incident lists. It enumerates concrete anomaly types (receiver-address changes, price mismatches, invalid receivers, etc.) and adds a distinctive framing ('Measurements, not accusations of intent'), making the purpose unmistakable even without sibling names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit usage cue: 'Check before paying anything,' which tells the agent when to invoke this tool (before payment decisions). It does not name alternative tools or state exclusions, but the context is clear and the directive is actionable. Sibling tools like check_x402_endpoint or mcp_security_report are not referenced, so a slight deduction for lack of explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Top x402 services ranked by the open PulseFeed Trust Score (0-100), with price and network — the most reliable live agent-payment endpoints right now. Free.
| 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, destructiveHint=false, and openWorldHint=true. The description adds that it's 'Free' and clarifies the ranking metric (Trust Score), providing useful extra context without contradicting the 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?
Single sentence that clearly states the tool's purpose and key details (ranking metric, data fields, and cost) with no unnecessary 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?
Given no output schema and no parameters, the description adequately covers the tool's function. Minor gap: no mention of output format (e.g., JSON list) or pagination, but acceptable for such a simple 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?
Input schema has zero parameters, so description coverage is 100%. No additional param info needed. Tool is straightforward; the description succinctly explains what the output includes.
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?
Specifically states the tool lists 'Top x402 services ranked by the open PulseFeed Trust Score (0-100), with price and network', clearly differentiating from sibling tools like check_x402_endpoint or x402_working_services.
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?
Implies use for getting a leaderboard of services, but provides no explicit guidance on when not to use this tool or which alternative (e.g., x402_working_services) to choose instead. The word 'Free' is a hint but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List x402 agent-payment services that are currently ALIVE and return a valid x402 challenge, ranked by PulseFeed Trust Score, plus ecosystem risk map. Use this to pick a service with a track record instead of paying an endpoint you have not checked. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Descriptions adds context beyond annotations: it returns alive services ranked by trust score and risk map, and states it's free. No contradiction with readOnlyHint, openWorldHint, idempotentHint, and destructiveHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the key purpose and usage guidance. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description mentions list of services and risk map. Adequate for a simple read-only tool with no parameters.
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?
No parameters, schema coverage 100%. Baseline of 4 is appropriate as description adds no parameter info but is not needed.
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 title and description clearly state the tool lists live x402 services ranked by PulseFeed Trust Score and includes an ecosystem risk map. This distinguishes it from siblings like check_x402_endpoint and x402_leaderboard.
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 explicitly states 'Use this to pick a service with a track record instead of paying an endpoint you have not checked,' providing clear guidance on when to use the tool and implying an alternative approach.
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.
mcp_drift_check4 fields changedInput schema / properties / days / maximumAdded value: +365Input schema / properties / days / minimumAdded value: +1Input schema / properties / days / typePrevious value: -"number"New value: +"integer"Input schema / properties / packages / maxItemsAdded value: +200x402_changes3 fields changedInput schema / properties / days / maximumAdded value: +365Input schema / properties / days / minimumAdded value: +1Input schema / properties / days / typePrevious value: -"number"New value: +"integer"x402_incidents3 fields changedInput schema / properties / days / maximumAdded value: +365Input schema / properties / days / minimumAdded value: +1Input schema / properties / days / typePrevious value: -"number"New value: +"integer"mcp_drift_checkcheck_x402_endpointmcp_check_servermcp_security_reportpulsefeed_productsx402_changesx402_data_samplex402_ecosystem_statsx402_incidentsx402_leaderboardx402_working_servicesCheck if a counterparty is safe to pay: trust/risk score for AI agents. Scam/phishing screen.
Entity verification, sanctions screening, and trust scoring for AI agents via x402 micropayments.
Screen a payee address before an AI agent pays: sanctions, mixers, scam lists, on-chain risk.
AI agent execution safety via x402 micropayments: risk scoring, integrity, memory checks
Add one secure layer between your agents and this server.
