The @getplexa/mcp server provides economic-safety tools for trading agents, enabling real-time trade price assessment and token risk evaluation on supported blockchains. Payments are handled automatically in USDC via x402 — no accounts, subscriptions, or API keys required, and your private key never leaves your machine.
Get Executable Swap Quotes (plexa_quote, $0.02/call):
Retrieve the real fill price for a swap of a specific size (not mid/spot price)
See price impact (in basis points), realizable depth, worst-case slippage, and confidence
View per-leg routing details (Uniswap v3, Aerodrome, Algebra, etc.)
Specify trade size by token amount (sizeIn) or USD notional (sizeUSD)
Supported chains: Base, Polygon, and Arbitrum
Run Pre-Trade Safety Checks (plexa_pretrade_check, $0.05/call):
Get a verdict of ok / caution / avoid with human-readable reasons and confidence
Screen tokens for rug pulls, honeypots, thin liquidity traps, fee-on-transfer fingerprints, holder concentration, and oracle/price sanity
Includes an executable quote bundled with the safety verdict
Currently Base-only
Automated x402 Payments: The server handles the full payment workflow by signing EIP-3009 USDC authorizations locally using your configured wallet — no manual steps needed.
Provides executable on-chain liquidity quotes on Polygon (along with Base and Arbitrum), returning real fill prices under a given size, price impact, route details, worst-case slippage, and confidence before trading.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@getplexa/mcp Check token 0xabc on Base for economic safety and quote $500"
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.
A Model Context Protocol server that gives any MCP client (Claude Desktop, Cursor, your own agent) two economic-safety tools from Plexa — the x402-native economic-safety layer for trading agents — paid per call in USDC, no accounts:
Tool | Wraps | Price | Returns |
|
| $0.02 | Executable fill price under size (not mid/spot), price impact (bps), realizable depth, per-leg route, worst-case slippage, confidence — from canonical on-chain quoters on Base, Polygon & Arbitrum. |
|
| $0.05 | Two levels. |
It is a thin client of the public API (https://api.getplexa.com) — it pays a 402 automatically,
signs the USDC authorization locally with your wallet, and never sees your key. The liquidity engine
stays behind the API.
A generic wallet guard answers "can I sign this transaction?". It can't answer the economic question an automated trader actually needs: what price will this swap really fill at under my size, and is this token a trap (rug / honeypot / thin liquidity)? Plexa answers both. This package puts those answers one tool-call away inside any MCP-speaking agent.
Related MCP server: mev-history-mcp
Nothing to install — point your MCP client at the package via npx. It is fetched and run on demand.
Add to claude_desktop_config.json (Settings → Developer → Edit Config):
{
"mcpServers": {
"plexa": {
"command": "npx",
"args": ["-y", "@getplexa/mcp"],
"env": {
"PLEXA_BASE_URL": "https://api.getplexa.com",
"AGENT_WALLET_KEY": "0x<your funded wallet private key>",
"CHAIN": "base"
}
}
}
}Add to ~/.cursor/mcp.json (or Settings → MCP → Add) — the same mcpServers block as above.
Restart the client. You should see the plexa_quote and plexa_pretrade_check tools available.
All configuration is via environment variables (set in the env block of your MCP config):
Variable | Default | Notes |
|
| The public API. The real URL — not a secret. |
| (none) | Required to pay. Funded wallet private key — pays per call and signs locally. Plexa never receives it. Without it, tools return a clear |
|
|
|
Funding. Use a dedicated, low-balance wallet with a little USDC on CHAIN to pay per call
(quotes $0.02, checks $0.05). The wallet signs an EIP-3009 USDC authorization per request; Plexa returns
the result only after the payment settles on-chain (settle-before-serve).
Your key is a secret. Prefer your MCP client's secret storage if it has one. Never commit it.
MCP has no native payment. This server acts as an x402 client: it wraps fetch, so when Plexa
replies 402 Payment Required it reads the payment requirements, signs a USDC authorization with your
wallet (locally), and retries. The signed authorization is the only thing that leaves your machine —
never the key. Payment is made on CHAIN, so you fund one wallet on one chain.
If no AGENT_WALLET_KEY is set, the tools return an honest 402 error explaining a funded wallet is
needed — they never fabricate a result.
Once configured, just ask your agent naturally — it will call the tools:
"Before I buy this token
0x…on Base, check it with Plexa and get me an executable quote for $500."
The agent calls plexa_pretrade_check (verdict + reasons) and plexa_quote (executable price under
$500), pays $0.05 + $0.02 in USDC automatically, and answers with real on-chain economics.
Beyond verdict / triggers / risk_profile / liquidityCoverage, every pre-trade
response carries six blocks of context. Live capture, WETH, 2026-08-20T14:46:29Z, Base block
50223921 — the note string each block carries is long and is cut here, nothing else is:
{
"identity": {
"name": "Wrapped Ether",
"symbol": "WETH",
"decimals": 18,
"totalSupplyRaw": "239296586519181917702210",
"totalSupply": 239296.58651918193
},
"valuation": {
"fdvExecutableUsd": 543916397.6557496,
"basis": "totalSupply(this chain) x executablePrice(at sizeUSD)"
},
"ownership": {
"ownerAddress": null,
"ownerRenounced": null,
"isMintable": false,
"creatorAddress": "0xe8a3ecea7d6a688ee903173024225357ddf29e93",
"creatorBalance": 0.000289172466091074,
"creatorSharePct": 1.208427041511075e-07
},
"dormancy": {
"topHolderIdleDays": null,
"lastTopHolderMoveBlock": null,
"headBlock": null
},
"market": {
"priceUsdSpot": 2277.76,
"volume24hUsd": 551324354.8699999,
"marketCapUsd": 542587444,
"holderCount": 5223863
},
"sources": {
"*": "measured",
"risk_profile.concentration": "unavailable:holder-axis-produced-nothing",
"flags.F_CONC": "unavailable:holder-axis-produced-nothing",
"valuation": "derived:identity.totalSupply*quote.executablePrice",
"dormancy": "unavailable:holder-axis-produced-no-block",
"ownership.creatorAddress": "derived:sender-of-first-transfer",
"ownership.isMintable": "derived:mint-selector-in-bytecode",
"market": "vendor:dexscreener+goplus",
"market.priceUsdSpot": "vendor:dexscreener",
"market.volume24hUsd": "vendor:dexscreener",
"market.marketCapUsd": "vendor:dexscreener",
"market.holderCount": "vendor:goplus"
}
}🔴 sources is the map of who said what. measured — ours, read off the chain on
this call. derived:<formula> — ours, computed from other fields of this same response.
vendor:<name> — somebody else's number, republished and signed as theirs.
unavailable:<reason> — no value, and the reason why. That last one is the point:
a missing number that names its own gap cannot be mistaken for a clean result.
Two numbers that look like duplicates and are not: valuation.fdvExecutableUsd is
THIS chain's supply at the price your size executes at; market.marketCapUsd is the
vendor's global figure. For a bridged token ours is legitimately smaller.
Client-only. Talks to the public Plexa API over HTTPS. No service internals ship in this package.
Honest failures. A non-2xx response or a network error becomes a loud tool error — never a clean-looking empty result. An agent can always tell a failure from a pass.
Built on the official @modelcontextprotocol/sdk +
x402.
MIT — see LICENSE.
Questions: support@getplexa.com · getplexa.com
Informational on-chain data and heuristic economic signals, not financial advice. Absence of flags is not a guarantee of safety. Verify independently before trading.
Economic-safety verdict for a token on Base before buying it: ok / caution / avoid with human-readable reasons and a confidence rating. Combines liquidity structure, holder concentration, token age, fee-on-transfer/honeypot fingerprints, and oracle/price sanity, plus an executable quote. Call this to screen a token for rug / honeypot / trap risk before an agent trades it. Base-only today (configure the server with CHAIN=base to use it). Cost: $0.05 USDC per call via x402 (paid automatically by the configured wallet). Heuristic economic signal, NOT financial advice; absence of flags is not a guarantee of safety.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Token to vet before buying. ERC-20 contract address (0x + 40 hex) on the chain this server is configured for. Not a symbol. | |
| sizeUSD | No | Optional USD notional for the executable-quote sub-result, e.g. "1000" (default 1000). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of behavioral disclosure. It details what factors are combined (liquidity structure, holder concentration, token age, fee-on-transfer/honeypot fingerprints, oracle/price sanity, executable quote), notes the cost ($0.05), warns it's heuristic not financial advice, and clarifies that absence of flags is not a guarantee. No contradictions.
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 well-structured: front-loaded with the core verdict and its components, followed by usage instruction, chain restriction, cost, and disclaimer. It is efficient but includes some extra details (cost, disclaimer) that, while useful, lengthen it slightly. Still concise for the amount of information conveyed.
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 (multiple checks, cost, output format, chain-specific) and the absence of an output schema, the description sufficiently explains the return value ('ok / caution / avoid with reasons and confidence rating' plus an executable quote). It also mentions the cost and chain requirement, making it complete for an agent to understand usage.
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 both parameters have descriptions in the input schema. The tool description does not add extra semantic details beyond the schema; it merely restates the purpose of each parameter. Per guidelines, baseline is 3 when schema coverage is high and the description does not enhance parameter understanding.
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 returns an economic-safety verdict ('ok / caution / avoid') with reasons and a confidence rating for a token on Base. It explicitly mentions the purpose is to screen for rug/honeypot/trap risk before trading, distinguishing it from the sibling tool 'plexa_quote' which likely provides trading quotes.
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 tells when to use this tool ('Call this to screen a token... before an agent trades it'), and provides chain-specific setup (Base-only, configure CHAIN=base). It does not explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get EXECUTABLE on-chain liquidity for a swap (Base / Polygon / Arbitrum) before trading: the real fill price under a given size (not the mid/spot quote), price impact in bps, realizable depth, the route (per-leg dex/pool/fee), worst-case slippage, and a confidence rating. Sources Uniswap v3 + Aerodrome/Algebra via canonical on-chain quoters. Call this when an agent needs to know what price a swap of a specific size will ACTUALLY execute at, especially for thin/long-tail tokens. Cost: $0.02 USDC per call via x402 (paid automatically by the configured wallet). Returns informational market data, NOT financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| tokenIn | Yes | Token being sold. ERC-20 contract address (0x + 40 hex) on the chain this server is configured for. Not a symbol. | |
| tokenOut | Yes | Token being bought. ERC-20 contract address (0x + 40 hex) on the chain this server is configured for. Not a symbol. | |
| sizeIn | No | Trade size as a human amount of tokenIn, e.g. "1.5" for 1.5 WETH. Provide EXACTLY ONE of sizeIn or sizeUSD. | |
| sizeUSD | No | Trade size as a USD notional, e.g. "5000". Provide EXACTLY ONE of sizeIn or sizeUSD. | |
| chain | No | Optional chain override for THIS quote: "base", "polygon", or "arbitrum" (or CAIP-2 "eip155:8453"/"eip155:137"/"eip155:42161"). Omit to use the server's configured chain (CHAIN env, default base). Payment is always made on the configured chain regardless of this override. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses cost ($0.02 per call via x402), states it returns informational data (implying no state modification), and notes the quote is executable but for pre-trade use. Lacks an explicit statement that it is read-only, but the context strongly implies it.
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 a single well-structured paragraph. It front-loads the core purpose, then lists outputs, data sources, usage advice, cost, and a disclaimer. Every sentence adds necessary information 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?
For a tool with 5 parameters and no output schema or annotations, the description covers purpose, outputs, usage, cost, data sources, and chain support. It lacks an explicit statement about read-only nature, but is otherwise comprehensive.
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 has 100% coverage with clear descriptions. The description adds value by explaining the purpose of parameters in context (e.g., 'under a given size') and provides additional detail on the 'chain' parameter about payment chain. This goes 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?
The description clearly states 'Get EXECUTABLE on-chain liquidity for a swap' and lists specific outputs (real fill price, price impact, etc.), distinguishing it from a mid/spot quote. It also mentions supported chains, making the purpose very 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?
Provides explicit guidance: 'Call this when an agent needs to know what price a swap of a specific size will ACTUALLY execute at, especially for thin/long-tail tokens.' It also notes the return is informational, not financial advice. However, it does not directly address when NOT to use it or how it differs from the sibling tool 'plexa_pretrade_check'.
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.
v0.1.2plexa_pretrade_checkplexa_quoteScored across 2 tools
The two tools have clearly distinct purposes: one performs a safety check on a token before buying, the other provides an executable swap quote. There is no overlap in functionality.
Both tools follow the 'plexa_' prefix and use descriptive snake_case names ('pretrade_check', 'quote'), forming a consistent and predictable naming pattern.
With only two tools, the server feels thin for a trading context. However, if the server's intended purpose is limited to pre-trade safety and pricing, the count is justifiable but borderline.
The server covers safety screening and quoting but is missing critical operations like executing a swap, managing approvals, or checking balances, leaving a significant gap in the trading workflow.
Pay-per-call DeFi and macro intel for AI agents. x402 USDC tools via streamable HTTP /api/mcp.
Metered MCP tools: free discovery over MCP; per-call execution settled in USDC via x402 v2.
Hosted MCP server for LLM cost estimation, model comparison, and budget-aware routing.
Pay-per-call MCP tools over x402 (USDC/Solana): LLM, utilities, x402 market and model prices.
