This MCP server lets you audit token risk/alpha and query Polymarket arbitrage data.
Run get_token_alpha for a token address to get real-time security checks (honeypot, sell taxes, balance modifications), volume momentum, and liquidity depth scoring.
Specify an optional network: Base (default), Solana, Ethereum, BSC, Arbitrum, or Polygon.
Use get_polymarket_alpha to retrieve top-volume Polymarket markets, outcome prices, and binary arbitrage spreads.
Provides the Bitcoin Lightning L402 payment backend (Alby Developer / LNbits) used to issue payment challenges and settle micro-payments required to unlock the on-chain alpha endpoints.
Supplies the free Base RPC endpoint used for x402 (USDC) micro-payment settlement on EVM chains.
Bitcoin Lightning is one of the two settlement rails: the API returns a 402 challenge with an L402 Lightning invoice and validates the payment preimage before returning token intelligence data.
Hosts and deploys the API/MCP server at the edge on Cloudflare's free tier, giving global low-latency access with 100,000 free requests per day via Wrangler deployments.
Integrates Coinbase AgentKit and Base CDP wallets to let autonomous agents pay x402 challenges in USDC and to list the endpoint as an AgentKit tool for Base/EVM trading agents.
Ethereum is one of the supported networks for the token alpha endpoint, returning liquidity, momentum, and security-audit data for ERC-20 tokens.
Polygon is one of the supported networks for the token alpha endpoint, returning liquidity, momentum, and security-audit data for tokens on the chain.
Solana is one of the supported networks; the token alpha endpoint accepts Solana token mint addresses and returns honeypot audits, momentum scores, and liquidity metrics.
Real-time DexScreener liquidity & momentum metrics, GoPlus fail-closed anti-honeypot smart contract security audits, newly active safe pool discovery (/v1/new-pairs + SSE stream), and Polymarket prediction market arbitrage opportunities for autonomous AI Agents across Base, Solana, Ethereum, BSC, Arbitrum, and Polygon.
🎁 Zero-Config Free Tier (3 Free Calls / Day): Start immediately in Claude Desktop, Cursor, Glama, or Smithery with no wallet setup required for your first 3 queries every day.
⚡ Instant Prepaid Base USDC Credits ($1.00 = 200 Security Audits / 50 Alpha Calls): Send $1.00 USDC once on Base to 0x8a8c238ed2b46908Ff6C6922a3870984f20f8913 and pass your transaction hash (0x...) for sub-20ms credit deduction and zero RPC wait time on subsequent calls.
🪙 Official Coinbase x402 Standard (x402Version: 1) & Lightning L402: Compatible out-of-the-box with x402-fetch, x402-axios, and Coinbase CDP AgentKit.
🌐 Live Production Gateway: https://alpha402.acter.workers.dev
📊 Live Funnel & Revenue Analytics: https://alpha402.acter.workers.dev/v1/analytics
Run immediately via npx (first 3 calls/day are 100% free; optionally add ALPHA402_TX_HASH for unlimited prepaid calls):
{
"mcpServers": {
"alpha402": {
"command": "npx",
"args": ["-y", "alpha402-mcp"],
"env": {
"ALPHA402_TX_HASH": "0x_OPTIONAL_PREPAID_BASE_USDC_TX_HASH"
}
}
}
}Tool / Endpoint | Free Tier | Unlimited Price | Description |
| 3 Free / Day | $0.005 USDC (5 sats) | Fast fail-closed GoPlus contract audit (honeypot, buy/sell tax, balance mod, freeze authority). |
| 3 Free / Day | $0.02 USDC (20 sats) | Full composite AlphaScore (Security 40% + Momentum 35% + Liquidity 25%) + wash-trading filter. |
| 3 Free / Day | $0.02 USDC (20 sats) | Scans newly active & boosted pools on Base/Solana/ETH/BSC/Arb/Polygon, filters out honeypots, and ranks safe pools by AlphaScore. |
| 3 Free / Day | $0.02 USDC (20 sats) | Real-time Server-Sent Events ( |
| 3 Free / Day | $0.01 USDC (10 sats) | Top volume prediction markets, outcome prices, and binary arbitrage spreads. |
| Always Free | $0.00 (Free) | Check remaining prepaid USDC credit balance for any |
Related MCP server: aegis-defi
Per-request on-chain transfers are too slow for sniper bots. Alpha402 solves this automatically:
Send any amount $\ge $0.005$ USDC on Base to 0x8a8c238ed2b46908Ff6C6922a3870984f20f8913 (e.g., $1.00 USDC = 1,000,000 units).
Pass paymentProof: "0x<your_tx_hash>" in any MCP tool call or Authorization: x402 0x<your_tx_hash> on REST requests.
Call #1 verifies the receipt on Base RPC and initializes your credit balance ($0.98 remaining = 49 more alpha calls or 196 security calls).
Subsequent Calls skip Base RPC completely and deduct credits in < 20ms, returning X-402-Credits-Remaining-USDC and X-402-Calls-Remaining headers on every response!
For pre-swap checks, failing open is a catastrophic bug. If the upstream security auditor (GoPlus) times out (4s timeout), errors, or cannot verify a contract:
auditStatus is set to UNAVAILABLE / TIMEOUT.
HTTP 503 Service Unavailable is returned and market data is withheld (data: null).
Atomic Credit Refund: The worker automatically refunds your exact call cost (reusableCredit: true, charged: false).
Performs a fast, fail-closed smart contract security and anti-honeypot audit via GoPlus on Base, Solana, Ethereum, BSC, Arbitrum, or Polygon. Detects honeypots, buy/sell taxes (in % and basis points), balance modification backdoors, mint authority, and blacklists. Includes 3 free calls/day; unlimited calls cost $0.005 USDC via Base prepaid session.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | The token smart contract address (0x... for EVM chains like Base/Ethereum, or Base58 mint address for Solana). Example Base BRETT address: "0x532f27101965dd16442e59d40670faf5ebb142e4". | |
| network | No | Target blockchain network to audit: "base", "solana", "ethereum", "bsc", "arbitrum", or "polygon". Defaults to "base". | base |
| paymentProof | No | Optional Base USDC transaction hash ("0x...") or HTTP 402 payment header for unlimited calls after your 3 free daily queries. Deposit $1.00 USDC once on Base to 0x8a8c238ed2b46908Ff6C6922a3870984f20f8913 for 200 instant security audits. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, but the description adds useful operational context: fail-closed auditing, the provider, detected risk categories, and the free-call/payment model. It could say more about rate limiting or error behavior, but the added cost and auth context is meaningful.
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 front-loaded with purpose and risk coverage, then follows with payment terms. It is appropriately sized, though the second sentence is somewhat dense and includes pricing detail that could be separated or trimmed.
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?
With no output schema, the description helpfully lists what the audit detects, giving the agent a sense of expected result categories. It does not describe the exact response shape, but it provides enough context to call the tool correctly for a read-only audit.
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 address, network enum, and paymentProof are already well documented in the schema. The description reinforces supported chains and payment mechanics but does not add syntax or semantics beyond the structured fields.
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 states a specific verb and resource: a smart contract security and anti-honeypot audit via GoPlus across six named chains. It clearly distinguishes this from sibling alpha/payment tools by focusing on honeypot detection, taxes, mint authority, blacklists, and backdoors.
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 context for use is clear: an agent should call this when it needs token contract security due diligence, especially honeypot or tax risk. However, it does not explicitly compare against alternatives such as get_token_alpha or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
100% free utility tool with zero cost. Checks the remaining prepaid USDC credit balance and remaining call count for any Base USDC transaction hash (0x...), or returns the Base USDC deposit address and pricing tiers for upgrading from the 3 free daily calls.
| Name | Required | Description | Default |
|---|---|---|---|
| txHash | No | Optional 66-character Base USDC transaction hash ("0x...") to verify on-chain and check remaining prepaid credit balance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuinely new context: the tool is free to call, it reads on-chain Base USDC data, and it serves two distinct modes depending on input. It stops short of describing response shape or latency, but that is a minor gap given the annotation coverage.
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?
A single front-loaded sentence that leads with the free/no-cost property and then explains both modes. Slightly redundant phrasing ("100% free utility tool with zero cost" says the same thing twice) keeps it from a perfect score.
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?
With no output schema and one optional parameter, the description covers what an agent needs: cost, both return modes, and the input trigger for each. Pricing tier detail and response formatting are left unspecified but not essential for correct invocation.
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 already documents the optional txHash as a 66-char 0x string. The description adds the key semantics the schema omits: omitting txHash switches the tool to deposit-address/pricing mode, which is essential branching behavior not expressed in the 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?
States a specific verb and resource — checking remaining prepaid USDC credit balance and call count — and additionally names the alternate behavior (returning a deposit address and pricing tiers). The domain is clearly distinct from the sibling tools, which are token/alpha/security lookups, so an agent can route without ambiguity.
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?
Gives clear context for when to call it: verifying a Base USDC tx hash for credit balance, or fetching deposit/pricing info to upgrade beyond the 3 free daily calls. It does not explicitly state when NOT to use it or name an alternative tool, but the conditional (with vs. without txHash) functions as practical usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scans newly active and boosted liquidity pools on Base, Solana, Ethereum, BSC, Arbitrum, or Polygon via DexScreener, automatically filters out honeypots and high-tax scams via GoPlus security audits, and returns the top verified safe pairs ranked by AlphaScore. Includes 3 free calls/day; unlimited calls cost $0.02 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of verified safe token pairs to return (between 1 and 10, defaults to 5). | |
| network | No | Blockchain network to scan for safe new token pools ("base", "solana", "ethereum", "bsc", "arbitrum", or "polygon"). Defaults to "base". | base |
| paymentProof | No | Optional Base USDC transaction hash ("0x...") or HTTP 402 payment proof for unlimited calls after your 3 free daily queries. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds substantive behavior: GoPlus honeypot and high-tax filtering, AlphaScore ranking, the six-chain scope, and a concrete rate-limit/paid-tier model. It does not describe result shape beyond 'top pairs', but the additive context is strong.
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?
One front-loaded sentence covering scope, filtering, ranking, and pricing, with no filler. It runs slightly long as a single clause-chained sentence, but every clause carries information an agent needs.
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?
With no output schema, the description takes on the burden of describing returns and does so at a summary level ('top verified safe pairs ranked by AlphaScore'). Combined with explicit filtering provenance and the payment gate, the picture is nearly complete; only pagination/empty-result behavior is unstated.
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 limit, network, and paymentProof are fully documented in the schema and the 3-baseline applies. The description enumerates the chains (already in the enum) and hints at the free-call gating behind paymentProof, but adds no format or validation detail beyond the 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?
States a specific verb and resource: scans newly active/boosted liquidity pools across six named chains, filters scams, and returns AlphaScore-ranked safe pairs. It is clearly a discovery tool, distinguishable in practice from check_token_security and get_token_alpha, though it never names those siblings to make the separation explicit.
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 payment model (3 free calls/day, $0.02 USDC thereafter) effectively signals when paymentProof is needed, which is real usage context. However, there is no explicit guidance on when to choose this tool over check_token_security or get_token_alpha, so the agent must infer the routing itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves the highest-volume active prediction markets on Polymarket along with outcome probabilities, liquidity depth in USD, and binary arbitrage spreads. Includes 3 free calls/day; unlimited calls cost $0.01 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| paymentProof | No | Optional Base USDC transaction hash ("0x...") or HTTP 402 payment proof for unlimited calls after your 3 free daily queries. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world, non-destructive behavior. The description adds important operational context beyond annotations: the free-call allowance and the paid USDC requirement for unlimited calls.
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?
Two sentences with no wasted wording. The core data-retrieval purpose is front-loaded, followed by the payment constraint.
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?
For a simple read-only retrieval tool with one optional parameter and no output schema, the description provides enough context: it explains what data is returned and the payment/free-tier model.
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%, and the sole optional paymentProof parameter is fully documented in the schema. The description reinforces the payment concept but does not add parameter-level meaning beyond what the schema already provides, matching the baseline for high coverage.
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 states a specific verb and resource: retrieving highest-volume active prediction markets on Polymarket. It also names the returned content, distinguishing it clearly from sibling tools focused on token security, credits, new pairs, or token alpha.
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 tool's domain is clear from the description, so usage is strongly implied for Polymarket prediction-market data. However, it does not explicitly state when to use this versus sibling tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Computes a fail-closed composite AlphaScore (0-100) combining GoPlus smart contract security (40% weight), DexScreener 5m/1h volume momentum & buy-pressure ratio (35% weight), and USD liquidity depth (25% weight) with automatic wash-trading detection. Includes 3 free calls/day; unlimited calls cost $0.02 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | The token smart contract address (0x... for EVM chains or Base58 mint address for Solana). Example Base token: "0x532f27101965dd16442e59d40670faf5ebb142e4". | |
| network | No | Target blockchain network: "base", "solana", "ethereum", "bsc", "arbitrum", or "polygon". Defaults to "base". | base |
| paymentProof | No | Optional Base USDC transaction hash ("0x...") or HTTP 402 payment proof for unlimited calls after your 3 free daily queries. Deposit $1.00 USDC once on Base to 0x8a8c238ed2b46908Ff6C6922a3870984f20f8913 for 50 instant alpha calls. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a safe, idempotent read operation, and the description adds substantial behavioral context beyond that: fail-closed scoring, component weights, wash-trading detection, free daily quota, and paid unlimited-call mechanics. The main residual gap is that "fail-closed" is not further explained, and the exact result format is not described.
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 two sentences and front-loads the core capability before pricing details. The first sentence is dense with component weights, but those details are relevant to understanding the score, and there is little wasted text.
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?
This is a high-complexity scoring and payment tool, and while the description covers the score composition and payment model, it does not explain the return structure or how fail-closed behavior manifests in results. With no output schema, the description should carry more of the return-value burden than it does.
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%, and all three parameters are already documented in the schema, including the address formats, network enum, and paymentProof purpose. The description adds general pricing and payment context but no meaningful parameter-level detail beyond what the schema provides, so the baseline 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 states a specific verb and resource: it computes a composite AlphaScore for a token, with named components (GoPlus security, DexScreener momentum, liquidity depth) and a 0-100 scale. It is clearly about a composite scoring tool, but it does not explicitly distinguish this from sibling tools such as check_token_security or get_new_pairs_alpha.
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 explains what the score contains and the pricing model, but gives no explicit guidance on when to use this tool versus check_token_security or get_new_pairs_alpha. There are no exclusions or conditions that would route an agent between the 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.
v1.6.0check_token_securityget_credits_and_payment_infoget_new_pairs_alphaget_polymarket_alpha2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / paymentProofAdded value: +{
+ "description": "Optional Base USDC transaction hash (\"0x...\") or HTTP 402 payment proof for unlimited calls after your 3 free daily queries.",
+ "type": "string"
+}get_token_alpha6 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / address / descriptionPrevious value: -"The smart contract address or token mint address"New value: +"The token smart contract address (0x... for EVM chains or Base58 mint address for Solana). Example Base token: \"0x532f27101965dd16442e59d40670faf5ebb142e4\"."Input schema / properties / network / defaultAdded value: +"base"Input schema / properties / network / descriptionPrevious value: -"Blockchain network (default is base)"New value: +"Target blockchain network: \"base\", \"solana\", \"ethereum\", \"bsc\", \"arbitrum\", or \"polygon\". Defaults to \"base\"."Input schema / properties / network / enumPrevious value: -[
- "base",
- "solana",
- "ethereum",
- "bsc",
- "arbitrum",
- "polygon"
-]New value: +[
+ "base",
+ "ethereum",
+ "solana",
+ "bsc",
+ "arbitrum",
+ "polygon"
+]Input schema / properties / paymentProofAdded value: +{
+ "description": "Optional Base USDC transaction hash (\"0x...\") or HTTP 402 payment proof for unlimited calls after your 3 free daily queries. Deposit $1.00 USDC once on Base to 0x8a8c238ed2b46908Ff6C6922a3870984f20f8913 for 50 instant alpha calls.",
+ "type": "string"
+}v0.1.0get_polymarket_alphaget_token_alphaScored across 5 tools
The tools mostly target distinct tasks: raw security auditing, composite alpha scoring, new-pair discovery, Polymarket data, and credits/payment info. However, check_token_security and get_token_alpha overlap around GoPlus security checks, and get_new_pairs_alpha also applies honeypot filtering, so an agent may need to read descriptions carefully to choose correctly.
All tool names use consistent snake_case and a predictable verb_noun structure. Four tools use get_* and one uses check_* for a security-audit action, which is semantically appropriate rather than inconsistent.
Five tools is a well-scoped set for a crypto alpha, security, and payment utility server. Each tool has a clear role, and there is no obvious filler or bloat.
The surface covers the core workflows: security checks, composite scoring, new-pair discovery, Polymarket alpha, and credit/payment management. Minor gaps exist, such as no dedicated historical market data or bulk token lookup, but these are not severe for the apparent purpose.
On-chain security and market intelligence for trading agents on Base.
Rug-check & launch radar for trading agents: composite honeypot score, EVM+Solana, keyless x402.
Token rug-risk scans, Know Your Agent wallet checks and deployer reputation for AI agents.
Crypto security, honeypot detection, wallet analysis, and token risk scoring across 31 blockchains.
