A
licenseA
qualityF
maintenanceCounterparty risk scoring for agentic commerce. Scores wallets, domains, IPs, and companies 0-100 before AI agents transact via x402 micropayments on Base
1
3
MIT
pulsefeed-x402-mcp
by Nikolife2016
The PulseFeed x402 MCP server equips AI agents with tools to safely navigate x402 payment endpoints. It provides three main capabilities:
Discover live x402 services (
x402_working_services): Retrieve a list of alive x402 services ranked by trust score, helping avoid the ~85% that are dead, invalid, or scams (free).Verify endpoints (
check_x402_endpoint): Before paying, check an unknown endpoint for liveness, valid x402 challenge, price, network, and a pay/avoid verdict (free).Explore PulseFeed products (
pulsefeed_products): Browse PulseFeed's paid x402 offerings, including real-time Base on-chain intelligence like token pulse, whale alerts, smart-money analysis, momentum signals, and the x402 trust oracle, along with payment instructions.
PulseFeed
Verify before you pay or install.
Two questions an agent has to answer before it acts, and neither is answered by a scanner that only looks at the present:
Is this x402 endpoint safe to pay? — liveness, a 0–100 trust score, scam flags (receiver swapped, catalog price ≠ challenge price, honeypot receiver, testnet listed as production), with a pay/avoid verdict and on-chain proof links on Base.
Did this MCP server or npm package change after people adopted it? — an install script added in a later version, ownership swapped, repository removed, package unpublished, build provenance lost.
The second question is the one static scanners cannot answer. A rug pull is clean at review
time by construction: the package collects installs for weeks, and only then ships the patch
that runs code on npm i. Answering it requires yesterday's snapshot to exist, which is why
the series here starts on 2026-07-30 and cannot be reconstructed after the fact.
PulseFeed re-audits the whole MCP registry every night and diffs it against the previous day's snapshot, and re-probes the x402 endpoint population daily. Everything below is free, needs no key, and no account.
MCP server
Hosted, no install:
https://pulsefeed.dev/mcp-serverStreamable HTTP. Also on the official MCP registry, Smithery and Glama.
Or run it locally — see mcp/:
npx pulsefeed-x402-mcpTools include check_x402_endpoint (is this endpoint safe to pay), mcp_check_server
(audit before installing), mcp_drift_check (the rug-pull check — pass your own
dependency list), mcp_security_report, x402_incidents and x402_changes.
Related MCP server: x402 Endpoint Trust
Drift badge
Put it in your README. It states what changed in your package after people adopted it:
[](https://pulsefeed.dev/mcp/drift)Use your registry name (io.github.you/your-server) or your npm package name.
A green badge is a public claim about your package, so it is only issued when the package is
actually in our snapshot. When it is not, the badge reads unwatched in grey — never
green. Reporting absence of measurement as evidence of cleanliness is a mistake we made once
publicly and will not repeat; see the correction.
CI check
Fails the build when something you already depend on changes dangerously:
- uses: Nikolife2016/mcp-drift-action@v1Marketplace · source. Run it on a schedule, not only on pull requests — drift happens between your commits.
Free API
No key, CORS enabled, safe to call from a browser or a catalog page:
# what changed, whole registry
curl -s "https://pulsefeed.dev/mcp/drift.json?days=7"
# only your dependencies
curl -s "https://pulsefeed.dev/mcp/drift.json?packages=pkg-a,pkg-b&days=7"
# is this x402 endpoint payable
curl -s "https://pulsefeed.dev/verify?endpoint=<url>"Subscribe without signing up — the filter lives in the URL, so there is no subscriber database and nothing to leak:
https://pulsefeed.dev/mcp/drift.rss?packages=pkg-a,pkg-bFull spec: /openapi.json.
Open data
Live feed: pulsefeed.dev/mcp/drift
Ecosystem state: pulsefeed.dev/status.json
Dataset: Nikolife/pulsefeed-x402-security
On being wrong in public
We once published that 76% of x402 endpoints were dead. That measured our own parser, not the market, and the figure was corrected twice more after that — each time downward, each time for the same class of reason: our own behaviour recorded as somebody else's track record. The whole mechanism, every correction and the checklist that came out of it are kept at pulsefeed.dev/correction rather than quietly deleted.
If you find a number here that does not hold, open an issue — that page is where it will end up.
What's in this repository
the MCP server ( | |
| |
published series and snapshots | |
| manifest for the official MCP registry |
License
MIT
Available Tools
3 toolscheck_x402_endpointAInspect
Before paying an unknown x402 endpoint, check whether it is live and returns a valid x402 payment challenge. Returns liveness, price, network and a pay/avoid verdict. For full uptime + reputation, use PulseFeed's paid /trust API.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The x402 endpoint URL to verify |
TDQS
A4.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool returns liveness, price, network, and verdict, implying a read-only operation. However, it does not mention potential side effects, authentication needs, or rate limits, leaving room for more transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences front-load the purpose and include a sibling reference. Every sentence adds value without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description explains what it checks and what it returns (liveness, price, network, verdict). It could be more complete by detailing the return structure, but it covers the essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'url' parameter. The description does not add additional parameter semantics beyond the schema's description, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool checks whether an x402 endpoint is live and returns a valid payment challenge. It distinguishes from sibling tools by suggesting PulseFeed's /trust API for full reputation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies 'before paying an unknown x402 endpoint' as the usage context and directs to PulseFeed's /trust API for 'full uptime + reputation', providing clear when-to-use and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pulsefeed_productsAInspect
List PulseFeed's paid x402 products — real-time Base on-chain intelligence for AI agents: token pulse, whale alerts, smart-money accumulation/distribution, momentum, and the x402 trust oracle — and how to pay via x402.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes a read-only listing operation and adds context on payment via x402, but doesn't mention authentication needs or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no waste; front-loaded with the core purpose and includes key details concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters or output schema, the description adequately covers the tool's purpose and the nature of its output (product list with categories and payment info).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. The description adds value beyond schema by listing product categories and payment method, which informs tool usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List PulseFeed's paid x402 products' with a specific verb and resource, distinguishing it from siblings like x402_working_services and check_x402_endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied for viewing available products and payment info, but no explicit when-to-use or alternatives compared to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
x402_working_servicesAInspect
List x402 agent-payment services that are currently ALIVE and return a valid x402 challenge, ranked by trust score. About 85% of x402 endpoints are dead or invalid — use this to avoid paying broken or scam endpoints. Free.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the tool as returning alive services with valid challenges, ranked, and free. Adequately transparent for a no-parameter read operation, though no annotations exist to shift burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste, front-loaded with purpose and key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficient for a simple list tool: covers purpose, usage, behavioral context. No output schema, but return semantics (alive, challenge, trust rank) are implied. Could specify output structure more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema coverage 100%. Baseline 4 is appropriate as description need not add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists alive x402 agent-payment services ranked by trust score. Distinguishes from sibling 'check_x402_endpoint' (individual check) by being a batch list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this to avoid broken/scam endpoints and mentions ~85% dead rate. Implicitly distinguishes from check_x402_endpoint, but lacks explicit when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
3 tool updates
v0.1.0- First observed
check_x402_endpoint - First observed
pulsefeed_products - First observed
x402_working_services
TDQS
A4.2/5.0
Disambiguation5/5
Each tool has a distinct purpose: listing live services, checking a specific endpoint, and listing paid products. No overlap in functionality.
Naming Consistency4/5
Uses snake_case consistently, but the prefix varies ('x402_', 'check_x402_', 'pulsefeed_'), so the pattern is not fully uniform though still clear.
Tool Count4/5
Three tools is slightly low but appropriate for the focused domain of x402 endpoint discovery and product listing; each tool earns its place.
Completeness3/5
Core workflow is covered (list live endpoints, check endpoint, list products), but missing tools to actually pay or access detailed trust data from the paid API.
Maintenance
ActivityActive
ResponsivenessResponsive
Related MCP Connectors
AI agent execution safety via x402 micropayments: risk scoring, integrity, memory checks
Counterparty risk scoring for agentic commerce via x402 micropayments.
Inspect and validate an x402 endpoint before an autonomous agent spends USDC.
Pay-per-call safety checks for AI agents: screen a crypto address or URL before you transact.
Related MCP Servers
- AlicenseAqualityAmaintenancex402-trust gives AI agents a "check before you pay" layer for the x402 ecosystem.13245MIT
attest-mcpofficial
AlicenseAqualityDmaintenanceEnables AI agents to scan payment endpoints for safety, returning a letter grade (A–F) and verdict before authorizing payments.243MIT- AlicenseNot gradedqualityCmaintenanceCrypto compliance tools for AI-agent payments: screen any address for sanctions, frozen-stablecoin and hacker/mixer exposure across 8+ chains, trace fund taint, and get an allow/review/decline decision before settlement. Free keyless address checks; deeper endpoints are x402-payable.68MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Nikolife2016/pulsefeed-x402'
If you have feedback or need assistance with the MCP directory API, please join our Discord server