Which integrations are available for this server?

Integrates Coinbase's x402 payment protocol for automatic payment signing and retry on HTTP 402 responses. Connects to Ethereum-based ERC-8004 agent registry for on-chain agent discovery and payment settlement.

agent-discovery-mcp

Q: What can you do with this server?

This server lets your AI coding agent discover and call on-chain agents from the ERC-8004 registry, and pay them automatically using Coinbase's x402 payment protocol. * Find agents by skill (find_agents_by_skill): Search the ERC-8004 registry using a skill keyword (e.g. "summarization", "code review"), with optional filters for chain ID, x402 payment support, and result count (up to 50). * Get agent details (get_agent_card): Retrieve a specific agent's complete ERC-8004 registration card by token ID and chain, including name, description, services, x402 support, trust models, and owner address. * Call agents with automatic payment (call_agent_with_payment): Make an HTTP request to an agent's endpoint and, if the agent responds with HTTP 402, automatically sign an x402 payment using your EOA wallet and retry — all within a single tool call, with a configurable max USDC spend limit. Supports multiple chains including Ethereum Mainnet, Base Mainnet, Base Sepolia, and Ethereum Sepolia. Payments use direct EOA signing, requiring no smart contract accounts, bundlers, or third-party relays.

by ClayYTsai

Overview Schema Related Servers Score Discussions

TypeScript

Remote

agent-discovery-mcp

Available on CodeGuilds

An MCP server that lets your AI coding agent (Claude Code, OpenClaw, Codex, Cursor, etc.) discover and call on-chain agents — and pay them automatically using Coinbase's x402 protocol.

Agents register themselves on ERC-8004, Ethereum's agent identity standard. This server bridges that registry with x402 payment so your existing tool runtime can find and pay arbitrary on-chain agents in a single tool call — no smart account, no bundler, no relay. Just your EOA, an HTTPS request, and an automatic 402 → sign → retry flow.

Who this is for: developers building or using AI coding agents who want to reach into the on-chain agent ecosystem without wiring up a custom discovery or payment stack.

What it does

Three tools, exposed via Model Context Protocol:

Tool	What it does	Source of truth
`find_agents_by_skill`	Search the ERC-8004 registry for agents matching a skill keyword. Returns id, chain, name, description, endpoint, and x402-support flag.	8004scan.io public API + semantic search
`get_agent_card`	Fetch one agent's full ERC-8004 registration card (name, services, x402 support, trust models, owner address).	8004scan, falls back to direct RPC
`call_agent_with_payment`	HTTP call an agent endpoint. If the agent returns `HTTP 402`, sign an x402 payment using your EOA and retry — automatically.	`x402-fetch` (Coinbase official)

The whole server is ~250 lines of TypeScript. No smart contract account, no bundler, no third-party relay — payment is direct EOA signing per the x402 spec.

Related MCP server: @true402.dev/mcp-server

Why this exists

The pieces of an agent-to-agent economy are now real:

