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 "Install 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 Related Servers Score Discussions

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": {
        "GATEWAY_BASE_URL": "https://agentpay-xhs-production.up.railway.app",
        "AGENT_PRIVATE_KEY": "0xYourAgentPrivateKey",
        "MAX_SPEND_PER_CALL": "0.10",
        "PYTHONUNBUFFERED": "1"
      }
    }
  }
}

或永久安装：

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
`GATEWAY_BASE_URL`	MCP	AgentPay 网关地址
`AGENT_PRIVATE_KEY`	Production	付款钱包私钥
`MAX_SPEND_PER_CALL`	No	单次上限（默认 `0.10`）
`PAYMENT_MODE`	Gateway	`demo` 或 `production`
`DATAFLOW_API_TOKEN` / `TIKHUB_API_KEY`	仅 Gateway 部署	上游数据源（不对 Agent 暴露）

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_statusAInspect

Returns current AgentPay configuration: network, amount, spending limits, and mode.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Returns', clearly indicating a read-only operation with no side effects. This is sufficient for a simple getter, though it does not explicitly mention that no modifications occur.

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 a single, concise sentence that conveys all necessary information without any fluff or redundancy. It front-loads the verb and resource, followed by the key fields.

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?

Given the tool has an output schema (as indicated by context), the description need not explain return values. It also covers the primary purpose and lists the main data returned. No additional context is needed for this simple read-only tool.

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 tool has no parameters, so there is nothing to document. The description correctly implies that the current configuration is retrieved without any inputs, making parameter semantics trivially clear.

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 returns the current AgentPay configuration with specific fields (network, amount, spending limits, mode). The verb 'Returns' and resource 'AgentPay configuration' are specific and unambiguous. There is no confusion with sibling tools, which are unrelated (user notes and pricing).

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 implies when to use this tool (whenever current AgentPay config is needed) and no alternatives are suggested among the sibling tools. However, it lacks explicit 'when not to use' guidance, but the simplicity of the getter makes it self-evident.

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

china_wholesale_pricing_queryAInspect

Fetches factory-direct wholesale pricing, MOQ, and supplier verification data from China manufacturing hubs. Requires x402 USDC micropayment.

Args: keyword: Product search query in English or Chinese category_id: Optional category filter ID max_price: Maximum target unit price in USD

ParametersJSON Schema

Name	Required	Description	Default
`keyword`	Yes
`max_price`	No
`category_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose the micropayment requirement, which is a critical behavioral trait (cost implication). However, it does not describe what happens on failure, response format (though output schema exists), or any side effects. It only reveals the payment requirement, which is useful but not comprehensive. A 3 reflects partial disclosure.

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 front-loaded. The first sentence states the purpose, the second states a key prerequisite, and the third lists parameters in a clean, readable format. No wasted words. Every sentence earns its place.

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 that the tool has an output schema, return values need not be explained. The description covers the purpose, payment requirement, and all parameters. It does not mention error handling, rate limits, or authentication beyond the payment, but these are minor for a straightforward query tool. The description is sufficiently complete for an agent to invoke it correctly.

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?

Schema description coverage is 0%, so the description must compensate. It does: for each parameter it adds meaningful semantics beyond the schema titles. 'keyword' is described as a product search query in English or Chinese; 'category_id' is an optional category filter; 'max_price' is a maximum target unit price in USD. These descriptions directly inform an agent on how to fill each field. While it doesn't provide examples or format details, it fully covers all three 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 clearly states the tool's function: 'Fetches factory-direct wholesale pricing, MOQ, and supplier verification data from China manufacturing hubs.' This is a specific verb (fetches), a specific resource (wholesale pricing/MOQ/supplier verification), and it immediately distinguishes itself from the siblings (which are social-media and payment tools). No ambiguity.

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 explicitly notes a prerequisite: 'Requires x402 USDC micropayment.' This tells the agent when the tool is usable (must have payment capability) and implies it is the tool for wholesale pricing queries. It does not explicitly name alternatives, but the sibling tools are unrelated, so the context is clear. The absence of explicit 'when not to use' is a minor gap, hence 4.

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

xhs_get_note_detailAInspect

Fetch Xiaohongshu (小红书) note detail via AgentPay: title, desc, author, stats, images, video URL. Paid with x402 USDC micropayment.

Args: note: Note share URL or 24-char hex note_id (e.g. https://www.xiaohongshu.com/explore/.... or abc123...) note_type: Optional hint — image / video / 图文 / 视频

ParametersJSON Schema

Name	Required	Description	Default
`note`	Yes
`note_type`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

The description discloses that the tool requires payment via x402 USDC micropayment, which is a significant behavioral trait. However, it does not mention potential errors, rate limits, or consequences of failed payment, so transparency is partial.

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 succinct and well-structured, with a clear summary of the tool's function followed by concise argument explanations. No redundant or confusing wording.

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 that the tool returns a note detail with multiple fields and an output schema, the description covers the main behavior and arguments. It lacks details on error handling or output structure, but the output schema likely provides that information, making it reasonably complete.

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?

The description adds meaning to the schema by explaining that 'note' accepts either a share URL or a 24-char hex ID, and that 'note_type' is an optional hint with example values. This compensates for the schema's lack of descriptions.

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 fetches Xiaohongshu note details and lists the specific fields returned (title, desc, author, stats, images, video URL). It also distinguishes itself from sibling tools by focusing on a single note via URL/ID, while xhs_get_user_notes is for user notes and agentpay_payment_status is for payment status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description does not provide explicit guidance on when to use this tool versus alternatives. It mentions payment, but not situations like 'use when you have a specific note ID'. The input format is described but no decision criteria are given.

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

xhs_get_user_notesAInspect

Fetch a Xiaohongshu user's posted notes list (paginated) via AgentPay. Paid with x402 USDC micropayment.

Args: user_id: Xiaohongshu user ID cursor: Pagination cursor from previous response next_cursor

ParametersJSON Schema

Name	Required	Description	Default
`cursor`	No
`user_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

