Decker

io.github.gigshowPublished by GitHub account gigshowv1.10.0Updated Oct 27, 2026

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

VerifiedStreamable HTTPWeb executableFinanceAI & ML

Overview

AI-generated overview

Decker is a remote MCP server exposing a deterministic market-state engine for crypto and Korean equities, giving assistants verdicts, signals, positions and…

What you can do
  • Read per-symbol verdicts and per-timeframe market state, plus plain-language readings and ready-to-show status cards
  • List active trading signals with entry, target and stop, and check historical trigger performance and price episodes
  • Review open positions and exposure, and validate a proposed order intent before placing it
  • Switch the active trading skill overlay and list available skills
  • Place market orders, close or reduce positions, and modify stop-loss or take-profit levels
When to use it
Useful when an assistant needs structured, reproducible market state and trade coordinates for supported crypto pairs or Korean stocks, or when it should gate and execute trades through Decker's own engine rather than improvising analysis.
Requirements
Remote Streamable HTTP endpoint at the API host's MCP path; a Decker API key sent in the X-API-Key header (free tier available, issued in the web app settings or via Telegram). Clients without native remote support need the mcp-remote bridge and Node/npx. Paid tiers raise daily call limits and unlock execution.
Before you install
The API key is a credential and should be kept out of shared configs. Several tools move money: place_order and close_position execute through Decker's own engine, not your broker, and update_protective_stops changes live risk levels; set_skill_overlay immediately changes later signals. Free tier is read-only with a one-day cache. Output is market information, not investment advice.

Installation

In SourceWeft

  1. Open Decker in the dashboard and add it to a workspace.
  2. Connect X-API-Key credentials. They are stored privately and never shown on public pages.
  3. Enable the server for the chats that should use its tools.

Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.

Use with an agent

Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.

Read https://sourceweft.com/mcp/io.github.gigshow%2Fdecker/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.

Read the install guide the agent follows

Other MCP clients

Add this to your client's mcpServers config.

{
  "mcpServers": {
    "decker": {
      "type": "http",
      "url": "https://api.decker-ai.com/api/v1/mcp",
      "headers": {
        "X-API-Key": "<YOUR_API_KEY>"
      }
    }
  }
}

README

[DeckerClaw]  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

[Open App] [Telegram] [Kakao Channel] [API Docs] [MCP Server] [PyPI] [Track record] [License]

[Decker AI — the live market-state cockpit across crypto and Korean equities (KOSPI 200)]

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

PathBest forStart
📱 Web appMost people — full dashboard, mock trading, KRX watchlistdecker-ai.com — sign up free
🤖 Telegram botQuick signal checks on your phone@deckerclawbot — /start
💛 Kakao channel한국 사용자, KRX 시그널 알림pf.kakao.com/_RxlxjVX
🧠 MCP serverClaude / Cursor / Codex usersdecker-ai.com/mcp — 2-min setup
🛠 REST APIDevelopers building bots & appsDEVELOPER_README.md

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.

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

[MCP journey demo — all 13 tools chained through one live session: explore, set risk, decide, execute, manage]

▶️ 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.

Shorter cut with the response and the plain-language takeaway shown together on every call (no separate captions needed): Play — Shorts cut (35s)

The engine room — live FSM, MTF alignment, R:R

[The live cockpit — full universe grid with per-symbol state and AI reading]

▶️ Play — the live cockpit (16s) · Every signal traces to a structural cause: progress_pct + operation_gate + entry / stop / target.

Signal → execution, non-custodial

[Hyperliquid — state, signal-engine coordinates, and a non-custodial order]

▶️ Play — non-custodial execution (16s) · Click Order · wallet-sign · custody 0. Decker relays your signature only (revocable agent wallet, EIP-712). For information only — not investment advice.

Read it daily — and we score our own calls

[The web briefing hub — per-symbol view with baseline, target, and invalidation] [The daily briefing on Telegram — picks and subscribe]

▶️ Play: web hub (10s) · Telegram (6s)

