Decker

io.github.gigshow由 GitHub 账号 gigshow 发布v1.10.0更新于 Oct 27, 2026

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

已验证Streamable HTTP可网页运行金融AI 与机器学习

概览

AI 生成的概览

Decker 是一个远程 MCP 服务器,提供面向加密货币与韩股的确定性市场状态引擎,让助手获取判断、信号、持仓并执行下单。

可以做什么
  • 读取单个标的的结论与各周期市场状态,以及自然语言解读和可直接展示的状态卡片
  • 列出带入场、目标与止损的活跃交易信号,并查询历史触发表现与价格事件记录
  • 查看当前持仓与敞口,并在下单前校验拟议订单意图
  • 切换当前生效的交易技能叠加层并列出可用技能
  • 通过 Decker 自有引擎下市价单、平仓或减仓,并修改止损与止盈
适用场景
当助手需要针对受支持的加密货币交易对或韩股获得结构化、可复现的市场状态与交易坐标时适用;也适用于希望先做下单前校验、再通过 Decker 引擎执行交易的场景。
运行要求
远程 Streamable HTTP 端点(位于 API 主机的 MCP 路径);需在 X-API-Key 请求头中提供 Decker API 密钥(有免费额度,可在网页设置或通过 Telegram 获取)。不支持远程服务器的客户端需借助 mcp-remote 桥接并安装 Node/npx。付费档位可提高每日调用上限并解锁交易执行。
安装前请注意
API 密钥属于凭据,不应写入共享配置。多个工具会动用资金:place_order 与 close_position 通过 Decker 自有引擎执行而非你的券商账户,update_protective_stops 会改动现有持仓的风险价位;set_skill_overlay 会立即影响后续信号。免费档为只读并带一天缓存。输出仅为市场信息,不构成投资建议。

安装

在 SourceWeft 中

  1. 打开 控制台中的 Decker,将其添加到工作区。
  2. 连接 X-API-Key 凭据。它们会被私密存储,绝不会在公开页面上展示。
  3. 为需要使用其工具的对话启用该服务。

Web executable,通过 Streamable HTTP。 远程服务在工作区中配置后即可从网页运行时运行。

交给智能体安装

把这段提示词粘贴到 Claude Code、Codex、Cursor 等智能体,或 SourceWeft 对话中。智能体会读取该服务器的安装指南,先向你展示发布者、端点和登录方式,经你同意后再把它添加到你的客户端。密钥不会写进任何命令。

阅读 https://sourceweft.com/mcp/io.github.gigshow%2Fdecker/install.md,并按其中说明把这个 MCP 服务器接入我的客户端。修改任何配置之前,先告诉我它的发布者、端点和登录方式,等我确认。不要把 API 密钥写进命令或我会提交的文件;问我密钥应从哪里获取。

查看智能体所依据的安装指南

其他 MCP 客户端

把它添加到你客户端的 mcpServers 配置中。

{
  "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.

来源:README.md,提交 b3f4fd2

工具

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: 정렬

输入参数detailsymbol

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.

输入参数symbol必填timeframetimeframesevents_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.

输入参数tfsymbol必填

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.

输入参数tfsymbol必填include_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.

输入参数limitsymbolstimeframeaction_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.

输入参数limitsymbol必填timeframe必填

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.

输入参数limitsincesymbol必填timeframe

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.

无需输入参数。

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.

输入参数side必填symbol必填timeframeorder_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).

无需输入参数。

decker.set_skill_overlay

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

输入参数skill_id必填

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.

输入参数side必填symbol必填notional_usd必填

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.

输入参数symbol必填close_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.

输入参数modesymbol必填sl_pricetp_price

版本历史

1
  1. v1.10.0最新Sep 16, 2026

评分

已满足适用检查项的 100%

该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。

  • 近 30 天内可连通必需25 分
  • 已声明认证方式必需10 分
  • 已列出工具必需15 分
  • 描述必需15 分
  • 图标10 分
  • 文档15 分
  • 许可证10 分