AI 에이전트가 EntRoute를 통해 요청당 결제(pay-per-request) API를 검색하고 호출할 수 있도록 하는 MCP 서버입니다.
Claude, Cursor, Windsurf 또는 모든 MCP 호환 에이전트에게 DeFi 가격, 웹 검색, 예측 시장, 뉴스 등 110개 이상의 기능에 걸쳐 350개 이상의 검증된 x402 API 엔드포인트에 대한 액세스 권한을 부여하세요.
claude mcp add entroute -- npx @entroute/mcp-serverclaude_desktop_config.json에 추가하세요:
{
"mcpServers": {
"entroute": {
"command": "npx",
"args": ["@entroute/mcp-server"]
}
}
}npx @entroute/mcp-server 명령어를 사용하여 MCP 설정에 추가하세요.
Related MCP server: x402-mcp
discover_paid_api모든 기능에 대해 순위가 매겨지고 검증된 API 엔드포인트를 찾습니다. 자연어 의도 또는 명시적 기능 ID를 지원합니다.
"Find me an API to get the current price of ETH"
-> Returns ranked endpoints with pricing, success rates, and latency metricslist_capabilities사용 가능한 모든 기능 유형을 탐색합니다. 태그별로 필터링하거나 키워드로 검색하세요.
call_paid_api검색된 엔드포인트를 실행합니다. 지갑이 구성된 경우 선택적으로 x402 결제를 자동으로 처리합니다.
자동 x402 결제를 활성화하려면 다음 환경 변수를 설정하세요:
EVM_PRIVATE_KEY=0x... # Wallet private key for USDC payments on Base
MAX_PAYMENT_PER_REQUEST=0.05 # Max USD per request (default: $0.05)지갑이 없어도 서버는 엔드포인트를 검색할 수 있지만, 402로 보호된 엔드포인트에 대해 자동 결제를 수행할 수는 없습니다.
변수 | 기본값 | 설명 |
| -- | x402 결제를 위한 16진수 개인 키 |
|
| 요청당 지출 한도 (USD) |
설치가 완료되면 에이전트에게 다음과 같이 요청하세요:
"DeFi에 사용할 수 있는 API는 무엇인가요?"
"웹 검색 API를 찾아줘"
"유료 API를 사용하여 현재 ETH 가격을 가져와줘"
"AI 에이전트 개발에 관한 뉴스를 검색해줘"
에이전트는 discover_paid_api를 사용하여 엔드포인트를 찾고, 가격 정보와 함께 옵션을 보여준 뒤 가장 적합한 엔드포인트를 호출합니다.
EntRoute는 다음을 포함한 여러 카테고리에 걸쳐 110개 이상의 기능을 인덱싱합니다:
금융/DeFi -- 토큰 가격, 스왑 견적, 포트폴리오 추적, 수익률 데이터
웹 -- 검색, 스크래핑, URL 단축
신원 -- 지갑 프로필, ENS 확인
AI -- 텍스트 생성, 이미지 생성
뉴스 -- 검색, 트렌드 토픽
보안 -- 컨트랙트 감사, 위협 인텔리전스
예측 -- 시장 데이터, 배당률
entroute.com/capabilities에서 모든 기능을 탐색하세요.
MIT
Call a previously discovered API endpoint.
Use this after discover_paid_api to execute the request. Payment-required endpoints (402) will return an error with payment details since no wallet is configured.
IMPORTANT: You must first use discover_paid_api to find an endpoint. Then use the endpoint_id from the discovery result.
Trust & safety:
No wallet is configured, so paid endpoints will return payment details without executing.
EntRoute verifies that endpoints return valid 402 responses every 10 minutes, but does not guarantee response quality or accuracy.
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint_id | Yes | The endpoint_id from a previous discover_paid_api result | |
| method | No | HTTP method (defaults to endpoint method) | |
| headers | No | Additional headers to include in the request | |
| body | No | Request body (for POST/PUT/PATCH) | |
| query_params | No | Query parameters to append to URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses that payment-required endpoints will error with payment details, that no wallet is configured, and that EntRoute verifies endpoints for valid 402 responses but does not guarantee quality. This provides good transparency beyond the basic function call.
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?
Description is well-structured with clear sections. It is concise with only necessary information. However, it could be slightly shorter by removing redundant phrasing like 'No wallet is configured' appearing twice.
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 tool's complexity (5 parameters, nested objects) and no output schema, the description provides sufficient context for basic use. It covers the discovery prerequisite and payment behavior. However, it does not explain what happens on successful calls (e.g., response structure) or error handling for non-402 errors.
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 description coverage is 100%, so the schema already defines parameters. The description does not add additional meaning beyond what the schema provides. It repeats the need for endpoint_id but does not explain formats or constraints like the method enum's relationship to the endpoint's supported methods.
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 calls a previously discovered API endpoint, specifying its purpose and distinguishing it from the sibling tool discover_paid_api, which is used for discovery. The verb 'call' and resource 'API endpoint' are specific.
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?
Explicitly tells the agent to use this after discover_paid_api and to use the endpoint_id from discovery. It also explains that paid endpoints will return payment details without executing. However, it does not provide explicit guidance on when not to use it or alternatives beyond the sequential relationship.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover pay-per-request API endpoints for a given capability.
Returns ranked, verified endpoints with pricing and reliability metrics. Use this to find APIs before calling them. The results include:
Endpoint URL and method
Price per call and payment network
Success rate and latency metrics
Provider information
After discovering, you can use call_paid_api to execute the endpoint.
Trust & safety:
"Verified" means the endpoint returns a valid x402 402 response -- it does not guarantee the quality or accuracy of the data returned after payment.
Endpoints are probed every 10 minutes. Check last_verified and success_rate to gauge reliability.
Fallback endpoints (unverified) have failed recent verification checks -- use with caution.
Prefer endpoints with success_rate >95% and verification within the last 24 hours.
| Name | Required | Description | Default |
|---|---|---|---|
| intent | Yes | Natural language description of what you want to do (e.g., "get current weather for London", "translate text to Spanish"). Provide this or capability_id. | |
| capability_id | No | Explicit capability ID if known (e.g., "weather.current", "translate.text"). Alternative to intent for precise matching. | |
| max_price | No | Maximum price per request in USD (e.g., 0.01 for 1 cent) | |
| network | No | Required blockchain network for payment | |
| ranking_preset | No | Ranking preference preset | |
| limit | No | Maximum number of endpoints to return (default: 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses behavioral traits: verification meaning ('x402 402 response', not data accuracy), probing frequency (10 minutes), reliability guidance (prefer >95%, <24h), and fallback endpoint caution. Exceeds expectations for 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?
Concise and well-structured: brief summary, bulleted results list, clear trust & safety section. Every sentence adds value without 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?
Given 6 parameters with 100% schema coverage and no output schema, the description is complete: explains purpose, usage, safety, and ranking guidance. No gaps for an agent to execute correctly.
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% and descriptions are clear, but the description adds context: 'natural language description' for intent, 'precise matching' for capability_id, and explicit pricing and ranking defaults. The description adds moderate value beyond schema.
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 discovers pay-per-request API endpoints for a given capability, with specific verb ('discover') and resource ('paid API endpoints'). It distinguishes itself from sibling tools like 'call_paid_api' (which executes) and 'list_capabilities' (which lists capabilities).
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?
Explicitly says 'Use this to find APIs before calling them' and directs to 'call_paid_api' for execution. Provides when-to-use context and alternative/next step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available API capability types.
Use this to explore what kinds of APIs are available in the registry. You can filter by tag (e.g., "weather", "translation") or search by keyword.
Note: A capability existing does not mean verified endpoints are available for it. Use discover_paid_api to check for live endpoints.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Filter by tag (e.g., "weather", "translation", "finance") | |
| search | No | Search capabilities by keyword |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: 'A capability existing does not mean verified endpoints are available for it.' It does not list other traits like rate limits or pagination, but the scope is appropriately limited for a listing tool.
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 three sentences, all essential. The first sentence states the purpose, the second gives usage context, and the third adds a critical caveat. No wasted 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 the tool's low complexity (no required parameters, no output schema, no nested objects), the description covers the main points: purpose, filtering, and the important caveat about live endpoints. It's complete enough for an agent to use correctly.
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 description doesn't need to re-document parameters. It provides context about how to use the parameters ('filter by tag' and 'search by keyword'), which adds some value beyond the schema's descriptions. The 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?
The description clearly states the tool's purpose: 'List available API capability types.' It names the resource ('capability types') and the action ('list'). The context about filtering and searching further clarifies its function, and the note distinguishes it from sibling tools like discover_paid_api.
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 when to use this tool ('explore what kinds of APIs are available in the registry') and how to filter. It also provides clear guidance on when NOT to rely solely on this tool, directing users to 'discover_paid_api to check for live endpoints.' This helps the agent choose between siblings.
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. Dates show when Glama detected each change.
v0.1.6call_paid_apidiscover_paid_apilist_capabilitiesEach tool has a clear and distinct purpose: list_capabilities for discovery, discover_paid_api for endpoint search, and call_paid_api for execution. No overlap exists.
Naming follows a consistent verb_noun pattern (list_capabilities, discover_paid_api, call_paid_api). Slight inconsistency: 'discover' and 'list' are different verbs but both are clear.
Three tools cover the entire workflow of discovering and calling paid APIs without unnecessary additions. The count is well-scoped for the domain.
Covers the full lifecycle: list capabilities, discover endpoints, and call them. Minor gap: no tool for viewing payment history or managing wallets, but that may be out of scope.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
x402 MCP for agents: crypto prices, funding, DeFi yields, Polymarket, Base RPC + MCP security.
Pay-per-call DeFi and macro intel for AI agents. x402 USDC tools via streamable HTTP /api/mcp.
Monetize any MCP server: x402 paywall, pay-per-call billing in USDC on Base, agent marketplace.
15 paid AI agent primitives via x402 (USDC on Base). Pay-per-call MCP server.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/entroute/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
