CyberWareX MCP Servers
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AWA_TIMEOUT | No | Timeout for the web-access server. | |
| DSO_TIMEOUT | No | Timeout for the defi-oracle server. | |
| AWA_BASE_URL | No | Base URL override for the web-access server. | |
| DSO_BASE_URL | No | Base URL override for the defi-oracle server. | |
| AWA_X_PAYMENT | No | Pre-signed payment header for the web-access server. | |
| CHAIN_TIMEOUT | No | Timeout for the chain-data server. | |
| DSO_X_PAYMENT | No | Pre-signed payment header for the defi-oracle server. | |
| VOICE_TIMEOUT | No | Timeout for the voice-stt server. | |
| CHAIN_BASE_URL | No | Base URL override for the chain-data server. | |
| VOICE_BASE_URL | No | Base URL override for the voice-stt server. | |
| CHAIN_X_PAYMENT | No | Pre-signed payment header for the chain-data server. | |
| VOICE_X_PAYMENT | No | Pre-signed payment header for the voice-stt server. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| token_safetyA | Decide whether an ERC-20 token is safe to trade before committing funds. Runs a live buy-then-sell simulation (Aerodrome and Uniswap V3) plus contract-power and ownership analysis and a GoPlus and honeypot.is cross-check, then returns a single verdict. Use it when an agent is about to swap into, approve, or accept a token it has not vetted. Returns JSON with: grade (A to F), risk_score (0-100), is_honeypot (boolean), tradeable (boolean), and a flags array where each flag carries on-chain evidence. Read-only: no wallet, key, or signature needed; a cold simulation can take a few seconds. Paid per call in USDC on Base via x402. |
| honeypot_checkA | Answer one focused question: can this token actually be sold after it is bought? Executes a real buy-then-sell round trip as a simulated transaction on Base or BSC. Use it when you only need the honeypot yes-or-no, not the full safety report. Returns JSON with: is_honeypot (boolean), buy_success (boolean), sell_success (boolean), and round_trip_loss_percent (the tax or slippage lost across the round trip). Read-only: no wallet needed. Paid per call in USDC on Base via x402. |
| contract_riskA | Inspect what the team behind a token contract is able to do to holders, without running a trade simulation. Reports verified-source status, whether the contract is an upgradeable proxy and who its admin is, whether ownership is renounced, and which dangerous powers exist (mint, pause, blacklist, and mutable fees). Use it when you want the governance and rug-vector picture rather than the tradeability verdict. Returns JSON with each power as a boolean plus the resolved owner and admin addresses. Read-only. Paid per call in USDC on Base via x402. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
token_safety is the full-report umbrella and naturally overlaps with both honeypot_check and contract_risk, but the focused tools have clearly distinct single-purpose roles: sellability only vs. contract governance only. Descriptions make the separation actionable, though an agent might overuse token_safety when a lighter check would suffice.
All three tool names use lowercase snake_case and follow a consistent target_aspect pattern: token_safety, honeypot_check, contract_risk. There is no mixed casing or style drift, and each name clearly reflects its focused purpose.
Three tools is a well-scoped size for a token-security domain: one comprehensive vetting tool plus two dedicated focused checks. Each tool earns its place and there is no bloat or trivial filler.
The surface covers the core token-vetting workflow: full tradeability verdict, isolated honeypot detection, and contract-power/ownership risk. Minor gaps exist such as explicit liquidity-lock or approval-specific checks, but they are largely covered indirectly through the GoPlus and contract analysis layers.