x402 (Coinbase's HTTP 402-based payment protocol) processes 165M+ transactions and ~$50M in volume as of April 2026.
ERC-8004 (Ethereum's agent identity standard) was deployed to mainnet on January 29, 2026 and now has tens of thousands of registered agents.
MCP (Anthropic's tool-call protocol) is the de-facto standard for connecting AI coding agents to external capability.

But there was no clean "glue" that lets a Claude Code / OpenClaw / Cursor user just discover and pay an arbitrary on-chain agent from inside their existing tool. Existing options like @azeth/mcp-server bundle ERC-4337 smart accounts and a custom trust layer on top — which forces a bundler/relay dependency that can fail in practice on testnets.

This server skips all of that. It uses:

8004scan public API for agent discovery (the canonical ERC-8004 indexer maintained by the ERC-8004 team)
Coinbase's official x402-fetch for payment — wraps native fetch to handle 402s automatically
viem for EOA signing — no contract account deployment, no bundler

The result: install, set one env var, and your agent runtime can call any x402 agent in the ERC-8004 registry.

Current status

This is a working v0.1.0 with real infrastructure underneath it, but the ecosystem is still early.

Discovery works. The 8004scan API returns real agents from the ERC-8004 registry (~70k+ registered across chains as of mid-2026).
Payment works. The x402 payment flow is end-to-end using Coinbase's official x402-fetch library and EOA signing.
Ecosystem caveat. Many agents set x402Support: true in their metadata but don't enforce a paywall on their endpoint — they accept calls for free or return 404. The flag is self-declared; nobody verifies it yet. Most production x402 traffic today flows through managed platforms (Coinbase Agent.market, AWS Bedrock AgentCore, etc.). The permissionless registry flow is real but early.

See Roadmap for what's planned next.

Install

Requires Node ≥ 20

git clone https://github.com/claynsn/agent-discovery-mcp
cd agent-discovery-mcp
npm install
npm run build

Set your wallet's private key (this is the EOA that will sign x402 payments):

export TEST_WALLET_KEY=0x...your-64-hex-private-key

TEST_WALLET_KEY is only required for call_agent_with_payment. The discovery tools (find_agents_by_skill, get_agent_card) work without it.

macOS LaunchAgent users (e.g. OpenClaw): use launchctl setenv instead, since LaunchAgent processes don't inherit your shell env:

launchctl setenv TEST_WALLET_KEY 0x...

Usage

With Claude Code

Add to .mcp.json in your project root or ~/.claude/mcp_settings.json:

{
  "mcpServers": {
    "agent-discovery": {
      "command": "node",
      "args": ["/absolute/path/to/agent-discovery-mcp/dist/index.js"],
      "env": {
        "TEST_WALLET_KEY": "${TEST_WALLET_KEY}"
      }
    }
  }
}

With OpenClaw

Add to ~/.openclaw/openclaw.json under mcp.servers:

{
  "mcp": {
    "servers": {
      "agent-discovery": {
        "command": "node",
        "args": ["/absolute/path/to/agent-discovery-mcp/dist/index.js"],
        "env": {
          "TEST_WALLET_KEY": "${TEST_WALLET_KEY}"
        }
      }
    }
  }
}

Then openclaw gateway restart.

With Cursor / Cline / any MCP-compatible client

Standard MCP stdio server. Point your client at node /path/to/dist/index.js.

Example workflow

In your AI coding agent, just ask:

Find me 5 agents on Base mainnet that can do text summarization, only ones supporting x402.

The agent calls find_agents_by_skill({ skill_keyword: "summarization", chain_id: 8453, x402_only: true, limit: 5 }) and returns real on-chain agents.

Then:

Call agent #25886 at its primary endpoint with the text "...long article...", pay max $0.05 USDC.

The agent calls call_agent_with_payment({ endpoint: "...", payload: { text: "..." }, max_pay_usdc: 0.05, chain_id: 8453 }). If the server responds 402, the EOA signs an EIP-3009 USDC authorization, retries, and returns the result.

Tools reference

`find_agents_by_skill`

{
  skill_keyword: string;       // e.g. "summarization", "code review", "price feed"
  limit?: number;              // 1-50, default 10
  chain_id?: number;           // e.g. 8453 (Base), 1 (Ethereum), 56 (BSC)
  x402_only?: boolean;         // filter to agents advertising x402 support
}

`get_agent_card`

{
  agent_id: number;            // ERC-8004 token ID
  chain_id: number;            // e.g. 8453
}

`call_agent_with_payment`

{
  endpoint: string;            // full HTTPS URL
  payload?: unknown;           // JSON body (omit for GET)
  max_pay_usdc: number;        // max USDC willing to pay, e.g. 0.10
  chain_id?: number;           // settlement chain, default 8453
}

Supported chains

Chain ID	Network	x402 settlement	Discovery
1	Ethereum Mainnet	✅	✅
8453	Base Mainnet	✅	✅
56	BSC	—	✅
84532	Base Sepolia	✅	✅
11155111	Ethereum Sepolia	✅	✅

Architecture

┌───────────────────────┐         ┌──────────────────────┐
│  Claude Code /        │  MCP    │  agent-discovery-mcp │
│  OpenClaw / Cursor    │ ──────▶ │  (this server)       │
└───────────────────────┘  stdio  └──────────┬───────────┘
                                              │
                          ┌───────────────────┼───────────────────┐
                          │                   │                   │
                          ▼                   ▼                   ▼
                   ┌────────────┐      ┌────────────┐      ┌─────────────┐
                   │ 8004scan   │      │ Base RPC   │      │ x402-fetch  │
                   │ public API │      │ (fallback) │      │ (Coinbase)  │
                   │ discovery  │      │ tokenURI   │      │ EOA signs   │
                   └────────────┘      └────────────┘      │ EIP-3009    │
                                                          └─────────────┘

No smart-contract account. No bundler. No relay. Your EOA signs, x402-fetch retries, agent's facilitator settles.

CodeGuilds

This package is listed on CodeGuilds, a directory of MCP servers and AI agent tools.

Roadmap

Endpoint health check before returning agent in find_agents_by_skill (filter out 404 demo deployments)
Verify on-chain x402Support claim by probing endpoint for 402 response
Multi-chain payment in one call (auto-select cheapest chain for USDC)
Optional integration with Coinbase Facilitator for settlement metadata
Spending-limit policy (server-side cap independent of max_pay_usdc parameter)
Receipt logging to disk for tax/audit

License

MIT

Available Tools

3 tools

call_agent_with_paymentA

Call an agent HTTP endpoint with automatic x402 payment. Uses Coinbase's official x402-fetch SDK with the EOA wallet from $TEST_WALLET_KEY. If the endpoint returns 402, signs and retries automatically (up to max_pay_usdc).

ParametersJSON Schema

Name	Required	Description
`endpoint`	Yes	Full HTTPS URL.
`payload`	No	Optional JSON body (omit for GET).
`max_pay_usdc`	Yes	Max USDC to pay (e.g. 0.10).
`chain_id`	No	Settlement chain (default 8453).

TDQS

A4/5.0

Behavior4/5

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

No annotations, so description carries full burden. Discloses automatic retry on 402, use of Coinbase SDK and EOA wallet from env var, and max payment limit. Could mention side effects (cost) and error handling, but current level is good.

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 efficient sentences front-load key purpose and behavior. No unnecessary words; every sentence adds value.

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

Completeness2/5

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

No output schema; description does not specify return value (likely HTTP response). Missing error handling details and prerequisites. Incomplete for a complex payment tool.

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 coverage is 100% with clear descriptions for all 4 parameters. The description does not add extra meaning beyond the schema; baseline 3 is appropriate.

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 the tool calls an agent HTTP endpoint with automatic x402 payment. Distinct from siblings (find_agents_by_skill, get_agent_card) which are about searching and retrieving agent info, not making paid calls.

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?

Implicitly clear: use when you need to call an agent endpoint that may require payment. No explicit exclusions or alternatives, but context is sufficient for typical use.

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

find_agents_by_skillA

Search ERC-8004 registry (via 8004scan public API) for agents matching a skill keyword. Returns up to limit candidates with id, chain, name, description, endpoint, and x402 support flag.

ParametersJSON Schema

Name	Required	Description
`skill_keyword`	Yes	Skill or capability to search for.
`limit`	No	Max results (default 10).
`chain_id`	No	Restrict to one chain (e.g. 8453 = Base mainnet).
`x402_only`	No	Only return x402-supporting agents.

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description must fully disclose behavior. It specifies the tool is a search operation that returns a limited set of candidates with specific fields, and mentions the use of a public API. It implies read-only behavior. It could be more explicit about being a read operation, but it's adequate.

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 two sentences, no unnecessary words, and front-loads the key action and source. Every sentence earns its place.

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 simple search tool with 4 parameters and no output schema or annotations, the description covers the purpose, scope, and return fields completely. It provides enough context for an agent to use the tool effectively.

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 100%, so the baseline is 3. The description adds value by explaining the return fields (id, chain, name, description, endpoint, x402 support flag) and clarifying how `limit` and `x402_only` relate to the response, compensating for the lack of an output schema.

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 verb 'Search' and the resource 'ERC-8008 registry for agents matching a skill keyword.' It distinguishes from siblings `call_agent_with_payment` and `get_agent_card`, which serve different purposes (calling and retrieving cards).

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 usage for finding agents by skill, which is straightforward. While it does not explicitly state when not to use it or provide alternatives, the context is clear enough for an AI agent to decide when to invoke it.

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

get_agent_cardA

Fetch a single agent's full ERC-8004 registration card (name, description, services, x402 support, trust models).

ParametersJSON Schema

Name	Required	Description	Default
`agent_id`	Yes	ERC-8004 token ID.
`chain_id`	Yes	Chain ID where the agent is registered.

TDQS

A3.7/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 full burden. It does not disclose behavioral traits such as whether the tool is read-only, what happens if the agent_id is invalid, or if any authentication is required. It only repeats the purpose.

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 sentence with 15 words, front-loaded with the main action and resource. Every word adds value; no redundancy or filler.

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

Completeness3/5

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

The description covers the tool's purpose but lacks details on return format, error handling, or edge cases (e.g., nonexistent agent). Given no output schema and simple parameters, it is adequate but could be more complete by stating that it returns the full card object.

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 each parameter already described (agent_id: ERC-8004 token ID; chain_id: Chain ID). The description adds no new meaning beyond the schema, so it meets the baseline of 3.

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 action ('Fetch'), the resource ('single agent's full ERC-8004 registration card'), and lists specific contents (name, description, services, x402 support, trust models). It distinguishes from sibling tools like 'call_agent_with_payment' and 'find_agents_by_skill' by focusing on fetching a single agent's detailed card.

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 implies when to use this tool (to fetch a single agent's details), but it does not explicitly state when not to use it or suggest alternatives. For example, it could mention that for searching by skill, one should use 'find_agents_by_skill', but it does not.

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 updatesv0.1.0May 26, 2026
- First observedcall_agent_with_payment
- First observedfind_agents_by_skill
- First observedget_agent_card

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 function: searching agents by skill, retrieving a detailed card, and calling an agent with payment. No overlap in purpose.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (call_agent_with_payment, find_agents_by_skill, get_agent_card), making them predictable.

Tool Count4/5

With 3 tools, the set is minimal but well-scoped for the server's purpose of discovery and basic interaction. Each tool earns its place, though a few more could be justified.

Completeness4/5

Core functionalities (search, details, call) are covered. Minor gaps exist, such as listing all agents without a skill filter or managing registrations, but agents can work around these.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

PayGate MCP — Monetization Gateway for AI Agents A
io.github.geoacpfilho
Monetize any MCP server: x402 paywall, pay-per-call billing in USDC on Base, agent marketplace.
Payments & Billing Cryptocurrency Blockchain
61
agent-x402-paywall-mcp
io.github.CSOAI-ORG
Agent x402 Paywall MCP — Coinbase HTTP 402 protocol + on-chain settlement. Agents pay per-call
Blockchain Cryptocurrency Payments & Billing
2
sovereign-engine A
io.github.invertedhoologan
15 paid AI agent primitives via x402 (USDC on Base). Pay-per-call MCP server.
AI & Machine Learning Payments & Billing Cryptocurrency
2
Pyrimid Protocol A
ai.pyrimid
Agent-commerce MCP server for x402/USDC payments and affiliate splits on Base.
Cryptocurrency Blockchain Payments & Billing
2

Related MCP Servers

x402-mcpofficial
Blockchain Cryptocurrency Payments & Billing
x402node
A
license
C
quality
D
maintenance
MCP server bringing 100+ x402-paid APIs to AI agents (Claude, Cursor, MCP-aware clients). Auto-discovers tools from CDP Bazaar; handles USDC micropayments on Base.
Updated 2 months ago (2026-07-18 20:36 UTC)
100
60
1
MIT
@true402.dev/mcp-server
AI & Machine Learning Cryptocurrency Web Scraping
true402
A
license
A
quality
A
maintenance
An MCP server that enables AI agents to access paid AI inference and web tools via HTTP 402 micropayments in USDC on Base, using the agent's wallet as identity.
Updated 15 days ago (2026-08-23 08:53 UTC)
14
564
MIT
obolpay-x402-mcp
Payments & Billing Cryptocurrency Blockchain
Hiroshi-Ichiyanagi
F
license
A
quality
B
maintenance
MCP server for a live x402 payment gateway on Base (USDC). Lets AI agents discover, preview for free, then pay per call — with prepaid gasless payments, signed receipts, and delta delivery.
Updated 21 hours ago (2026-09-06 02:56 UTC)
7
-
x402-mcp
merkleworks
A
license
Not graded
quality
D
maintenance
MCP server for the x402 protocol that lets AI agents discover and call payment-gated HTTP APIs automatically.
Updated 6 months ago (2026-03-15 22:03 UTC)
428
Apache 2.0

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/ClayYTsai/agent-discovery-mcp'

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

agent-discovery-mcp

What it does

Why this exists

Current status

Install

Usage

With Claude Code

With OpenClaw

With Cursor / Cline / any MCP-compatible client

Example workflow

Tools reference

find_agents_by_skill

get_agent_card

call_agent_with_payment

Supported chains

Architecture

CodeGuilds

Roadmap

License

Available Tools

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

x402-mcpofficial

@true402.dev/mcp-server

obolpay-x402-mcp

x402-mcp

Latest Blog Posts

MCP directory API

`find_agents_by_skill`

`get_agent_card`

`call_agent_with_payment`