No annotations are provided, so the description carries full responsibility. It transparently discloses the payment side effect ('Paid with x402 USDC micropayment'), which is a key behavioral trait. However, it does not mention other potential side effects (e.g., rate limits, idempotency), so it is not fully exhaustive.

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 extremely concise, consisting of two short sentences, and directly states the action, resource, pagination, and payment. No unnecessary words 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?

Given the low complexity (two parameters, simple fetch operation), the description adequately covers the essential context: what it does, pagination, and payment. It does not describe the output format, but an output schema is present, so this omission is minor.

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 schema has zero descriptions, but the description explicitly explains both parameters: user_id is the Xiaohongshu user ID, and cursor is the pagination cursor from the previous response. This fully covers parameter semantics despite the lack of schema annotations.

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 fetches a Xiaohongshu user's posted notes list, which is a specific verb and resource. It distinguishes from sibling tools like xhs_get_note_detail by specifying a list operation rather than a detail operation.

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?

The description explains what the tool does but does not explicitly state when to use it versus alternatives. It mentions pagination and payment, which provides some context, but lacks direct guidance on when to prefer this tool over xhs_get_note_detail or other siblings.

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.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool serves a clearly distinct purpose: fetching user notes, fetching note details, checking payment status, and querying wholesale pricing. No overlap or ambiguity.

Naming Consistency3/5

Tool names are descriptive but mix different prefixes (xhs_, agentpay_, china_wholesale_) rather than following a single consistent pattern. While each name is clear, the set lacks a uniform naming convention.

Tool Count5/5

With only 4 tools, the count is well-scoped for the narrow domain of querying Xiaohongshu data and wholesale pricing, with a payment status helper. It feels neither sparse nor bloated.

Completeness4/5

The tool set covers the core read operations for the stated domain (user notes, note details, pricing, payment config). It lacks write or update capabilities, but for a data-query service this is acceptable, leaving only minor gaps like user profile or search.

Maintenance

ActivityNo data

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Agentic Endpoints A
com.oliverkiss
Pay-per-call tools for autonomous agents, settled in USDC on Base via x402.
Autonomous Agents Payments & Billing Blockchain
161
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
Agent Newsstand C
com.agentnewsstand
Market data and web intelligence for AI agents, paid per call in USDC on Base via x402.
Finance Search RAG Systems
161

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 5 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
B
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 18 days ago (2026-08-20 01:23 UTC)
148
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 3 days ago (2026-09-04 10:54 UTC)
3
64
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 13 hours ago (2026-09-06 16:14 UTC)
3
544
1
MIT No Attribution

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/yyxqqq777/mcp-server-agentpay'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

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

Latest Blog Posts

MCP directory API

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