MCP.Market

Decker MCP server

online · 100% uptime
by gigshow·io.github.gigshow/decker·v1.10.0·3 stars

Deterministic market-state engine for trading agents — state, gate, coordinates, with receipts.

A85/100grade A
What users say
No reviews yet
Be the first
Safety scan
A85/100

full report

Adoption
Growing

3 stars

Reviews

Write one

Nobody has reviewed Decker yet.

If you have run it, two minutes of your experience saves the next person an afternoon.

Decker tools (15, 2 write)

write = sends, deletes, buys or posts
  • decker.close_positionFree

    Axis③ (Order/Execution) — closes (or partially reduces) an existing position through DECKER'S OWN execution engine (see decker.place_order for what that means — same account-linkage requirement applies here for real positions). Unlike place_order, there is no crypto-6 restriction — this reduces risk, not adds it, so any symbol you actually hold (including HL-synthetic/KRX paper positions) can be closed. Mode is NOT chosen by the caller — this looks up whatever position(s) actually exist for the symbol (real via live exchange query, virtual via the paper ledger) and closes whichever are open; if both a real and a virtual position exist for the same symbol, both are closed and the response reports execution_mode as 'mixed'. No open position for the symbol = a clean not-found response, not an error — safe to call speculatively.

  • decker.get_assemblyFree

    Multi-timeframe optimal-path assembly per symbol (STRATEGY_LAYER §8): one deterministic machine verdict combining all live timeframes — direction, grade (aligned | structure+pullback | exhaustion-reversal), entry (now vs wait, with source TF), stop (risk stop), target (upper-TF target), RR, and a conditional switch coordinate on mixed structure. Upper TF supplies the target (slower = higher success), lower TF supplies the entry. This is the single judgment authority — narrate or filter it, do not re-decide coordinates. Omit symbol for all 14 universe symbols. ⚠ grade='aligned' means no OPPOSING-direction row exists among the active timeframes — it does NOT mean every timeframe's gate is GO/actionable right now. Check matrix_summary[].gate per timeframe before treating 'aligned' as 'all timeframes tradeable now'. ⚠ entry.mode='지금'(now) is a pure price-geometry verdict (STRATEGY_LAYER §8 R3 — is current price within the exhaustion-reversal zone or the ±0.3% entry band), independent of any timeframe's trigger/gate state — it does NOT mean the engine has confirmed a break event on this bar. Check the entry TF's row in matrix_summary[].gate before treating entry.mode='지금' as 'a trigger just fired, act now'.

  • decker.get_market_stateFree

    Market State v0 — current engine structural state for a symbol/timeframe (latest evaluated bar, persisted engine emit read as-is, zero recompute). DOMAIN FRAME (why this engine exists): the market is read as a TARGET GAME — every coordinate comes from a *verified anchor* (a past level where a triggered move actually succeeded). The `game` block tells you the context that matters: game.status = forming_target (new anchor set, awaiting test) | testing_target (price is testing whether the declared target holds) | direction_resolved (game decided, price traveling); game.target = WHO is being judged (anchor id/phase/band); game.progress_dest = where price goes if the move proceeds (the opposing verified anchor to conquer); game.reverse_dest = where it goes if the move fails (the opposite house — also the stop logic's home); game.why_gate = full gate derivation chain; game.zt_regime = output canonicality (restored = deterministic delta lineage). action_gate alone (GO/WATCH/HOLD) is only a posture — the game context is the information. RAW CONTRACT: fields are engine-native vocabulary (c_state, hold_reason, R_* risk enums …), NOT customer-facing prose — for a human-language view use decker.get_view (with tf) or decker.get_reading. layer=STATE: this is a market-state reading, NOT a trade instruction. Absent fields are null (engine did not emit that axis — no filling). IMPORTANT: top-level state.c_state/action_gate/trigger_kind reflect the TRIGGER SNAPSHOT (only populated on a bar that actually had a trigger event) — null on most bars is normal, not a data gap. For the always-present, every-bar-populated view of the same axes use game.phase.c_state / game.phase.action_gate instead (different freshness, same underlying engine state machine). Don't read a null top-level field as 'engine has no state' — check game.phase first. object_context (top-level, W1-C1 standard object block, present when a recent trigger bar exists): my_anchor/opp_anchor(reversal destination)/judgment_ref/geometry/why(engine reason_codes)/reverse_branch context (object_context.reverse_direction_conflict is present only when a local reversal shows stage='confirmed' but the swing's confirmed direction still disagrees — read it before treating reverse_branch.stage='confirmed' as a swing-level reversal). null on non-trigger bars or symbols outside the narrative universe (e.g. individual KRX stocks). current_price (top-level, 2026-09-03): {price, bar_ts} — the single latest completed-bar close for this symbol ACROSS ALL timeframes (not just the requested tf), useful when comparing multiple timeframes' target bands against one 'now' price. null for KRX individual-stock symbols. Before placing any order through any execution tool, check the intent with decker.validate_intent.

  • decker.get_positionsFree

    Axis③ (Order/Execution) — this user's actual exposure: real open futures positions (execution_mode=real, with live sl_price/tp_price), virtual (paper) open positions, and the last 10 closed round-trips per mode. This is what your money actually did, distinct from decker.get_signals (axis②, what the engine recommends) — use this before deciding whether to place another order (avoid duplicate/over-exposure) and to check current protective stop/target on a real position.

  • decker.get_price_axis_stateFree

    Price-axis (가격축) state v0 — latest engine emit for a symbol/timeframe on the SEPARATE close-price target-selection loop (parallel to MAIN, same underlying CBA principle applied to the closing-price series alone; see PRICE_AXIS_CLOSE_STATE_ARCHITECTURE_2026-09-19.md). Zero recompute — reads engine_bar_state.reason_summary.price_axis as persisted (Store-Output-Read, same architecture as decker.get_market_state, just a different axis). OMIT `timeframe` to get the MULTI-TIMEFRAME view: {timeframes:{30m,1h,4h,8h,1d,1w}, missing:[...]} — every TF's state side by side, which is how this engine is meant to be read (a target selected on 4h/1d resolves slowly, so lower TFs act as hints; conversely when 4h/1d has no target, 30m/1h supply the faster decision point). NO cross-TF verdict is computed — each TF's judgment is its own engine's, this just puts them side by side; the synthesis is the reader's/strategy layer's job. session.active = a target is currently being judged (test phase in progress). active_target = {price, run_direction, born_ts} of the candidate that opened the current/most-recent judging session — 'what price was most recently selected as a target'. canonical_tail = {phase, direction_hint, confirmed_direction} from the canonical CONFIRMED/FAILED tracker — C_TARGET (just selected) | TESTING (test phase) | CONFIRMED | FAILED. pending_targets = up to 5 untouched candidate prices, nearest-to-current-close first (a watchlist of future targets). events = this bar's PriceAxisEvent list (target_touch_inside/break, missing, test_try, confirm, post_confirm_retouch) — empty list is normal (no event this bar). phase_state = {position(above|below|inside), key, confirm_aligned, anchor_high/low} — the A-7 axis: where the close sits relative to the target's high/low band, and (on a confirm bar) whether that position agrees with the confirm key. confirm_aligned=false means the confirm fired AGAINST the position (e.g. price above the band but a sell confirm); position=inside means A-7 hold, not a confirm. post_confirm_retouch is a CONTEXT TAG that always accompanies a target_touch_inside/break, never replaces it: it marks that this session-opening touch follows a completed (confirmed) judging session, i.e. a re-entry rather than a cold start. It does not carry its own coordinate. move_proposal = {posture, triggering_events, strategy_version} from the PRICE strategy box (propose_move) when this bar had events, else null — posture is currently always 'immediate' (v0 default, not yet tuned per-event). This is a PROPOSAL, not an instruction or a gate. IMPORTANT — action_gate is always null here BY DESIGN, even when move_proposal is populated: this axis is diagnostic-only (OUT_CONTRACT §1), NOT wired to engine_action_gate or any order-execution path yet — do not read events/canonical_tail/move_proposal as a trade signal. For actual GO/WATCH/HOLD posture and trigger history, use decker.get_market_state (MAIN axis) instead. null on symbols/timeframes the engine has not evaluated yet, or on any bar before this axis was wired into the live pipeline (2026-09-23).

  • decker.get_readingFree

    AI-synthesized market reading for a symbol/timeframe, in customer-facing language: current state description, directional bias scores, bidirectional break targets, MTF verdict per timeframe, and an execution hint (stance + long/short setups). Engine-native raw fields are NOT exposed here — use the REST raw contract (GET /public/reading) or decker.get_market_state for those — except object_context (W1-C1 standard object block, explicit exception: my_anchor/opp_anchor/judgment_ref/geometry/reverse_branch + why limited to action_gate/trigger_kind (internal reason codes scrubbed on this customer surface), present when a recent trigger bar exists, null otherwise incl. individual KRX stocks). object_context.reverse_direction_conflict is present only when a local reversal shows stage='confirmed' but the swing's confirmed direction still disagrees — read it before treating reverse_branch.stage='confirmed' as a swing-level reversal. execution_hint.preferred_direction is derived from key_direction alone and is NOT guaranteed to have a matching long_setup/short_setup (they come from an independent break-target resolver) — check that the setup for the preferred side is non-null before treating preferred_direction as an actionable side.

  • decker.get_signalsFree

    Active trading signals for the current user (with Skill Overlay applied), in customer-facing shape: coordinates (entry/target/stop), decision (ENTER/WAIT/SKIP — is_actual_trigger=true only for ENTER; WAIT/SKIP are standing candidates, not executed triggers), action_gate posture (GO/WATCH/HOLD — a stance, not an order command), progress, MTF verdict, and a plain-language summary_ko line. risk_reward_ratio is computed on the DISPLAYED coordinates (after overlay). Signals are retained rather than cut when they age (turn-retention policy) — read freshness_state (open|aged) / age_bars / freshness_sec before treating an old PENDING row as current. Filtered by symbols / min_progress / action_gate — action_gate here filters the CURRENT-MOMENT representative state, it does not search history (almost always 0 rows unless a gate is GO right now); for past GO events with their entry/target/stop and realized performance use decker.get_trigger_history instead. object_context (W1-C1 standard object block, present when a recent trigger bar exists): my_anchor / opp_anchor (reversal destination) / judgment_ref / geometry / why (action_gate + trigger_kind only — internal reason codes are scrubbed on this customer surface, use decker.get_market_state for those) / reverse_branch context (object_context.reverse_direction_conflict is present only when a local reversal shows stage='confirmed' but the swing's confirmed direction still disagrees — read it before treating reverse_branch.stage='confirmed' as a swing-level reversal). null on non-trigger bars or symbols outside the narrative universe (e.g. individual KRX stocks). Before placing any order through any execution tool, check the intent with decker.validate_intent.

  • decker.get_state_timelineFree

    Market State v0 — per-bar state timeline for a symbol/timeframe (same schema as decker.get_market_state, except each item carries a SLIM `game` tag {status, target_id, zt_regime, provenance} instead of the full game block — read status transitions across bars to see how the target game unfolded (forming → testing → resolved/failed); ascending by bar_ts). Bars the engine did not emit are simply absent (honest gaps, no filling).

  • decker.get_trigger_historyFree

    ACTION axis — actual historical GO triggers (not standing WATCH/HOLD candidates) for a symbol, with entry/target/stop coordinates and realized performance (mfe_pct/mae_pct/exit_reason/exit_price from trigger_performance, null = still open). Distinct from decker.get_signals (which reflects only the current-moment state, not a searchable history — its action_gate filter answers 'what does symbol×tf look like right now', not 'when did this last fire'). Use this to answer 'what did the engine actually trigger recently and at what price' — decker.get_signals/get_market_state cannot answer that. direction is judgment_signals-native vocabulary ("long"/"short"), distinct from the "+"/"-" convention used by other tools — read as-is, no translation.

  • decker.get_user_skillsFree

    Trading skill catalog + currently active overlay for this user. Returns 8 published skills (conservative_v0/standard_v0/aggressive_v0/default_v0/scalp_v0/tight_v0/wide_v0/swing_v0) and the user's selected one.

  • decker.get_viewFree

    The engine's VIEW for a symbol — the same composed card the daily briefing sends (single composer, verbatim): overall verdict, big/main timeframe alignment, the current game narrative in plain language, coordinates (baseline ref_price / target / invalidation), 'at this price, this view', and recent self-scoring verdicts (receipts). layer=STATE_VIEW: a market-state reading, NOT a trade instruction. Prefer this over get_market_state when you want the interpreted view instead of raw engine fields. object_context (W1-C1 standard object block, present when a recent trigger bar exists): my_anchor/opp_anchor(reversal destination)/judgment_ref/geometry/why(action_gate+trigger_kind only, reason codes scrubbed on this customer surface)/reverse_branch context (object_context.reverse_direction_conflict is present only when a local reversal shows stage='confirmed' but the swing's confirmed direction still disagrees — read it before treating reverse_branch.stage='confirmed' as a swing-level reversal). null on non-trigger bars or symbols outside the narrative universe. Before placing any order through any execution tool, check the intent with decker.validate_intent.

  • decker.place_orderwrite actionFree

    Axis③ (Order/Execution) — unlike every other tool here, this one moves money. It places a market order through DECKER'S OWN execution engine (same path as the decker-ai.com chat trading UI, source='mcp') — it does NOT hand off to your own broker connection or exchange account; Decker executes using whatever exchange credentials this user has separately linked to their Decker account on the website. execution_mode (virtual|real) is NOT chosen by the caller — it is resolved server-side from this user's account settings (user_settings.execution_mode) AND the platform's real-trading kill switch; a real-money order requires both an explicit user opt-in AND role/tier eligibility (PRO/ENTERPRISE or admin) AND passing the tier's hard notional/leverage/daily-count caps (checked here before dispatch — violation blocks the order, does not downgrade it to virtual). The response always states which mode actually executed — treat 'virtual' in the response as authoritative even if you expected real. Restricted to the crypto-6 universe (BTCUSDT/ETHUSDT/SOLUSDT/BNBUSDT/XRPUSDT/DOGEUSDT) for this MCP path — HL-synthetic and KRX symbols are read-only via other tools. Call decker.validate_intent first to read the engine's current stance; this tool does not check it for you. Positions are tracked as ONE net row per user+symbol+mode, not per order — if you already hold a position on this symbol, this order nets into it and the response's pre_existing_position field says so. A later close_position call closes the combined total, not just what this call added.

  • decker.set_skill_overlayFree

    Change active trading skill overlay for this user. Immediately affects all subsequent get_signals calls and downstream channels.

  • decker.update_protective_stopswrite actionFree

    Axis③ (Order/Execution) — modifies the stop-loss and/or take-profit on an EXISTING open position. There is no cancel_order tool because Decker only places market orders (there is no resting order to cancel) — the actual gap this fills is modifying protective stops on a position you already hold. real: cancels the old exchange stop/take-profit order(s) and places new ones at the given price(s) (new order placed first, old one canceled only after — no unprotected window). virtual: updates the paper position's stop_loss/take_profit columns directly (polled by the paper monitor). Provide at least one of sl_price/tp_price — the other side, if omitted, is left at its current value. If both a real and a virtual position are open for this symbol, pass mode explicitly or the call is rejected asking which one.

  • decker.validate_intentFree

    Pre-trade gate check for a proposed order intent. Call this BEFORE placing any order through any execution tool (e.g. a broker MCP's review→place flow). Checks the intent (symbol + side) against Decker's deterministic market state: engine action_gate (GO/WATCH/HOLD — a transition posture, not an order command), current structural state, and the active signal's direction / invalidation (stop) coordinates. Returns a stance reading, NOT an approval or rejection: the vocabulary is the engine gate as-is plus a mechanical side_alignment (aligned/opposed vs the active signal's direction). covered=false means the engine does not emit state for this symbol — treat as unknown, not as HOLD. top-level action_gate can be null even when covered=true — this is not a missing field, it means the current bar has no fresh trigger reading; check gate_null_reason ('no_gate_available' = neither the current bar nor the carried-forward signal had a gate at all, vs 'signal_stale' = a value existed but the underlying signal exceeded the staleness threshold and was deliberately suppressed rather than served as a confident-but-old answer). The order decision and responsibility remain with the calling agent/user. Every check is persisted to an auditable decision ledger (check_id). signal.object_context (W1-C1 standard object block, present when a recent trigger bar exists): my_anchor/opp_anchor(reversal destination)/judgment_ref/geometry/why(action_gate+trigger_kind only, reason codes scrubbed)/reverse_branch context (object_context.reverse_direction_conflict is present only when a local reversal shows stage='confirmed' but the swing's confirmed direction still disagrees — read it before treating reverse_branch.stage='confirmed' as a swing-level reversal) — null when there is no active signal or no trigger bar.

Public scan report

scanner v0.1.9 · 2026-09-26 · same rubric, same numbers if you re-run it

1 low
  • –Code scanremote-only server, no package to scann/a
  • Live reliabilityremote reachable in 1278ms20/20
  • Tool poisoning15 tool descriptions checked13/15
  • Auth qualityAPI key sent as a header8/15
  • Maintenancelast push 0 days ago15/15
  • Maintainer identityregistry namespace matches repository owner; GitHub account older than a year8/10

Findings (1)

  • lowUnusually long tool description (over 2,000 characters)poison.long-description
    tool decker.get_market_state: …Market State v0 — current engine structural state for a symbol/timeframe (latest evaluated bar, persisted engine emit read as-is, zero recompute). DOMAIN FRAME (why this engine exists): the market is read as a TARGET GAME — every coordinate comes from a *verified anchor* (a past level where a triggered move actually succeeded). The `game` block tells you the context that matters: game.status = forming_target (new anchor set, awaiting test) | testing_target (price is testing whether the declared target holds) | direction_resolved (game decided, price traveling); game.target = WHO is being judged (anchor id/phase/band); game.progress_dest = where price goes if the move proceeds (the opposing verified anchor to conquer); game.reverse_dest = where it goes if the move fails (the opposite house — also the stop logic's home); game.why_gate = full gate derivation chain; game.zt_regime = output canonicality (restored = deterministic delta lineage). action_gate alone (GO/WATCH/HOLD) is only a posture — the game context is the information. RAW CONTRACT: fields are engine-native vocabulary (c_state, hold_reason, R_* risk enums …), NOT customer-facing prose — for a human-language view use decker.get_view (with tf) or decker.get_reading. layer=STATE: this is a market-state reading, NOT a trade instruction. Absent fields are null (engine did not emit that axis — no filling). IMPORTANT: top-level state.c_state/action_gate/trigger_kind reflect the TRIGGER SNAPSHOT (only populated on a bar that actually had a trigger event) — null on most bars is normal, not a data gap. For the always-present, every-bar-populated view of the same axes use game.phase.c_state / game.phase.action_gate instead (different freshness, same underlying engine state machine). Don't read a null top-level field as 'engine has no state' — check game.phase first. object_context (top-level, W1-C1 standard object block, present when a recent trigger bar exists): my_anchor/opp_anchor(reversal destination)/judgment_ref/geometry/why(engine reason_codes)/reverse_branch context (object_context.reverse_direction_conflict is present only when a local reversal shows stage='confirmed' but the swing's confirmed direction still disagrees — read it before treating reverse_branch.stage='confirmed' as a swing-level reversal). null on non-trigger bars or symbols outside the narrative universe (e.g. individual KRX stocks). current_price (top-level, 2026-09-03): {price, bar_ts} — the single latest completed-bar close for this symbol ACROSS ALL timeframes (not just the requested tf), useful when comparing multiple timeframes' target bands against one 'now' price. null for KRX individual-stock symbols. Before placing any order through any execution tool, check the intent with decker.validate_intent.…
Overall 85/100. Components that don't apply are left out of the denominator. Any critical finding is an F.RubricAppeal a findingJSON

How Decker compares

Against every graded MCP server, from our own scans and uptime checks. Updated after each scan run.

Safety score
85/100
higher than 70% of 48,255 servers
Tools
15
the typical server has 7
Tools that change things
13%
typical: 0%. Fewer write tools means less an agent can break
Uptime
100%
of our recent checks; the typical remote server answers 100%
Response time
322 ms
faster than 45% of 30,031 servers
GitHub stars
3
more than 80% of 28,688 servers

What its tools let an agent do: 11 read · 4 change

Install Decker in Claude Code, Cursor or VS Code

claude mcp add --transport http decker https://api.decker-ai.com/api/v1/mcp
Add to Cursor

What the publisher says

From the Decker repository's README, as published. We do not edit it. Read it on GitHub

<!-- Keywords: AI trading signal, crypto market state engine, structural analysis, algorithmic trading API, Telegram trading bot, Python SDK, decker-client, deterministic signal, progress_pct, operation rules, GO WATCH HOLD, KRX, KOSPI -->

&nbsp; Decker AI

The deterministic market-state layer your trading agents call.

Rules trade, LLMs explain. Live, non-custodial, with receipts.

Open the app · Telegram bot · Kakao channel · API docs

What you get

  • Signals you can act on, with context. Not "BUY" — GO / WATCH / HOLD + progress_pct (0–100% lifecycle) + entry / stop / target.
  • It explains itself. Every signal has a structural cause (multi-timeframe alignment, state machine phase) that an LLM translates into plain language.
  • Same engine, two markets. Crypto (24/7) + Korean equities (KOSPI + KOSDAQ, Beta).
  • Use it your way. Web app, Telegram, Kakao channel, REST API, or MCP server inside Claude / Cursor.

"Where are we in the current structural cycle — and what's the next optimal move?"

Get started in 60 seconds

Free tier is generous (30 calls/day on the API; Web + Telegram included). During Beta, signed-up users get PRO access for free.

See it in action

Start here — 30 seconds. No signup, no key.

curl -s https://api.decker-ai.com/api/v1/public/demo | jq .

▶️ Play — MCP journey demo (30s) · One live session, all 13 tools: explore a market → set your risk profile → decide → execute → manage — zero LLM in the signal path.

Shortened. The full README is on GitHub.

Nothing above is checked by us. What we check is on the safety report.

Decker: common questions

Is Decker MCP server safe?
Yes, by our scan: it is graded A (85/100). Read the Decker safety report
How do I install Decker?
It runs remotely at api.decker-ai.com. Add it to Claude Code, Cursor, VS Code or Claude Desktop with the snippets above, or call it through the mcp.market gateway without installing anything.
Does Decker need an API key?
Yes. The registry entry asks for X-API-Key.
Is Decker maintained?
The last commit was 39 days ago (2026-09-26). The latest release is v1.10.0.
Is Decker up?
100% of our last 28 checks got an answer. We check remote servers about four times a day.
What can I use instead of Decker?
Servers from other publishers that do the same job: CCXT MCP server.
How does Decker compare with other MCP servers?
safety score 85/100 (higher than 70% of 48,255 servers); tools 15 (the typical server has 7); tools that change things 13% (typical: 0%. Fewer write tools means less an agent can break). Full comparison.

Alternatives to Decker

Same job from other publishers: the closest match first, then the best rated.

  • CCXT
    Official CCXT MCP server - Market data and trading across 100+ exchanges and prediction markets
    A