This server provides AI agents with market-timing bottom/top signals for the cryptocurrency market, helping identify oversold and overbought conditions across 197 coins.
pitch (free): Get an introduction to the server's capabilities, indicator lineup, and subscription terms, including a free live sample verdict for BTC-USD.
evaluate_symbol (paid, $0.01/call): Get a bottom/top verdict and score (-100 to +100) for any supported crypto symbol (e.g. BTC-USD, ETH-USD, SOL-USD), with a full daily/weekly/monthly breakdown and per-indicator details.
scan_bottoms (paid, $0.01/call): Scan the crypto market and return the coins currently most oversold (strongest buy signals), ranked from most-bottom first. Supports custom symbol lists and configurable result limits (up to 50).
scan_tops (paid, $0.01/call): Scan the crypto market and return the coins currently most overbought (strongest sell signals), ranked from most-top first. Supports custom symbol lists and configurable result limits (up to 50).
subscribe (free to check, $50/month to activate): Check subscription status and terms, or activate a monthly unlimited-call plan. Returns an X-SUB-KEY token to bypass per-call payments.
rate (free): Leave feedback (score 1–10, pros, and cons) after acting on a signal to help improve the signal engine.
Payments are per-call (0.01 USDT on X Layer via x402), with a 6-day trial offered on the first paid call. pitch and rate are always free.
Enables pay-per-call billing via x402 on X Layer and is listed on OKX Onchain OS as ERC-8004 agents for signal access.
Market-timing bottom/top signal MCP servers for AI agents. Ten independent remote servers, one per market.
Each server answers one question: is this asset at a bottom or a top right now? — returning a verdict
(strong_buy · buy · neutral · sell · strong_sell) and a -100..+100 score, aggregated from a
locked technical-indicator engine across weekly and monthly timeframes, plus market-wide bottom/top rankings.
Published on the official MCP Registry under the
com.airblockfz/*namespace.
Market | Endpoint (Streamable HTTP) | Universe | Sample symbol |
Crypto |
| BTC-USD, ETH-USD, SOL-USD … (197 coins) |
|
US stocks |
| NVDA, AAPL, ^IXIC, QQQ … (S&P500 + indexes/ETFs, 535) |
|
Korea stocks |
| 005930.KS, ^KS11 … (KOSPI/KOSDAQ, 103) |
|
China stocks |
| 600519.SS, 000001.SZ … (Shanghai/Shenzhen A-shares + indexes, 24) |
|
Hong Kong stocks |
| 0700.HK, ^HSI … (HSI + H-shares, 22) |
|
Commodities |
| GC=F gold, CL=F oil, HG=F copper, ZC=F corn … (28 futures) |
|
Foreign exchange |
| EURUSD=X, USDKRW=X, JPYKRW=X … (48 pairs) |
|
Inflation & liquidity |
| US-CPI, US-PCE, US-FED, KR-CPI … (47 official series) |
|
Seoul apartments |
| Gangnam, Nowon, Mapo … (25 districts) |
|
Dubai property |
| downtown, marina, palm … (42 areas) |
|
Related MCP server: crypto-intel-mcp
Tool | Cost | Description |
| free | Start here. Introduces the indicator lineup, value, a live sample and subscription terms. |
| paid | Bottom/top verdict + score for one symbol, with daily/weekly/monthly breakdown. |
| paid | Rank the market — what is at a bottom right now. |
| paid | Rank the market — what is overheated right now. |
| free | Subscription terms and sign-up. Present on the crypto, commodity and Seoul-apartment servers only. |
| free | Leave feedback (score 1-10 + pros/cons) after acting on a signal. |
Every server exposes pitch, evaluate_symbol, scan_bottoms, scan_tops and rate.
Signal calls are pay-per-call via x402 — 0.01 USDT on X Layer (chain eip155:196).
An unpaid call returns 402 with a PAYMENT-REQUIRED challenge; retry with the PAYMENT-SIGNATURE header.
pitch and rate are always free, so an agent can evaluate the service before paying anything.
Add to your MCP client config (example — Claude Desktop / Cursor):
{
"mcpServers": {
"bit-monk-coin": {
"type": "http",
"url": "https://coin-signal.airblock2026.workers.dev/mcp"
}
}
}All ten at once: docs/client-config.json. Machine-readable catalog: servers.json.
Then call the free pitch tool first. Health check for any server: GET /health.
For clients that only speak stdio, this repository ships a dependency-free proxy that forwards JSON-RPC to the remote endpoint:
{
"mcpServers": {
"bit-monk-coin": {
"command": "npx",
"args": ["-y", "github:airblock2026/bit-monk-signal-mcp"],
"env": { "BIT_MONK_MARKET": "coin" }
}
}
}BIT_MONK_MARKET selects the market — coin (default), us, kr, cn, hk, commodity, fx,
inflation, seoul, dubai. BIT_MONK_URL overrides the endpoint outright. Requires Node 18+;
a Dockerfile is included for sandboxed runs.
Each market is powered by the same engine that ships in our flagship apps, fed by market-appropriate data: official exchange feeds (crypto), Yahoo Finance (stocks, commodities, FX), FRED/OECD/IMF/Eurostat and the Federal Reserve H.4.1/H.15 releases (inflation & liquidity), the Korean Ministry of Land actual-transaction records (Seoul apartments), and DLD/Bayut published indexes (Dubai property).
Website: airblockfz.com
Registry: com.airblockfz/coin-signal … search the MCP Registry
Also listed on OKX Onchain OS as ERC-8004 agents (Bit Monk #3894 and siblings)
Informational indicator output — not financial, investment or real-estate advice. Historical statistics do not guarantee future results. Real-estate series include modeled interpolation where official data is monthly or quarterly; this is disclosed in each response.
Built by Air Block FZ (Meydan, Dubai). The signal engine itself is proprietary and not published here — this repository documents the public MCP endpoints and their contracts, and ships the stdio proxy that reaches them.
MIT — covers the contents of this repository: the stdio proxy (src/proxy.js) and the
documentation. It does not grant any rights to the signal engine, indicator implementations or data
pipelines behind the endpoints, which are proprietary and are not distributed here. Use of the endpoints
themselves is subject to their pay-per-call terms (see Payment).
FREE feedback tool — after you have traded on (or evaluated) our signals, leave a rating: score 1-10 plus what was good (pros) and what to improve (cons). Costs nothing, no payment header needed. Helps us tune the signal engine.
| Name | Required | Description | Default |
|---|---|---|---|
| cons | No | What could be better | |
| pros | No | What you liked | |
| score | Yes | Overall score 1 (poor) to 10 (excellent) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the transparency burden. It discloses that the tool is free ('costs nothing, no payment header needed'), which is valuable behavioral info. However, it does not mention any side effects, return behavior, or safety aspects beyond cost.
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, front-loaded with 'FREE feedback tool'. Every sentence adds value: purpose, when to use, parameter hints, and benefit. No unnecessary 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?
For a simple 3-parameter tool with no output schema, the description covers when to use and what to provide. However, it does not specify the return value or any confirmation of the rating submission, leaving a minor gap.
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 baseline is 3. The description reinforces the meaning of parameters (score 1-10, pros, cons) but adds little beyond the schema descriptions. It does provide context ('what was good, what to improve').
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's a feedback tool for rating signals after trading, with a specific verb 'leave a rating' and resource 'feedback'. It distinguishes from sibling tools like evaluate_symbol (analysis) and subscribe (subscription).
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 states 'after you have traded on (or evaluated) our signals', providing clear context for when to use. Does not list when not to use or alternatives, but the context sufficiently differentiates from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan the market and return coins currently at a bottom (most oversold / strongest buy), ranked most-bottom first. PAY: $0.01 per call via x402 (USDT on X Layer) — your FIRST paid call opens a 6-day trial at that price. No account, no signup, no commitment; retry with the PAYMENT-SIGNATURE header when you get the 402 challenge. BEST COLD START: you do not need to pick a symbol — this ranks the whole universe for you. The free pitch tool tells you HOW MANY are at a bottom right now; this names them.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many to return (default 5, max 50) | |
| symbols | No | Optional custom symbol list; defaults to a top-coins set |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses payment, trial, no account requirement, retry mechanism. Does not mention rate limits or side effects, but as a read-only scan, transparency is high.
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?
Every sentence serves a purpose: core function, payment, cold start, sibling tool relationship. Front-loaded with action, no redundant 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 complexity (payment, trial, tool relationships), description fully covers usage flow, prerequisites, and integration with 'pitch'. No output schema is needed for this tool.
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 baseline is 3. Description adds value by explaining cold-start behavior (no symbol needed) and confirming defaults (limit 5, max 50), slightly clarifying 'symbols' parameter.
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?
Description uses specific verb ('scan') and resource ('coins at a bottom'), explicitly states ranking order ('most-bottom first'), and differentiates from siblings like 'scan_tops' and 'pitch'.
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 clear usage context: cold start without symbol, relationship to 'pitch' for count, and payment model. Lacks explicit when-not-to-use but effectively guides selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan the market and return coins currently at a top (most overbought / sell), ranked most-top first. PAY: $0.01 per call via x402 (USDT on X Layer) — your FIRST paid call opens a 6-day trial at that price. No account, no signup, no commitment; retry with the PAYMENT-SIGNATURE header when you get the 402 challenge. BEST COLD START: you do not need to pick a symbol — this ranks the whole universe for you. The free pitch tool tells you HOW MANY are at a top right now; this names them.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many to return (default 5, max 50) | |
| symbols | No | Optional custom symbol list; defaults to a top-coins set |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses payment mechanics ($0.01 per call, x402, trial) and cold start behavior. It lacks details on rate limits or caching but is adequately transparent for a paid API.
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?
Four sentences efficiently cover purpose, payment, and usage guidance. Could be slightly more terse, but no filler.
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?
No output schema exists; description lacks details on the return format (e.g., fields for each coin). Could specify what data is returned besides ranking.
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 covers both parameters with descriptions; the description adds context about default behavior (no symbol needed) and ranking order, complementing 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 the tool scans the market for coins currently at a top (most overbought/sell) and ranks them. This is specific and distinguishes from siblings like scan_bottoms.
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 contrasts with the 'pitch' tool (count versus names) and highlights cold start behavior. Provides payment and trial usage instructions, though it does not cover all sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check your subscription status & terms (FREE), or activate the monthly plan: call with activate:true to receive the $50 x402 payment challenge, sign it, and retry — that buys 30 days of unlimited calls and returns your X-SUB-KEY token (pass it as a header to skip per-call payment). Until you subscribe, signal calls are $0.01 each (6-day trial from your first paid call). Optionally pass your ERC-8004 agentId to link it.
| Name | Required | Description | Default |
|---|---|---|---|
| agentId | No | Optional ERC-8004 agent id to link to this subscription. | |
| activate | No | true = request the $50 subscription payment challenge (402) to sign & retry. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: the 402 payment challenge, token return, per-call cost, trial period, and optional agent linking. Could be more structured but covers important aspects.
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 run-on paragraph with three sentences conveying multiple pieces of information. Could be better structured for readability.
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 complexity of subscription activation and payment flow, the description adequately explains the process, token return, and pricing. Lacks explicit return value info but that's implied.
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% parameter coverage; description adds context: 'activate' triggers payment challenge, 'agentId' links to subscription. Adds value beyond schema descriptions.
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 specifies the tool's two modes: checking subscription status (FREE) and activating the monthly plan with activate:true. It distinguishes from sibling tools (evaluate_symbol, etc.) which are unrelated to subscriptions.
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 on when to use each mode (check vs activate), including the payment challenge flow and token usage. While it doesn't state when not to use siblings, siblings are sufficiently different to not require exclusion.
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.0.0ratescan_bottomsscan_topssubscribeScored across 4 tools
Each tool has a clearly distinct purpose: rate for feedback, scan_bottoms and scan_tops for opposite market scans, and subscribe for subscription management. No overlap or ambiguity.
All tool names are single-word, lowercase, and follow a verb-based pattern. The scan_ prefix for scanning tools creates a clear naming convention.
Four tools is reasonable for a signal service, covering feedback, market scans, and subscription. Slightly minimal but functional.
The domain is cryptocurrency signals, but there is no tool for direct signal delivery or viewing historical signals. The set covers scans and subscription but lacks core signal output.
Crypto bottom/top signals: verdict + score per coin, market scans. Pay-per-call x402.
Korea stock (KOSPI/KOSDAQ) bottom/top signals: verdict + score, scans. Pay-per-call x402.
Crypto market signals and portfolio telemetry. 6 tools pay-per-call in USDC, no API key.
Stock market trading signals: regime, ranked buy list, stock + sector reads. Free tier + x402 live.