Every morning (08:00 KST): the engine's view per symbol — baseline, what winning and losing look like, and a pick you can answer. Evening: the same view scored against what actually happened — hits and misses alike, on the record. We stamp our wrong calls too.

Web hub: decker-ai.com/briefing · Subscribe: @deckerclawbot → /briefing

Korean equities (KRX) — Beta, free

[Korean equities — today's hot market and portfolio actions on KOSPI]

▶️ Play — KRX (16s) · Same deterministic engine on KOSPI + KOSDAQ. Portfolio states — ADD / HOLD / REDUCE / EXIT, not buy/sell. Daily closing-bell checkup at 16:30 KST · @krxdeckerbot.


Three things that make it different

1. progress_pct — every signal has a lifecycle. A signal at 25% progress is a different trade than the same signal at 80%. Most tools just say "BUY"; Decker tells you where in the move you are.

Entry                                                           Target  0%──────────33%──────────50%──────────67%──────────83%────────100% Wait       Entry        Active       Late TP      Final TP     Exit

2. GO / WATCH / HOLD — three gates, not binary.

GateMeaning
GOStructure confirmed — entry conditions met
WATCHSignal forming — monitor, no entry yet
HOLDActive position — no new entry signal

WATCH is the gate most tools skip. It's why users enter too early.

3. Deterministic + traceable. LLM explains, doesn't decide.

Typical AI signalDecker
SourceML / LLM price predictionDeterministic state machine
OutputBUY / SELLprogress_pct + operation_gate + ranked choices
LLM roleMakes the callExplains the structural state
Auditability❌ Black box✅ Every signal has a trace_id
Cost per signalHigh$0 on the rules path
Reproducibility❌✅ Same input → same output, always

Pricing

TierPriceDaily API limitMCPAuto-trade
FREE$0 forever30 calls/dayread-only (1d cache)❌
PRO$20 / mo · 7-day trial1,000 / dayfull (13 tools)virtual + real
ENTERPRISEContact us100,000+ / day · customfull + per-org skill catalog+ custom integration

Beta (now): all authenticated users get PRO for free via BETA_TIER_OVERRIDE=PRO. No payment required.

Web sign-up and Telegram bot are always free for the basics.


For developers

Building a bot, app, or agent on top of Decker? Everything you need — REST endpoints, MCP server (Claude / Cursor / Codex), Python SDK, OpenClaw skill, self-host — lives in one place:

→ DEVELOPER_README.md

bash
# 60-second smoke test (no auth needed)curl https://api.decker-ai.com/api/v1/public/demo
bash
# With an API key (decker-ai.com → Settings → API Keys, or Telegram /apikey)curl "https://api.decker-ai.com/api/v1/public/signals/BTCUSDT/latest?timeframe=1h" \  -H "X-API-Key: dk_live_xxx"

Prefer a runnable file? → examples/quickstart.py — zero dependencies (stdlib only), no key, prints the composed view + receipts in one run. Wrapping Decker for an agent crew: examples/langgraph_decker_tool.py. More in examples/.

The demo returns the composed view — the same card our daily briefing sends:

json
{ "layer": "STATE_VIEW", "symbol": "BTCUSDT", "ref_price": 63650.0,  "lines": ["■ BTC — 층간 힘겨루기: 주 판 아래쪽 · 지금 판 위쪽", "…"],  "wait_target": "...", "invalidation": "...",  "verdict_recent": [{"briefing_date": "2026-07-05", "slot": "morning", "verdict": "hit"}],  "provenance": { "composer": "briefing_story.compose_card" } }

Add to Claude Desktop / Cursor (MCP): guided 2-minute setup with per-client config → decker-ai.com/mcp.

Cursor (~/.cursor/mcp.json) takes a remote server directly:

json
{  "mcpServers": {    "decker": {      "url": "https://api.decker-ai.com/api/v1/mcp",      "headers": { "X-API-Key": "dk_live_YOUR_KEY" }    }  }}

⚠ Endpoint is /api/v1/mcp (stateless Streamable HTTP) — an old /sse suffix now returns 405 Method Not Allowed.

Claude Desktop / Codex reach it through the mcp-remote bridge (needs Node/npx) — see decker-ai.com/mcp or DEVELOPER_README.md (endpoints · auth · rate limits · MCP tools · SDK · OpenClaw · self-host).

Running a multi-agent crew (TradingAgents / LangGraph / AutoGen)? Give your analysts one deterministic market-state instrument — with receipts — instead of re-deriving structure per prompt: → docs/integrations/multi-agent-frameworks.md


How the engine works (one diagram)

Raw OHLCV candles  ↓  Sequence Labeler  →  every candle gets a role (anchor / test / signal)  ↓  State Machine     →  C_SET → B_FORMING → B_SET → A_FORMING → W_PENDING  ↓  Operation Gate    →  GO · WATCH · HOLD  ↓  RULES Engine      →  9-layer YAML rulebook → strategy + ranked choices  ↓  AI Consultation   →  LLM translates structural state → plain language  ↓"67% progress. B-leg confirmed. Recommended: 30% partial TP or hold to target."

No price prediction. No black box. Every output traces to a formal structural cause.

Deep dives: Sequence Engine · Labeling Algorithm · Market State Theory


Supported symbols

Crypto (GA): BTCUSDT · ETHUSDT · SOLUSDT · BNBUSDT · XRPUSDT · DOGEUSDT — timeframes 30m, 1h, 4h, 1d.

KRX (Beta, free): KOSPI 948 + KOSDAQ 1,822 = 2,770 tickers. Universe = top 200 by trading value ∪ user watchlist ∪ momentum spike ∪ volume spike. Timeframe 1d only (1w expanding). Daily evaluation at 16:30 KST.

KRX details: docs/krx/KRX_BUSINESS_MODEL_AND_ROADMAP_2026-05-09.md.


Performance

We don't publish a headline win rate. Backtest numbers without method and sample size are marketing, not evidence — and easy to cherry-pick.

What we stand on instead:

  • Deterministic & reproducible. Same input → same output, always. The rules path has zero LLM in it, so a signal is not a model's opinion — it's a formal structural verdict you can re-derive.
  • Auditable. Every read carries its provenance (composer + the versioned rulebook contract) and traces back to the exact engine emit. The full RULES.yaml is open, so you can re-derive any verdict yourself.
  • Scored in public, daily. The morning briefing's view is graded against what actually happened that evening — hits and misses alike, on the record. → decker-ai.com/briefing · a GitHub Action stamps the daily scorecard straight into this repo: TRACK_RECORD.md

Method and rulebook are open: Model & Algorithm · Operation Rules (YAML) · Signal Performance.

For information only. Not investment advice.


Docs

DEVELOPER_README.mdAPI · MCP · SDK · OpenClaw · self-host — start here if you're building
Quick Start5-minute path picker — Telegram / MCP / REST / SDK
API GuideFull field-level endpoint reference + error codes
Docs by personaTrader / Builder / Curious about the engine / Evaluating claims
ArchitecturePipeline, state engine, modules
Model & AlgorithmHow the signal engine works
Operation RulesOpen YAML rulebook (v2.4.7+)
Article Series (1–15)Deep dives on Medium
RoadmapWhat's next
llms.txtLLM / AI agent discovery manifest

Links


This repository is the public hub for Decker AI — SDK, samples, rulebook, architecture docs, OpenClaw skill packages. Production application code runs in a private monorepo. All listed endpoints, channels, and the web app are live.

Built by gigshow (Dohyung Kim · 김도형) — founder. Open to investor / partnership conversations.

Source: README.md at commit b3f4fd2

Tools

14

decker.get_assembly

THE answer for 'what is the situation and what do I do on this symbol now' — one verdict per symbol, built from the per-timeframe judgment state (CR1); no scores or weights. READ IN THIS ORDER: (1) verdict = state (direction · phase) + action: 진입 enter now (a new signal) | 유지 hold the existing stance, NOT a new entry | 청산 exit | 대기 wait; `reason` says why, `until` names the close that would change it. (2) summary_ko = ready-to-show Korean lines. (3) entry / stop / target / rr = the prices (entry.mode says whether it is a new entry or on hold — when the action is not 진입 it never says 'now'; target may be null with target.reason, e.g. no coordinate at least 2% from the entry price; rr mixes the entry timeframe's stop with the target timeframe's target). (4) as_of = the bar this answer is based on. Default = the answer only (about 3KB per symbol; summary_ko already narrates the next closes and the last signal). Pass detail=true for the structured detail: path (nearby prices and what a close there means), watch (upcoming bar closes in time order and the question each decides), story (this / last signal), ladders, matrix_summary (every timeframe's row incl. gate), tf_states (EVERY timeframe's own state: judgment stage, open reversal test with its confirm price, engine action, next-bar label chain, recently missed targets — none folded by direction), knots (every timeframe's decision prices ordered by distance from the price, up and down, with which timeframes and roles sit on each — the ORDER in which transactions would be reached, not a probability). `reason` may end with '반대 방향 반전 보류 중: …' = other timeframes whose reversal test runs AGAINST the verdict's direction, i.e. is testing the current stance (a fact, not a vote; it never changes the action). Omit `symbol` for all 14 symbols. Roles: frame = highest confirmed timeframe (sets direction and target); entry = lowest aligned timeframe whose signal is alive; 1w supplies direction/target only, never an entry. grade: 정렬

Parametersdetailsymbol

decker.get_market_state

PER-TIMEFRAME judgment state of a symbol, structured (consumer contract CR1) — the evidence behind decker.get_assembly's single verdict. For 'what is the situation and what do I do' call decker.get_assembly first; use this when you need one timeframe's exact state. Per timeframe (top→short): stage = target_selected (대상선정) | pending (판정보류: the close is still inside the signal bar) | confirmed (확인) | failed (실패) | none; side = buy/sell (a failed signal asserts nothing about the opposite side); signal_time; signal_bar {time, low, high} (its edges decide confirm/fail); entry (= close at the signal); stop; target (take-profit: opposite-side confirmed-signal edge at least 2% from entry, else null + target_reason); unit_target (the price this timeframe is judging now — NOT the take-profit); units (the targets judged together, max 6, primary first); reverse_pending (a reversal on hold: the first reversing key appeared, the next judgment bar has not closed beyond the target); standing (the last confirmed signal's entry/stop/target while a new target is being selected); prev_signal; turn (reverse|same|null); levels (nearby prices). state_text = ready-to-show Korean lines (🟢▲ buy confirmed · 🔴▼ sell confirmed · ⚪ pending · 🟡 target selected / reversal on hold · ✖️ failed). timeframe_summary lists timeframes by (stage, side) — a listing, not a verdict; no scores, weights or probabilities anywhere. events = recent target_selected / signal / signal_resolved / reverse_failed / reverse_tested / conn_arrival, newest first, always including each timeframe's own latest 2 (pass `timeframe` for one timeframe's full history). as_of = the latest closed bar among the returned timeframes (it can be earlier than get_assembly.as_of, which is the 30m bar). Read as persisted (no recompute). A state reading, NOT a trade instruction. Crypto and Hyperliquid synthetics only (KRX: decker.get_reading). Before placing any order, check the intent with decker.validate_intent.

Parameterssymbolrequiredtimeframetimeframesevents_limit

decker.get_view

Ready-to-show Korean status card for a symbol — the same card the daily briefing sends, built from the same consumer contract (CR1) as decker.get_market_state, so direction and prices always agree with it. Shows the timeframes grouped 상위/중간/단기 with one line each (direction + stage + the price that decided it), the nearby prices to watch, and a short explanation of the chosen timeframe (tf, default 4h): what closed beyond what, whether the signal flips the previous one, entry/target/stop. Also returns direction (+/- only while that timeframe's signal is pending or confirmed; a failed or absent signal gives no direction — failure does not assert the opposite side), wait_target, invalidation, ref_price and recent self-scoring verdicts. Use this when you want text to show as-is; use decker.get_market_state when you want structured values to reason over. layer=STATE_VIEW: a market-state reading, NOT a trade instruction. Before placing any order through any execution tool, check the intent with decker.validate_intent.

Parameterstfsymbolrequired

decker.get_reading

How ONE timeframe looks right now, in plain language: state (phase, this timeframe's key direction, posture GO/WATCH/HOLD — a stance, not an order), mtf.by_tf (the same for other timeframes), narrative, plus `assembly` = the symbol's single verdict (the same one decker.get_assembly returns: direction, action 진입/유지/청산/대기, entry/stop/target). ⚠ `state.direction` is only this timeframe's direction and can differ from `assembly.direction` — for the decision use `assembly` (direction_basis says which is which). For the full detail call decker.get_assembly with detail=true; for the structured per-timeframe judgment use decker.get_market_state. Engine-native raw fields are not exposed here.

Parameterstfsymbolrequiredinclude_tfs

decker.get_signals

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. Before placing any order through any execution tool, check the intent with decker.validate_intent.

Parameterslimitsymbolstimeframeaction_gatemin_progress

decker.get_episodes

Price-axis EPISODE history — answers 'where did I buy/sell last time, what was the target value and the event chain then, and where did price move WITHOUT a signal (and which target values it passed = missing points)'. Read-only from the persisted event ledger (no recompute). `episodes` (newest first) = one target selection until the next: target {price, from_price, reason}, chain (primary-unit judgment events), signals {ts, side, entry, targets, resolved{status, close, bar_low, bar_high}}, left (target_left: MISSING = a target value price passed through with no judgment; MOVED), missing, signal_gap (no signal in that episode), move {start_close, end_close, pct}. `signal_gaps` (ascending) = the interval between consecutive signals with its price move and the missing points inside (last one is open). Missing points carry `sign` and `position` (price below/above the target at the pass) — classify on the read side; do not re-decide coordinates. History starts at the first persisted event of this generation.

Parameterslimitsymbolrequiredtimeframerequired

decker.get_trigger_history

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.

Parameterslimitsincesymbolrequiredtimeframe

decker.get_positions

Axis③ (Order/Execution) — this user's actual exposure (each open row carries vs_verdict: does the held side match the current symbol verdict, plus `knots` = the decision prices nearest to the price above and below, with which timeframes sit on each — the ORDER in which transactions would be reached, not a probability; `exit_levels` only when the held side matches): 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.

Takes no parameters.

decker.validate_intent

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 tf_signal_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). READ verdict_check FIRST: it compares the intent with the symbol's single verdict (the same one decker.get_assembly returns — direction, action 진입/유지/청산/대기, entry/stop/target, what would change it) and says in summary_ko whether a NEW entry exists now (entry_now) or the stance is only being held. The timeframe-level gate/signal fields below describe one timeframe (default: your open position's) and can be stale.

Parameterssiderequiredsymbolrequiredtimeframeorder_type

decker.get_user_skills

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. Also returns symbol_skills: the symbols where this user's paper account turns the symbol verdict's entry event into an order (read-only here; turn on/off via REST /auto-order-rules/symbol-skills).

Takes no parameters.

decker.set_skill_overlay

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

Parametersskill_idrequired

decker.place_order

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.

Parameterssiderequiredsymbolrequirednotional_usdrequired

decker.close_position

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.

Parameterssymbolrequiredclose_fraction

decker.update_protective_stops

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.

Parametersmodesymbolrequiredsl_pricetp_price

Version history

1
  1. v1.10.0LatestSep 16, 2026

Score

100% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 daysRequired25 pts
  • Auth declaredRequired10 pts
  • Tools listedRequired15 pts
  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts