MCP Server for AI agents to discover and call pay-per-request APIs via EntRoute.
Give Claude, Cursor, Windsurf, or any MCP-compatible agent access to 350+ verified x402 API endpoints across 110+ capabilities -- DeFi prices, web search, prediction markets, news, and more.
claude mcp add entroute -- npx @entroute/mcp-serverAdd to your claude_desktop_config.json:
{
"mcpServers": {
"entroute": {
"command": "npx",
"args": ["@entroute/mcp-server"]
}
}
}Add to your MCP settings with command npx @entroute/mcp-server.
Related MCP server: x402-mcp
discover_paid_apiFind ranked, verified API endpoints for any capability. Supports natural language intent or explicit capability IDs.
"Find me an API to get the current price of ETH"
-> Returns ranked endpoints with pricing, success rates, and latency metricslist_capabilitiesBrowse all available capability types. Filter by tag or search by keyword.
call_paid_apiExecute a discovered endpoint. Optionally handles x402 payments automatically when a wallet is configured.
To enable automatic x402 payments, set these environment variables:
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)Without a wallet, the server still discovers endpoints -- you just can't auto-pay for 402-protected ones.
Variable | Default | Description |
| -- | Hex private key for x402 payments |
|
| Spending cap per request in USD |
Once installed, ask your agent:
"What APIs are available for DeFi?"
"Find me a web search API"
"Get the current price of ETH using a paid API"
"Search the news for AI agent developments"
The agent will use discover_paid_api to find endpoints, show you the options with pricing, and call the best one.
EntRoute indexes 110+ capabilities across categories including:
Finance/DeFi -- token prices, swap quotes, portfolio tracking, yield data
Web -- search, scraping, URL shortening
Identity -- wallet profiles, ENS resolution
AI -- text generation, image generation
News -- search, trending topics
Security -- contract audits, threat intelligence
Prediction -- market data, odds
Browse all capabilities at 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
