What can you do with this server?

This MCP server lets AI agents make paid API calls (USDC micropayments via x402) to fetch Xiaohongshu (小红书) content and Chinese wholesale pricing data. It also provides payment status. Capabilities include: * xhs_get_note_detail: Fetch note details (title, description, author, stats, images, video) for a Xiaohongshu note URL or ID, with optional note type hint. * xhs_get_user_notes: Fetch a paginated list of notes posted by a Xiaohongshu user, using user ID and optional cursor. * china_wholesale_pricing_query: Query factory-direct wholesale pricing, MOQ, and supplier verification from Chinese manufacturing hubs (1688/Yiwu), using keyword, optional category filter, and max price. * agentpay_payment_status: View current payment configuration (network, amount, spending limits, mode) at no cost. All paid tools cost 0.01 USDC per call, with payments automatically handled by the server.

Which integrations are available for this server?

Provides tools for fetching Xiaohongshu note details and user-posted note lists, with each API call paid automatically in USDC via the AgentPay gateway.

How do I use AgentPay MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@AgentPay MCP Server Get wholesale prices for wireless earbuds under $3" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

AgentPay MCP Server

by yyxqqq777

Overview Schema Source Related Servers Discussions Admin

Python

Remote

AgentPay MCP Server

Agent-to-Agent micropayments via x402 + MCP — let AI agents autonomously pay for API access with USDC on Base.

Install

Option A — Remote MCP（推荐，无需本地安装）

在 Cursor / Claude / 任意支持 Streamable HTTP 的客户端添加：

https://agentpay-xhs-production.up.railway.app/mcp

官方 Registry 条目：io.github.yyxqqq777/agentpay

Option B — 本地 stdio（`uvx` / PyPI）

{
  "mcpServers": {
    "agentpay": {
      "command": "uvx",
      "args": ["mcp-server-agentpay"],
      "env": {
        "AGENT_PRIVATE_KEY": "0xYourAgentPrivateKey"
      }
    }
  }
}

只需填付款钱包私钥（需有 USDC）。网关地址已内置，一般不用改。

或永久安装：

pip install mcp-server-agentpay
# or
uv tool install mcp-server-agentpay

Related MCP server: @hpp-io/x402-mcp-bridge

Tools

Tool	Description	Cost
`xhs_get_note_detail`	Xiaohongshu note detail	0.01 USDC/call
`xhs_get_user_notes`	Xiaohongshu user posted notes list	0.01 USDC/call
`china_wholesale_pricing_query`	Factory-direct wholesale pricing (1688/Yiwu)	0.01 USDC/call
`agentpay_payment_status`	View payment config, wallet, and spending limits	Free

Example prompts

"帮我看看这条小红书笔记写了什么：https://www.xiaohongshu.com/explore/..."
"拉一下这个博主最近发的笔记，user_id=..."
"Search wholesale prices for wireless earbuds under $3"
"What's my AgentPay wallet and spending limit?"

Environment Variables

Variable	Required	Description
`AGENT_PRIVATE_KEY`	Yes（付费工具）	付款钱包私钥
`MAX_SPEND_PER_CALL`	No	单次上限（默认 `0.10`）
`GATEWAY_BASE_URL`	No	网关地址（默认已指向公网 Gateway）

How it works

MCP Client  →  mcp-server-agentpay  →  x402 Gateway  →  Paid API
              (auto 402 → sign → retry)   (verify USDC)

Tool call hits a paid API endpoint
Gateway returns 402 Payment Required with USDC payment details
MCP server signs payment and retries automatically
JSON data flows back to the LLM

Self-host the Gateway

If you operate the paid API, deploy the gateway separately:

pip install "mcp-server-agentpay[gateway]"
# .env: PAYMENT_MODE=production + upstream keys + your receive wallet
agentpay-gateway

Real USDC settlement (x402)

Mode	Behavior
`PAYMENT_MODE=demo`	Local fake pay (dev only)
`PAYMENT_MODE=production`	Official Facilitator verify + settle on-chain

Testnet (Base Sepolia) — use https://x402.org/facilitator, network eip155:84532.

# Fund a test agent with Sepolia USDC, then:
PYTHONPATH=src python scripts/test_x402_settlement.py

Mainnet — set PAYMENT_NETWORK=eip155:8453 and a mainnet facilitator (https://api.cdp.coinbase.com/platform/v2/x402 or PayAI). USDC goes to WALLET_RECIPIENT_ADDRESS.

See .env.example.

Publish to MCP Registry

This package is designed for the official MCP Registry.

# 1. Publish to PyPI
pip install build twine
python -m build && twine upload dist/*

# 2. Publish to MCP Registry (packages + remotes)
./scripts/publish_all.sh

Or create a GitHub Release (v0.1.0) — Actions uses Trusted Publishing to PyPI then updates the Registry.

Before publishing, update server.json and README mcp-name with your GitHub namespace (io.github.<username>/agentpay).

Development

git clone https://github.com/yyxqqq777/mcp-server-agentpay
cd mcp-server-agentpay
python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"
pytest tests/ -v

License

MIT

Available Tools

4 tools

agentpay_payment_statusCheck AgentPay payment statusA

Read-onlyIdempotent

Inspect

Return AgentPay payment configuration without charging: network, price, spending limit, payment mode, gateway URL, and agent wallet address. Call this before paid tools to verify the wallet is configured, or after a payment error.

ParametersJSON Schema

Name	Required	Description	Default
`include_wallet`	No	If true (default), include the derived agent wallet address from AGENT_PRIVATE_KEY.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior4/5

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

The annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds the key behavioral trait that this operation does not charge, which is not covered by the annotations, providing extra transparency about side effects.

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?

The description is concise, consisting of two sentences that deliver essential information without unnecessary detail or repetition. It is well-structured and easy to parse.

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

Completeness5/5

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

The description is complete for the tool's purpose: it states what is returned, when to call it, and that it does not charge. No additional context is needed for an agent to decide whether and how to use it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The sole parameter 'include_wallet' has a clear description explaining its effect ('include the derived agent wallet address') and its default value (true). This fully covers the parameter's semantics, leaving no ambiguity.

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 the tool's function: returning AgentPay payment configuration. It enumerates the specific fields (network, price, spending limit, payment mode, gateway URL, agent wallet address) that will be returned, making the purpose unambiguous.

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?

The description provides explicit guidance on when to use the tool: 'Call this before paid tools to verify the wallet is configured, or after a payment error.' This directly tells the agent the appropriate contexts for invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

china_wholesale_pricing_queryQuery China wholesale pricingA

Read-onlyIdempotent

Inspect

Search factory-direct wholesale pricing samples for a product keyword (1688 / Yiwu style catalog). Returns items with MOQ, unit price USD, factory location, and supplier verification flags. Use for China sourcing research. Settles ~0.01 USDC via x402 per query.

ParametersJSON Schema

Name	Required	Description
`keyword`	Yes	Product search query in English or Chinese, e.g. 'wireless earbuds' or '蓝牙耳机'.
`max_price`	No	Optional maximum target unit price in USD to filter results.
`category_id`	No	Optional category filter ID when the user specifies a catalog category.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

The description discloses that the tool performs a search (read-only) and incurs a micro-transaction, which is transparent about its behavioral side effects. Annotations (readOnlyHint, idempotentHint) reinforce this, and there is no contradiction between the description and 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured, covering the core function, output summary, and cost in a few sentences. It is free of redundancy and directly addresses the tool's primary use case without unnecessary elaboration.

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?

The description adequately conveys the tool's output (item list with MOQ, price, location, verification) and mentions the cost, which is important for an agent to decide whether to invoke it. It does not detail error handling or pagination, but these are not essential for the core use case and the provided context (output schema exists) is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All three parameters have detailed descriptions: 'keyword' is explicitly defined with an example (English or Chinese), 'max_price' is described as an optional maximum unit price filter, and 'category_id' is explained as an optional catalog category filter. The schema coverage is 100% and the descriptions add meaningful context beyond the names.

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 the tool's function: searching factory-direct wholesale pricing samples for a product keyword. It specifies the domain (1688/Yiwu style catalog) and the key output attributes (MOQ, unit price USD, factory location, supplier verification flags), 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.

Usage Guidelines4/5

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

The description provides practical guidance by stating 'Use for China sourcing research' and mentions the cost of ~0.01 USDC per query. It does not explicitly contrast with sibling tools, but the distinct domain (China wholesale pricing vs payment status or xhs notes) makes the usage context clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xhs_get_note_detailGet Xiaohongshu note detailA

Read-onlyIdempotent

Inspect

Fetch one Xiaohongshu (小红书) note by share URL or 24-char note_id and return title, description, author, engagement stats, images, and video URL as JSON. Call this when the user pastes an xiaohongshu.com/explore link or a note id. Settles ~0.01 USDC via x402 on each successful call.

ParametersJSON Schema

Name	Required	Description	Default
`note`	Yes	Xiaohongshu note share URL or 24-character hex note_id. Example: https://www.xiaohongshu.com/explore/6a95a1f30000000026019ab7
`note_type`	No	Optional media hint to speed lookup: image, video, 图文, or 视频.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior1/5

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

The description transparently discloses a payment side effect ('Settles ~0.01 USDC via x402 on each successful call'), but this contradicts the idempotentHint annotation: repeated identical calls would incur repeated payments. It also tensions with readOnlyHint, which implies no state-changing side effects. Because the description contradicts the annotations, the score is 1.

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?

The description is three focused sentences with no filler: what it fetches, what it returns, when to call it, and the payment detail. Every sentence serves a purpose.

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?

The description covers the input format, output contents, trigger condition, and cost side effect. Since an output schema is present, detailed return-structure documentation is unnecessary, though error handling or failure behavior is not mentioned.

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% with clear explanations of both parameters, including examples and the optional note_type hint. The tool description adds little beyond the schema, so it remains at the baseline for high schema coverage.

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 uses a specific verb ('Fetch') and identifies the exact resource (one Xiaohongshu note by URL or 24-char note_id) plus the returned fields. It clearly distinguishes this from sibling tools like xhs_get_user_notes.

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?

It explicitly states when to call the tool ('when the user pastes an xiaohongshu.com/explore link or a note id'), providing clear context. It does not mention when not to use it or alternatives, so it misses the full 'when-not/alternatives' bar.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xhs_get_user_notesList Xiaohongshu user notesA

Read-onlyIdempotent

Inspect

List posted notes for a Xiaohongshu user_id (paginated). Returns note summaries and next_cursor for pagination. Use when the user asks for a creator's recent posts. Settles ~0.01 USDC via x402 per page.

ParametersJSON Schema

Name	Required	Description	Default
`cursor`	No	Pagination cursor from the previous response's next_cursor. Omit or null for the first page.
`user_id`	Yes	Xiaohongshu user ID string from a profile or prior note author.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds critical behavioral context beyond annotations: the cost 'Settles ~0.01 USDC via x402 per page' and the pagination contract (returns next_cursor). These are not derivable from annotations and are essential for an agent to anticipate side effects and costs.

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?

The description is four short sentences, each earning its place: purpose, return content, usage trigger, and cost. It is front-loaded with the primary action, then essential details. No redundant or filler wording.

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

Completeness5/5

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

For a two-parameter, paginated list tool with a rich output schema and annotations covering safety, the description covers all needed call context: purpose, pagination return, usage trigger, and cost. Nothing critical is missing. The output schema exists, so return details are not the description's burden.

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%: both user_id and cursor have thorough descriptions, including the cursor's default and first-page behavior. The description's mention of 'next_cursor' and 'paginated' repeats schema information without adding new parameter-level meaning. Baseline 3 applies because the schema already fully documents parameters.

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 opens with a specific verb and resource: 'List posted notes for a Xiaohongshu user_id'. It explicitly mentions pagination and return format, and distinguishes from the sibling xhs_get_note_detail by focusing on listing rather than single-note detail. The usage hint 'Use when the user asks for a creator's recent posts' reinforces the purpose.

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?

The description gives an explicit trigger condition: 'Use when the user asks for a creator's recent posts.' It does not explicitly mention when not to use or name alternative tools, but the clear trigger covers the main selection case. A 4 reflects clear context without exclusions or alternatives.

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.

4 tool updatesSep 7, 2026

Changedagentpay_payment_status1 field changed

addedInput schema / properties / include_wallet

Added value: +{
+  "default": true,
+  "description": "If true (default), include the derived agent wallet address from AGENT_PRIVATE_KEY.",
+  "title": "Include Wallet",
+  "type": "boolean"
+}

Changedchina_wholesale_pricing_query3 fields changed

addedInput schema / properties / category_id / description

Added value: +"Optional category filter ID when the user specifies a catalog category."

addedInput schema / properties / keyword / description

Added value: +"Product search query in English or Chinese, e.g. 'wireless earbuds' or '蓝牙耳机'."

addedInput schema / properties / max_price / description

Added value: +"Optional maximum target unit price in USD to filter results."

Changedxhs_get_note_detail2 fields changed

addedInput schema / properties / note / description

Added value: +"Xiaohongshu note share URL or 24-character hex note_id. Example: https://www.xiaohongshu.com/explore/6a95a1f30000000026019ab7"

addedInput schema / properties / note_type / description

Added value: +"Optional media hint to speed lookup: image, video, 图文, or 视频."

Changedxhs_get_user_notes2 fields changed

addedInput schema / properties / cursor / description

Added value: +"Pagination cursor from the previous response's next_cursor. Omit or null for the first page."

addedInput schema / properties / user_id / description

Added value: +"Xiaohongshu user ID string from a profile or prior note author."

4 tool updatesv0.1.0Sep 7, 2026
- First observedagentpay_payment_status
- First observedchina_wholesale_pricing_query
- First observedxhs_get_note_detail
- First observedxhs_get_user_notes

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.1/5.0

Scored 2026-09-07 05:35 across 4 tools

Disambiguation5/5

Each tool targets a distinct action: payment status check, wholesale pricing search, XHS note detail, and XHS user note listing. The two XHS tools are complementary (single item vs. list) rather than overlapping, so an agent can disambiguate easily.

Naming Consistency2/5

Names mix conventions: `agentpay_payment_status` and `china_wholesale_pricing_query` are noun-heavy and lack a clear verb, while `xhs_get_note_detail` and `xhs_get_user_notes` follow a get_object pattern. The shared prefixes are helpful, but the action verbs are inconsistent and not uniformly placed.

Tool Count3/5

4 tools is at the low end of a reasonable count. The number is not problematic by itself, but it spans several unrelated domains (payment, China wholesale, Xiaohongshu), making the set feel like a small fragment of a broader service rather than a cohesive server.

Completeness2/5

The payment domain is represented only by a status check, and the data tools each provide one narrow read operation: wholesale has only a search, and XHS lacks obvious endpoints like search by keyword or fetching user profile/context. This leaves common workflows with no corresponding tool on the server.

Maintenance

ActivityMaintained

ResponsivenessUnresponsive

Resources

Need Help?

Related Servers

Related MCP Connectors

Automan B
io.github.i02202
Autonomous AI agent selling pay-per-call skills settled with x402 micropayments (USDC).
Autonomous Agents Payments & Billing Cryptocurrency
121
Agentic Endpoints A
com.oliverkiss
Pay-per-call tools for autonomous agents, settled in USDC on Base via x402.
Autonomous Agents Payments & Billing Blockchain
201
DeriveAI x402 APIs B
io.github.deriveit33z-ship-it
25 pay-per-request intelligence APIs for AI agents via x402 micropayments (USDC/Base)
AI & Machine Learning Payments & Billing Agent Orchestration
251
x402 Web Extract A
io.github.Senpi-Station
Pay-per-use web extract, token prices, and wallet balances via x402 USDC micropayments.
Web Scraping Cryptocurrency Blockchain
51

Related MCP Servers

x402 Payment Gateway MCP
Blockchain Cryptocurrency Payments & Billing
AiAgentKarl
A
license
Not graded
quality
F
maintenance
Enables AI agents to make micropayments using USDC on Solana via the x402 protocol, supporting payment requests, on-chain verification, and revenue tracking.
Updated 6 months ago (2026-04-03 16:05 UTC)
MIT
@hpp-io/x402-mcp-bridgeofficial
Cryptocurrency Autonomous Agents Payments & Billing
hpp-io
A
license
Not graded
quality
A
maintenance
Enables AI agents to autonomously pay for and discover services using HPP USDC.e over the x402 protocol, without API keys or manual signing.
Updated a month ago (2026-08-20 01:23 UTC)
93 npm
Apache 2.0
token4u-mcpofficial
AI & Machine Learning Payments & Billing Blockchain
Token4uAi
A
license
A
quality
B
maintenance
Enables AI agents to call LLM APIs via x402 micropayments in USDC on Base network, manage a local wallet, and query consumption records.
Updated 19 days ago (2026-09-04 10:54 UTC)
3
53 npm
MIT
@bridgenode/mcpofficial
AI & Machine Learning Blockchain
bridgenode-ai
A
license
A
quality
A
maintenance
Enables AI agents to make pay-as-you-go AI inference requests through x402 with automatic Solana USDC payments, no API keys or registration, while enforcing configurable spending limits.
Updated 3 days ago (2026-09-20 06:09 UTC)
3
118 npm
1
MIT No Attribution

AgentPay MCP Server

Install

Option A — Remote MCP（推荐，无需本地安装）

Option B — 本地 stdio（uvx / PyPI）

Tools

Example prompts

Environment Variables

How it works

Self-host the Gateway

Real USDC settlement (x402)

Publish to MCP Registry

Development

License

Available Tools

Output Schema

TDQS

Output Schema

TDQS

Output Schema

TDQS

Output Schema

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

x402 Payment Gateway MCP

@hpp-io/x402-mcp-bridgeofficial

token4u-mcpofficial

@bridgenode/mcpofficial

Option B — 本地 stdio（`uvx` / PyPI）