Deterministic market-state engine for trading agents — zero LLM in the signal path. 8 tools: structural market state & phase, action gate (GO/WATCH/HOLD) as a transition posture, entry/target/invalidation coordinates, bar-by-bar state timeline, composed view cards, and pre-trade intent validation. Every output traces to a bar-stamped ledger with a public daily self-scoring track record (misses included). Crypto + TradFi synthetics (gold, oil, S&P 500, Tesla, NVIDIA, KOSPI 200).
Scored across 15 tools
The read-side tools (decker.get_assembly, get_market_state, get_reading, get_view, get_signals, get_trigger_history, get_episodes) all answer variations of 'what is happening on this symbol', and their boundaries are only differentiated by extremely long prose rather than by self-evident purpose. The descriptions do explicitly instruct which to use when (verdict vs structured vs text card vs history), which prevents true 1-2 level confusion, but an agent must read carefully to avoid misselection.
Every tool follows a clear verb_noun snake_case pattern (get_*, set_*, place_order, close_position, update_protective_stops, validate_intent), with a consistent decker. namespace. No mixed conventions or camelCase leakage.
15 tools is at the upper end of the comfortable range but reasonable for a trading engine with state, signals, positions, execution, and skill configuration. The count is slightly inflated by closely related read variants that could arguably be consolidated.
Covers the core lifecycle: state reading, signal/history inspection, intent validation, order placement, position closing, protective stop modification, and skill configuration. Minor gaps exist (no account/balance/margin query, no explicit order history separate from positions), but the main workflows are closed.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | e.g. BTCUSDT, XYZ_GOLDUSD — whatever symbol you hold. Aliases resolve like other tools. | |
| close_fraction | No | Fraction of the current position to close, 0 < x <= 1. Default 1.0 = full close. E.g. 0.5 closes half. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: it uses DECKER's execution engine, looks up actual positions (real or virtual), handles mixed positions, and returns a response with execution_mode. It also states the not-found behavior, going beyond what annotations could provide.
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 detailed and every sentence conveys useful information, but it is somewhat verbose with parentheticals and cross-references. It could be tightened slightly without losing the transparency, but it remains well-structured and front-loaded with the primary purpose.
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?
The description covers most aspects: purpose, restrictions, mode selection, mixed positions, and edge cases. The only minor gap is that it doesn't explicitly describe how close_fraction applies when both real and virtual positions exist (e.g., does it close half of each or apply only to one). This is a small ambiguity given the otherwise thorough coverage.
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?
The input schema provides full descriptions for both parameters (symbol and close_fraction), and the description reiterates that closing can be partial, but adds no new parameter-level details beyond what the schema already states. Given the 100% schema coverage, a baseline score of 3 is appropriate.
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 identifies the action: closes or partially reduces an existing position. It distinguishes itself from sibling tools like place_order by stating it is for closing, not opening, and notes the absence of the crypto-6 restriction. The statement 'No open position for the symbol = a clean not-found response' further clarifies the tool's scope.
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?
The description explains when to use this tool: to close positions, and contrasts it with place_order, noting which restrictions apply. It explicitly says it is safe to call speculatively when no position exists, and mentions the account-linkage requirement for real positions. This is clear, actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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: 정렬 aligned | 되돌림 pullback against the frame | 전환 시험 frame under test | 재장전 no confirmed signal. Caveats: 정렬 does not mean every timeframe's gate is GO (check matrix_summary[].gate); entry.mode '지금' does not mean a new event this bar. Narrate or filter the result — do not re-decide coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Include path / watch / story / ladders / matrix_summary (about 20KB per symbol). Default false: the answer only. | |
| symbol | No | Optional symbol or alias (BTC, 비트코인, GOLD, 테슬라...). Omit for all 14 symbols. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly: it explains that there are no scores or weights, what each action means, what reason/until convey, why target may be null, how rr mixes timeframes, approximate response sizes, and caveats such as 정렬 not implying every gate is GO. It also warns not to re-decide coordinates.
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 front-loaded with the core verdict purpose and then structured into a numbered reading order and a default-vs-detail explanation. It is dense and lengthy, but most content is relevant for a complex decision tool; the only weakness is that some caveats and interpretive notes make it heavier than necessary.
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?
There is no output schema and no annotations, so the description must explain the result shape and semantics; it does this in detail, covering verdict, summary_ko, entry/stop/target/rr, as_of, and the structured detail fields. For a complex multi-timeframe decision tool with two optional parameters, it is complete enough for correct invocation and interpretation.
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 already 100%, but the description adds substantial meaning beyond the schema: detail=true is expanded into path/watch/story/ladders/matrix_summary/tf_states/knots, and omitting symbol is clarified as returning all 14 symbols. It also gives examples of symbol aliases and relative payload sizes.
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 states a specific verb-and-resource purpose: 'one verdict per symbol' answering 'what is the situation and what do I do on this symbol now,' built from per-timeframe judgment state. It distinguishes the tool from raw-signal or market-state siblings by emphasizing a single verdict with action semantics and explicitly saying 'no scores or weights.'
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?
It gives explicit usage instructions: read in a numbered order, default vs detail=true, omit symbol for all 14 symbols, and interpret action labels like 진입/유지/청산/대기. However, it does not explicitly name sibling tools or say when to use one of them instead, so the alternatives guidance is implicit rather than complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | number of episodes | |
| symbol | Yes | e.g. BTCUSDT | |
| timeframe | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose key traits: 'Read-only from the persisted event ledger (no recompute)' and 'History starts at the first persisted event of this generation.' That is genuinely useful behavioral context. It omits permissions, latency, and ordering trade-offs beyond newest-first, so not a 5.
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 purpose is front-loaded, but it then collapses into a dense, jargon-heavy run-on string with backtick field lists that is hard to parse. Every element is arguably informative, but the lack of paragraphing or ordering hurts 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?
Since there is no output schema, the description appropriately spends its space documenting the return shape (episodes, targets, chain, signals, missing points, signal_gaps, sign/position). It is largely complete for an agent to interpret the result. A modest gap remains around how `limit` interacts with the two returned collections.
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 67% and the description adds essentially no parameter guidance — it never mentions `limit`, `symbol`, or `timeframe`. The schema documents symbol, timeframe enum, and limit bounds/default, so the baseline of 3 is appropriate, but the description does nothing to compensate for the undocumented fraction.
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?
States a specific verb-equivalent and resource: 'Price-axis EPISODE history' with two named collections (`episodes`, `signal_gaps`). It goes well beyond restating the name by describing the conceptual content (target selections, chains, signals, missing points). It does not explicitly differentiate itself from siblings like get_signals or get_trigger_history, which keeps it at 4.
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?
The framing question ('where did I buy/sell last time...') implies when the tool is useful, giving implied usage context. However, it never states when to use this versus the many sibling read tools (get_signals, get_trigger_history, get_state_timeline), and gives no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | e.g. BTCUSDT, XYZ_GOLDUSD | |
| timeframe | No | Alias for a single-element `timeframes` (backward compatible). | |
| timeframes | No | Subset to return. Omit for all timeframes. | |
| events_limit | No |
| Name | Required | Description |
|---|---|---|
| as_of | Yes | 가장 최근 평가 봉의 마감 시각 |
| price | Yes | 가장 최근 평가 봉의 종가 |
| events | Yes | 최근 사건(새것 먼저). 대상선정·신호·신호 결말·추세 변경 안 됨(reverse_failed: 1순위 대상의 반전이 실패한 판정 결과, side = 유지되는 추세 쪽 — 신호 아님)·반전 테스트(reverse_tested: 1순위 대상의 반전 첫 키 결과, status beyond|short — 신호 아님)·이전 판정 가격 도달(conn_arrival: 가격이 이전에 판정이 끝난 기준 가격에 닿음 — 방향·결말 판정 아님). |
| ladder | No | 현재가 위·아래 가까운 순서로 각 8개. 같은 가격은 한 점이고 at 에 그 가격이 어느 시간대에서 어떤 역할인지(kind) 모두 나열된다 — 하위 시간대가 닿는 가격이 상위 시간대의 대상·후보·신호봉 경계이면 그 한 사건이 두 시간대의 사건이다(상위는 하위의 조각이 모여 만들어진다). signal_edge.edge: confirm=그 방향 확인 경계 · fail=반대(실패) 경계. reads=그 칸의 사건 문장(역할→사건 표) + 그 시간대의 다음 마감 시각(판정은 종가). 우세·점수 없음 |
| symbol | Yes | |
| state_text | No | 사용자에게 그대로 보여 줄 수 있는 현재 상태 문면 — 상위·중간·단기로 묶어 시간대마다 방향+단계, 마지막에 주목 가격. 해석·전망 문장은 없다(그건 호출자 몫). 시간대 행이 없으면 null |
| timeframes | Yes | 상위→단기 순. 각 시간대가 낸 상태를 나란히 — 시간대 간 종합 판정은 없다(종합은 호출자 몫). |
| timeframe_summary | No | 시간대 행을 단계(confirmed 확인·pending 판정보류·failed 실패)와 방향(buy·sell)별로 나열만 한다. 우세·점수·투표 없음 — 실패는 반대 방향을 뜻하지 않는다. target_selected = 대상선정 중인 시간대 목록 |
| missing_timeframes | Yes | 아직 평가값이 없는 시간대 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and mostly does: it states data is 'read as persisted (no recompute)', that there are 'no scores, weights or probabilities anywhere', and that timeframe_summary is 'a listing, not a verdict'. It also flags that as_of can precede get_assembly.as_of and that target falls back to null + target_reason. It stops short of stating authorization or rate-limit behavior, so 4 rather than 5.
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 purpose and routing are front-loaded, which is good, but the long parenthetical enumeration of output fields (stage, side, signal_bar, entry, stop, target, unit_target, units, reverse_pending, standing, prev_signal, turn, levels) largely restates what the output schema already declares. Useful vocabulary, but it bloats a single paragraph and hurts scannability.
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 an output schema exists, the description still supplies the semantic caveats an agent needs: state_text legend, target vs unit_target distinction, event inclusion rules, as_of semantics, and the crypto/Hyperliquid-only market scope. Nothing material for correct invocation appears missing.
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 75%, and the description adds meaning the schema doesn't: `timeframe` is explained as the key to one timeframe's full event history, and `timeframes` is framed as a subset selector. events_limit is covered only indirectly via the 'latest 2' default rule.
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?
Opens with a specific verb+resource+scope: 'PER-TIMEFRAME judgment state of a symbol, structured'. It explicitly positions itself relative to siblings, describing itself as 'the evidence behind decker.get_assembly's single verdict', so an agent knows exactly what this returns and what it does not.
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?
Gives explicit routing: call decker.get_assembly first for 'what is the situation and what do I do', use this for one timeframe's exact state. Also names exclusions and alternatives — 'KRX: decker.get_reading' and 'Before placing any order, check the intent with decker.validate_intent'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the full behavioral burden and does so well: it explains the real vs. virtual modes, live sl_price/tp_price, vs_verdict, knots, the order-not-probability distinction, and when exit_levels appear. This is substantially more than the structured fields provide.
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 content is useful and front-loaded with the core resource, but the first sentence is extremely dense and packed with parentheticals. It earns most of its length given the lack of an output schema, though readability could be improved.
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 zero-parameter read tool with no annotations and no output schema, the description supplies the return categories, mode distinctions, and interpretation cues needed to call and understand it. Nothing critical appears missing.
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?
The tool has zero parameters, so there is no parameter semantics to document. The baseline for a zero-parameter tool is 4; the description does not need to compensate for missing parameter documentation.
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 names the resource precisely: real open futures positions, virtual paper positions, and the last 10 closed round-trips per mode. It also explicitly distinguishes itself from decker.get_signals, so an agent can identify its scope without opening the empty schema.
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?
It gives concrete when-to-use guidance: check before placing another order to avoid duplicate/over-exposure, and inspect live protective stop/target on a real position. It also names the relevant alternative (decker.get_signals) and explains the difference in purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| tf | No | 4h | |
| symbol | Yes | e.g. BTCUSDT | |
| include_tfs | No | Comma-separated additional TFs (e.g. '1h,4h,1d'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full burden — and it does meaningful work: it names the returned fields, states it is a plain-language read of the current moment, warns that state.direction can diverge from assembly.direction, and declares 'engine-native raw fields are not exposed here.' It does not mention auth or rate limits, but the output-shape and caveat disclosure is well above baseline.
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?
Front-loaded with what the tool does and every clause carries information (field inventory, the assembly shortcut, the direction caveat). It is dense and parenthesis-heavy, but there is no filler sentence to cut.
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 and no annotations, so the description has to explain returns — which it does (state, mtf.by_tf, narrative, assembly fields and their meanings), plus a key interpretive pitfall. Missing only peripheral details like pagination or the symbol format, which the schema's example covers.
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?
With 67% schema description coverage the schema documents symbol and include_tfs, and tf is enum-constrained. The description gestures at parameters conceptually ('this timeframe', 'the same for other timeframes'), which loosely maps to tf and include_tfs, but adds no syntax, defaults, or usage detail beyond the schema, so 3 is the right baseline.
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?
States a specific verb-like operation ('how ONE timeframe looks right now, in plain language') and enumerates the payload (state, mtf.by_tf, narrative, assembly). It explicitly differentiates itself from decker.get_assembly and decker.get_market_state, so an agent can pick it without opening either schema.
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?
Gives explicit routing: use decker.get_assembly with detail=true for full detail, decker.get_market_state for the structured per-timeframe judgment. It also gives a when-not/interpretation rule ('state.direction is only this timeframe's direction ... for the decision use assembly').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| symbols | No | Symbol filter (e.g. ['BTCUSDT','ETHUSDT']). Omit for all. | |
| timeframe | No | Signal horizon filter (30m=scalp, 1h=swing, 4h/8h/1d=position). The same symbol can hold OPPOSITE directions on different horizons — omit to get the latest active signal regardless of horizon (its timeframe field says which one you got; when a specific symbols[] was requested, a row's other_horizon_conflict field flags it if another horizon is ACTIVE with the opposite direction). Prefer decker.get_assembly for the composed cross-horizon judgment instead of guessing which horizon to pass here. | |
| action_gate | No | Engine action gate filter (3-layer grammar: gate = transition posture, not an order command). Rows where the engine emitted no gate for this bar (effective_action_gate null, e.g. KRX daily) are excluded when this filter is set. | |
| min_progress | No | Minimum progress_pct (0-100). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it does so well: it discloses the turn-retention policy (aged signals are retained, not cut), that is_actual_trigger=true only for ENTER while WAIT/SKIP are unexecuted candidates, that action_gate is a stance not an order command, and that risk_reward_ratio is computed on post-overlay displayed coordinates. It does not state read-only/side-effect profile or rate/limit behavior, so it falls short of a 5.
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?
Front-loaded with the payload shape before the caveats, and nearly every clause carries operational information (freshness policy, gate semantics, sibling routing). It is dense but slightly overpacked in a single block, with the action_gate 'stance not order command' point echoed in both the description and the schema.
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?
With no output schema and no annotations, the description compensates fully: it enumerates the returned fields (coordinates, decision, action_gate posture, progress, MTF verdict, summary_ko, risk_reward_ratio, freshness_state, age_bars, freshness_sec) and explains the retention/freshness caveat needed to interpret old rows correctly.
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 80%, so baseline is 3, and the description adds real semantic weight beyond the schema: the action_gate filter operates on the current-moment representative state rather than history, and freshness_state/age_bars/freshness_sec must be consulted before treating a PENDING row as current. It adds meaning to how filter results should be interpreted rather than just restating parameter names.
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?
States a specific verb+resource (active trading signals for the current user, with Skill Overlay applied) and immediately characterizes the returned shape (coordinates, decision, action_gate, progress, MTF verdict, summary_ko). It is clearly distinguished from decker.get_trigger_history, decker.get_assembly, and decker.get_engine_state_raw by name.
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?
Explicit routing: action_gate filtering does NOT search history and 'almost always' returns 0 rows, so past GO events should go to decker.get_trigger_history; cross-horizon judgment should use decker.get_assembly; any order should be preceded by decker.validate_intent. This is textbook when/when-not/alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| since | No | ISO8601 lower bound on trigger time (exclusive). Optional. | |
| symbol | Yes | e.g. BTCUSDT | |
| timeframe | No | Optional — omit for all timeframes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that results are historical triggers with realized performance fields (mfe_pct/mae_pct/exit_reason/exit_price) and null for open positions. It also flags the direction vocabulary nuance (long/short vs +/–), which is a non-obvious behavioral trait. Lacks explicit statements about read-only nature or pagination, but 'get' + context implies non-mutating, and the field detail adds strong transparency.
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?
Dense but well-organized. It front-loads the core distinction, then contrasts with the sibling, then details output fields and vocabulary. Could be tightened slightly but every clause contributes meaning — no fluff.
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 history tool with no output schema, the description covers the essential output semantics (entry/target/stop, performance metrics, null meaning) and the key vocabulary trap (direction). It omits details like sort order or empty-result behavior, but these are minor for the tool's purpose. It adequately equips an agent to call and interpret the result.
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 description coverage is 75% (limit lacks a description). The tool description adds no parameter-specific detail beyond the schema, so it does not compensate for the missing limit description. Baseline of 3 is appropriate since the schema already covers the other three parameters well.
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?
Precisely states the resource (actual historical GO triggers for a symbol) and the verb (get). Explicitly contrasts with get_signals to eliminate ambiguity, and clarifies it is on the 'ACTION axis', distinguishing from WATCH/HOLD candidates. It answers 'what' and 'when' with concrete fields.
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?
Directly states the intended use case ('what did the engine actually trigger recently and at what price') and explicitly says get_signals/get_market_state cannot answer that. Names the alternative sibling and explains why it is different, leaving no ambiguity about when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 (turn on/off with decker.set_symbol_skill or REST /auto-order-rules/symbol-skills).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the burden and does disclose the payload shape: 8 named published skills, the user's selected one, and the precise semantics of symbol_skills (symbols where the paper account converts a symbol verdict's entry event into an order). It omits permission/rate-limit behavior and does not explicitly state the call is side-effect free, though the 'get_' naming and read-only framing make that clear in practice.
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 the headline ('Trading skill catalog + currently active overlay'), then the detail on symbol_skills. The inline enumeration of all eight skill ids is slightly listy but earns its place as the actual return values an agent will see.
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?
There is no output schema, so the description must convey return values and it does so concretely (named skills, active selection, symbol_skills semantics). It leaves the meaning of the individual skill profiles (conservative_v0 vs scalp_v0 etc.) unexplained and says nothing about staleness or account scoping, which keeps it from a 5.
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?
The tool takes zero parameters, so there are no parameter semantics to convey; the baseline for a 0-param tool is 4. The description spends its space on outputs instead, which is the right allocation.
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 opens with a specific verb-like summary ('Trading skill catalog + currently active overlay for this user') and enumerates exactly what is returned, including the 8 skill ids and the symbol_skills list. An agent can distinguish this read-only catalog/overlay lookup from mutation siblings like decker.set_skill_overlay and decker.set_symbol_skill without opening any schema.
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?
It implies when to use it (reading the user's skill catalog and active overlay) and explicitly routes mutation intent elsewhere, naming both decker.set_symbol_skill and the REST /auto-order-rules/symbol-skills endpoint for toggling symbol skills. It does not state exclusions for the skill overlay itself (i.e. which sibling sets that), so it falls short of a full when/when-not statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| tf | No | Optional view timeframe — the grounded narrative is composed on this TF's bar (e.g. '1h' when the user asks about the 1-hour picture). Omit for the engine's default action TF (usually 4h, same as the daily briefing card). | |
| symbol | Yes | e.g. BTCUSDT, XYZ_GOLDUSD (crypto + HL TradFi synthetics; KRX daily lineage not yet covered by view v1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full burden, and it does so well: it defines layer=STATE_VIEW ('a market-state reading, NOT a trade instruction'), explains that direction is only +/- while a signal is pending/confirmed and that failure asserts nothing, and lists the returned fields. It stops short of stating read-only/permission behavior explicitly, so not a 5.
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?
Front-loaded with the deliverable and the sibling distinction before the field list, and every sentence carries content (consistency guarantee, output fields, layer, prerequisite). It is on the dense/long side for a 2-parameter view tool, which keeps it from a 5.
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?
With no output schema, the description compensates by enumerating the returned fields (direction, wait_target, invalidation, ref_price, self-scoring verdicts) and the card layout. Coverage of error/edge behavior and unsupported-symbol handling is left to the schema, so it is strong but not exhaustive.
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% and both parameters are documented in the schema, so the baseline is 3. The description restates the tf default (4h) and the grouping semantics but adds no syntax or format detail beyond what the schema already provides.
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?
States a specific deliverable ('Ready-to-show Korean status card for a symbol') and pins down its scope by naming the sibling it mirrors (decker.get_market_state via the shared CR1 contract). An agent can tell instantly that this returns a rendered card rather than raw values.
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?
Explicit routing rule: 'Use this when you want text to show as-is; use decker.get_market_state when you want structured values to reason over.' It also adds a cross-tool prerequisite ('Before placing any order through any execution tool, check the intent with decker.validate_intent').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| side | Yes | Order direction (buy/long or sell/short). | |
| symbol | Yes | Crypto-6 only for this MCP write path. | |
| notional_usd | Yes | Order size in USD (quantity = notional_usd / current price). This is the value checked against the account's tier notional cap. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral disclosure burden. It reveals that orders execute via Decker's own engine, not the user's broker, that execution_mode is resolved server-side with real trading gated by opt-in, eligibility, and hard caps, and that the response states actual mode. It also discloses position netting behavior and pre_existing_position, going well beyond basic write-side transparency.
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 long but highly dense; every sentence adds a needed caveat or constraint (mode resolution, cap checks, symbol whitelist, validate_intent dependency, netting). The opening distinguishes it immediately from siblings. A bulleted structure might improve scannability, but the content earns its length for a high-risk money-moving tool.
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 no output schema and no annotations, the description is remarkably complete. It covers prereqs (validate_intent), restrictions (crypto-6 only), execution semantics (server-side mode, caps), response behavior (authoritative mode, pre_existing_position), and downstream actions (close_position closes combined total). It leaves no major operational question unanswered.
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, but the description adds meaningful layer: it explains notional_usd is the value checked against tier notional cap and defines quantity as notional/price. It also flags that execution_mode is not a caller-chosen parameter, preventing a likely misuse. This compensates for any schema brevity.
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 places a market order through Decker's own execution engine, explicitly distinct from every sibling tool ('unlike every other tool here, this one moves money'). It names the resource (orders) and the action (places a market order), making the purpose unambiguous.
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?
The description provides explicit when-to-use guidance: it contrasts with other tools, instructs calling decker.validate_intent first ('this tool does not check it for you'), and notes that HL-synthetic and KRX symbols are read-only via other tools. It also references close_position for later closing combined positions, giving clear operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change active trading skill overlay for this user. Immediately affects all subsequent get_signals calls and downstream channels.
| Name | Required | Description | Default |
|---|---|---|---|
| skill_id | Yes | trading_skills.id (e.g. 'aggressive_v0'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the change is immediate and affects downstream channels, which is useful. However, it does not mention whether the change is reversible, if it overrides existing settings, or any permission requirements, leaving gaps.
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 the action verb. Every word earns its place; no redundancy or 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?
For a simple one-parameter setter, the description covers the core function and its immediate consequences. It lacks details about error conditions or prerequisites, but given the simplicity and single parameter, it is nearly complete.
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?
The schema already provides 100% coverage for the single parameter skill_id, including a description and example. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
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 verb 'change' and the resource 'active trading skill overlay for this user', which distinguishes it from sibling getters. It is specific and unambiguous.
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?
The description explains the immediate effect on subsequent get_signals calls, providing clear context for when this tool is relevant. However, it does not explicitly mention alternatives or when-not-to-use scenarios, though the sibling set of getters makes the use case obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn the per-symbol integrated skill on or off for this user's PAPER (virtual) account — real accounts are refused. When on, the symbol verdict's entry event (decker.get_assembly) opens a paper order and the same verdict's exit / opposite-entry events close it; per-timeframe rules never close a position this skill opened. Defaults: paper notional quantity, engine stop/target. replace_timeframe_rules=true pauses this user's paper per-timeframe rules for the symbol (the response's paused_rule_ids restore them via enabled=false + restore_rule_ids). Current state: decker.get_user_skills → symbol_skills.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | e.g. BTCUSDT, XYZ_GOLDUSD (a symbol with an engine verdict). | |
| enabled | Yes | true = on (idempotent), false = off (rule kept, paused). | |
| quantity | No | Optional order size. Omitted = paper default notional. | |
| against_frame | No | Also order lower-timeframe pieces opposite to the symbol frame (default off). | |
| restore_rule_ids | No | With enabled=false: re-activate these paused per-timeframe rules. | |
| replace_timeframe_rules | No | Pause this user's paper per-timeframe rules for the symbol (default false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses the paper-only guardrail, the exact order lifecycle triggered by verdict entry and exit/opposite-entry events, the fact that per-timeframe rules never close a skill-opened position, defaults for quantity and stops, and the pause/restore interaction with replace_timeframe_rules and paused_rule_ids.
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 dense but efficient paragraph: the primary action and paper-only restriction are front-loaded, and every subsequent clause adds operational meaning about order lifecycle, defaults, rule pausing, and state retrieval. There is 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?
For a six-parameter mutation tool with no annotations and no output schema, the description is complete enough to call correctly: it covers the account restriction, event-driven behavior, defaults, rule interactions, and how to inspect current state. It even mentions the response field paused_rule_ids, compensating for the missing output schema.
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 description coverage is already 100%, so the baseline is 3. The description still adds meaningful semantics beyond the schema: it explains that enabled=true is idempotent, that omitting quantity falls back to the paper default notional, and how replace_timeframe_rules and paused_rule_ids interact with restore_rule_ids.
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 states a specific verb and resource: turning a per-symbol integrated skill on or off for the user's PAPER account, with real accounts explicitly refused. It references related tools (decker.get_assembly for entry events, decker.get_user_skills for current state) but does not explicitly distinguish itself from the nearby sibling decker.set_skill_overlay, so it falls short of full sibling differentiation.
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?
It clearly explains the operational context: this only affects paper accounts, enabling opens paper orders from verdict entry events, disabling pauses the skill, and current state should be checked via decker.get_user_skills. It does not give explicit when-not-to-use guidance versus decker.set_skill_overlay, but the paper-only constraint and state-lookup pointer provide strong usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Only required when both a real and a virtual position are open for this symbol — says which one to modify. | |
| symbol | Yes | e.g. BTCUSDT — must be a symbol you currently hold. | |
| sl_price | No | New stop-loss price. Omit to leave the current stop unchanged. | |
| tp_price | No | New take-profit price. Omit to leave the current target unchanged. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and excels: it details real-mode ordering (new order first, old canceled after, no unprotected window), virtual-mode direct column updates, and the rejection behavior for ambiguous mode.
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 dense but every sentence provides essential information: purpose, real vs virtual behavior, parameter rules, and mode requirement. It is front-loaded with the main purpose and avoids redundancy, making the length justified.
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 tool's complexity (real/virtual modes, order of operations, dual-position ambiguity), the description covers all critical aspects a caller must know. It is self-sufficient for an agent to invoke correctly without needing output schema details.
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?
Though schema coverage is 100%, the description adds crucial semantics: the 'at least one' constraint, that omitted side is left unchanged, the symbol must be currently held, and mode is required only in dual-position scenarios—all beyond the schema's simple field 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 states the tool 'modifies the stop-loss and/or take-profit on an EXISTING open position', using a specific verb and resource. It also distinguishes itself from siblings by explaining why there is no cancel_order tool and that this fills the gap of modifying protective stops.
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?
The description explicitly says this is for modifying stops on an existing position, contrasts with market-order placement, and provides concrete rules: provide at least one of sl_price/tp_price, and pass mode when both real and virtual positions exist, otherwise the call is rejected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| side | Yes | Proposed order direction (buy/long = +, sell/short = -). | |
| symbol | Yes | e.g. BTCUSDT, SILVER, 테슬라 — aliases resolve to the engine symbol (XYZ_SILVERUSD, XYZ_TSLAUSD, …). | |
| timeframe | No | Gate horizon. Omit = your open position's entry TF if you hold one on this symbol, else decker.get_assembly's entry TF (the single judgment authority's current best-path TF), else the engine's default action TF (4h). | |
| order_type | No | Optional, informational (market/limit/…) — recorded in the ledger, does not change the state verdict. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers: it is a read-only stance reading, NOT an approval/rejection, with explicit semantics for covered=false (unknown, not HOLD), null action_gate (with two distinct gate_null_reason meanings), staleness caveats, and a persisted check_id ledger. This is far beyond what a bare mutation/read hint would give.
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?
Front-loaded with the core purpose and timing, but the body is a dense run-on of nested parentheticals (gate_null_reason, covered semantics, verdict_check recap) that could be tightened. It mostly earns its length given the behavioral burden, but readability suffers.
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, so the description must explain returns and it does comprehensively: the response vocabulary (engine gate + tf_signal_alignment), the null/covered edge cases, and the relationship to decker.get_assembly's verdict. An agent has everything needed to interpret results without additional tooling.
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 the schema already documents all four parameters, establishing a baseline of 3. The description references 'symbol + side' and the timeframe-level gate/signal fields but adds no syntax or format detail beyond 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?
States a specific verb+resource ('Pre-trade gate check for a proposed order intent') and clearly distinguishes itself from execution siblings (place_order) and read siblings (get_market_state) by framing itself as a pre-placement gate rather than an order command. An agent can tell it apart from get_reading or get_signals without opening schemas.
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 when to call ('BEFORE placing any order through any execution tool') and gives an ordering instruction ('READ verdict_check FIRST'). It describes the interaction with an external review→place flow, leaving no ambiguity about sequencing relative to the execution path.
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.
decker.set_symbol_skilldecker.get_market_state3 fields changedOutput schema / properties / timeframes / items / properties / edge_break_atAdded value: +{
+ "description": "근거 붕괴 시각 — 확인된 신호의 종가가 신호봉 반대 경계를 처음 이탈한 봉(그 봉의 행동 = 청산). 이 값이 있으면 다음 봉부터 이 신호의 입장은 없다(입장 종료, 용어 대장 §근거 붕괴·입장 종료). 가격이 경계 안으로 돌아와도 되살아나지 않는다. 없으면 null",
+ "format": "date-time",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / timeframes / items / properties / units / descriptionPrevious value: -"이 시간대가 **함께 보고 있는 대상 목록**(최대 6, 1순위 먼저). 한 시간대에서 대상은 하나가 아니다 — 1순위가 판정 중이어도 이전부터 있던 다른 대상이 터치되면 보조 유닛으로 각자 판정한다(수평·수직). unit_target = 그 대상 가격 · zone = 대상 자리(buy = 아래서 산 자리 · sell = 위에서 판 자리) · stage = target_selected 대상선정 | reverse_pending 반전 보류(테스트·보류 포함) | confirmed 확정 | reverse_failed 추세 변경 안 됨 · primary = 1순위 여부 · touch_kind = 터치 종류(break 종가로 돌파 · inside 꼬리만) · touched_at = 터치 봉 시각 · holds = 보류 이월 횟수 · reverse_side = 반전 측. 신호·결말(stage 최상위)과 별개 층이고 신호 아님."New value: +"이 시간대가 **함께 보고 있는 대상 목록**(1순위 먼저, 보조는 현재가 가까운 순 — 후입(late) 유닛 포함·자르지 않는다). 한 시간대에서 대상은 하나가 아니다 — 1순위가 판정 중이어도 이전부터 있던 다른 대상이 터치되면 보조 유닛으로 각자 판정한다(수평·수직). unit_target = 그 대상 가격 · zone = 대상 자리(buy = 아래서 산 자리 · sell = 위에서 판 자리) · stage = target_selected 대상선정 | reverse_pending 반전 보류(테스트·보류 포함) | confirmed 확정 | reverse_failed 추세 변경 안 됨 · primary = 1순위 여부 · touch_kind = 터치 종류(break 종가로 돌파 · inside 꼬리만) · touched_at = 터치 봉 시각 · holds = 보류 이월 횟수 · reverse_side = 반전 측. 신호·결말(stage 최상위)과 별개 층이고 신호 아님."Output schema / properties / timeframes / items / properties / units / items / properties / lateAdded value: +{
+ "type": "boolean"
+}decker.get_market_state2 fields changedOutput schema / properties / timeframes / items / properties / label_nextAdded value: +{
+ "description": "1순위 대상의 라벨이 **다음 한 봉**에 어떻게 되는지의 읽기. state = 지금 라벨 위치 · hi/lo = 직전 봉의 고가·저가(다음 봉이 이 두 가격에 대해 고가 갱신 F · 저가 갱신 B · 둘 다 아님 I · 둘 다 W 로 갈린다 — 종가가 아니다) · next = 움직임별 다음 라벨. 판정 입력이 아니라 읽기. 엔진이 아직 내지 않은 세대는 null.",
+ "properties": {
+ "hi": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "lo": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "next": {
+ "properties": {
+ "B": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "F": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "I": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "W": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "state": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+}Output schema / properties / timeframes / items / properties / missedAdded value: +{
+ "description": "판정 없이 지나간 break(미싱)의 최근 몇 건(최신 먼저). 판정 중인 1순위가 있는 동안 태어난 대상이 터치브레이크되면 판정 대상이 아니라 미싱으로 남는다 — **상태**일 뿐 스윙 반전이 아니다. time = 그 봉 시각 · price = 그 대상 가격 · sign = 대상 부호 · position = 그 봉 종가가 대상의 위(above)/아래(below) · judging = 그때 판정 중이던 1순위 대상 가격.",
+ "items": {
+ "properties": {
+ "judging": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "position": {
+ "enum": [
+ "above",
+ "below",
+ "at",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "price": {
+ "type": "number"
+ },
+ "sign": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "time": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+}decker.get_state_timelinedecker.get_engine_state_rawdecker.get_price_axis_statedecker.get_assembly2 fields changedInput schema / properties / detailAdded value: +{
+ "description": "Include path / watch / story / ladders / matrix_summary (about 20KB per symbol). Default false: the answer only.",
+ "type": "boolean"
+}Input schema / properties / symbol / descriptionPrevious value: -"Optional symbol or alias (BTC, 비트코인, GOLD, 테슬라...). Omit for the full universe."New value: +"Optional symbol or alias (BTC, 비트코인, GOLD, 테슬라...). Omit for all 14 symbols."decker.get_episodesdecker.get_market_state2 fields changedOutput schema / properties / timeframes / items / properties / action_switch / descriptionPrevious value: -"이 시간대 루프의 현재 위치가 사용자에게 주는 **행동전환 결정**(저자 10-11 교정 #9·#10: 런타임은 스냅샷이라 모든 상태가 결정을 낸다). need = required 전환 필요(이 봉에서 신호 확정, side 로 진입·반대 측이면 청산 후 리버스) · exit 청산(이 봉에서 직전 신호 실패 — stance 측 판단 근거 붕괴) · pending 전환 대기(확정 전, 반전 가설이 시험 중 — side = 후보 방향, 가설이 양방향이면 null) · not_required 전환 불필요(stance = 직전 신호 측 유지, 없으면 행동 없음). reversal_tests = 살아 있는 반전 가설 수(1순위+보조 유닛, 방향별 — 순위·승격 없음) · mismatch = 최근 키와 종가 위상이 엇갈림(양방향 동시 테스트) · close_vs_target = 1순위 대상 가격 대비 종가 위치. 신호(stage)·반전 보류와 별개 층이고 엔진 한 곳에서만 나온다. 가설도 신호도 없으면 null."New value: +"이 시간대 루프의 현재 위치가 사용자에게 주는 **행동전환 결정**(저자 10-11 교정 #9·#10: 런타임은 스냅샷이라 모든 상태가 결정을 낸다). need = required 전환 필요(이 봉에서 신호 확정, side 로 진입·반대 측이면 청산 후 리버스) · exit 청산(이 봉에서 직전 신호 실패 — stance 측 판단 근거 붕괴) · pending 전환 대기(확정 전, 반전 가설이 시험 중 — side = 후보 방향, 가설이 양방향이면 null) · not_required 전환 불필요(stance = 직전 신호 측 유지, 없으면 행동 없음). exit_edge = need=exit 를 정한 사건이 '확인된 신호의 신호봉 반대 경계 종가 이탈'일 때 그 경계 가격(매수=저가·매도=고가) — 표면이 경계를 추정하지 않도록 엔진이 싣는다, 다른 사건이 정한 행동이면 null · reversal_tests = 살아 있는 반전 가설 수(1순위+보조 유닛, 방향별 — 순위·승격 없음) · mismatch = 최근 키와 종가 위상이 엇갈림(양방향 동시 테스트) · close_vs_target = 1순위 대상 가격 대비 종가 위치. 신호(stage)·반전 보류와 별개 층이고 엔진 한 곳에서만 나온다. 가설도 신호도 없으면 null."Output schema / properties / timeframes / items / properties / action_switch / properties / exit_edgeAdded value: +{
+ "type": [
+ "number",
+ "null"
+ ]
+}decker.get_market_state3 fields changedOutput schema / properties / ladder / descriptionPrevious value: -"현재가 위·아래 가까운 순서로 각 8개. 같은 가격은 한 점이고 at 에 그 가격이 어느 시간대에서 어떤 역할인지(kind) 모두 나열된다 — 하위 시간대가 닿는 가격이 상위 시간대의 대상·후보·신호봉 경계이면 그 한 사건이 두 시간대의 사건이다(상위는 하위의 조각이 모여 만들어진다). signal_edge.edge: confirm=그 방향 확인 경계 · fail=반대(실패) 경계. 우세·점수 없음"New value: +"현재가 위·아래 가까운 순서로 각 8개. 같은 가격은 한 점이고 at 에 그 가격이 어느 시간대에서 어떤 역할인지(kind) 모두 나열된다 — 하위 시간대가 닿는 가격이 상위 시간대의 대상·후보·신호봉 경계이면 그 한 사건이 두 시간대의 사건이다(상위는 하위의 조각이 모여 만들어진다). signal_edge.edge: confirm=그 방향 확인 경계 · fail=반대(실패) 경계. reads=그 칸의 사건 문장(역할→사건 표) + 그 시간대의 다음 마감 시각(판정은 종가). 우세·점수 없음"Output schema / properties / ladder / properties / down / items / properties / at / items / properties / readsAdded value: +{
+ "type": "string"
+}Output schema / properties / ladder / properties / up / items / properties / at / items / properties / readsAdded value: +{
+ "type": "string"
+}decker.get_market_state3 fields changedOutput schema / properties / ladderAdded value: +{
+ "description": "현재가 위·아래 가까운 순서로 각 8개. 같은 가격은 한 점이고 at 에 그 가격이 어느 시간대에서 어떤 역할인지(kind) 모두 나열된다 — 하위 시간대가 닿는 가격이 상위 시간대의 대상·후보·신호봉 경계이면 그 한 사건이 두 시간대의 사건이다(상위는 하위의 조각이 모여 만들어진다). signal_edge.edge: confirm=그 방향 확인 경계 · fail=반대(실패) 경계. 우세·점수 없음",
+ "properties": {
+ "down": {
+ "items": {
+ "properties": {
+ "at": {
+ "items": {
+ "properties": {
+ "edge": {
+ "enum": [
+ "confirm",
+ "fail",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "kind": {
+ "enum": [
+ "unit_target",
+ "next_unit_target",
+ "connection",
+ "candidate",
+ "signal_edge",
+ "decision"
+ ],
+ "type": "string"
+ },
+ "timeframe": {
+ "enum": [
+ "1w",
+ "1d",
+ "8h",
+ "4h",
+ "1h",
+ "30m"
+ ],
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "distance_pct": {
+ "type": "number"
+ },
+ "price": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "up": {
+ "items": {
+ "properties": {
+ "at": {
+ "items": {
+ "properties": {
+ "edge": {
+ "enum": [
+ "confirm",
+ "fail",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "kind": {
+ "enum": [
+ "unit_target",
+ "next_unit_target",
+ "connection",
+ "candidate",
+ "signal_edge",
+ "decision"
+ ],
+ "type": "string"
+ },
+ "timeframe": {
+ "enum": [
+ "1w",
+ "1d",
+ "8h",
+ "4h",
+ "1h",
+ "30m"
+ ],
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "distance_pct": {
+ "type": "number"
+ },
+ "price": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}Output schema / properties / timeframes / items / properties / closes_withAdded value: +{
+ "description": "진행 중인 봉이 이 시간대와 같은 시각에 닫히는 다른 시간대 목록 — 겹치는 하위 봉의 종가가 상위 판정의 결정적 순간이다",
+ "items": {
+ "enum": [
+ "1w",
+ "1d",
+ "8h",
+ "4h",
+ "1h",
+ "30m"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / timeframes / items / properties / next_close_timeAdded value: +{
+ "description": "이 시간대의 진행 중인 봉이 닫히는 시각(마지막 평가 봉 마감 + 시간대 길이). 상위 봉은 하위 봉들이 모여 닫힌다",
+ "format": "date-time",
+ "type": [
+ "string",
+ "null"
+ ]
+}decker.get_market_state1 field changedOutput schema / properties / timeframes / items / properties / signal_positionAdded value: +{
+ "description": "확인·실패 신호의 지금 종가가 신호봉 대비 어디인가(신호 방향 반영) — for=신호 방향 경계 밖 · against=반대 경계 밖(불리; 신호 결과 stage 는 첫 결말로 고정이고 이후 이탈은 위치로만 남는다) · inside=신호봉 안",
+ "enum": [
+ "for",
+ "against",
+ "inside",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+}decker.get_market_state1 field changedOutput schema / properties / timeframes / items / properties / standingAdded value: +{
+ "description": "**유지 중인 입장의 기준 신호**(단계가 대상선정일 때만, 직전 신호가 확인이고 아직 실패하지 않았을 때). 새 대상이 선정되어도 직전 확인 신호의 입장은 유지된다(action_switch.stance) — 그 입장의 진입가·손절·목표를 신호 단계 필드(entry·stop·target)와 섞지 않고 따로 싣는다. side = 유지되는 입장 · signal_time = 그 신호 시각 · entry = 체결 기준(신호 시점 종가) · stop = 손절 · target = 목표 좌표 · target_rr = 좌표가 없을 때 손익비 기계값. 신호 단계(pending·confirmed·failed)이거나 직전 확인 신호가 없으면 null",
+ "properties": {
+ "entry": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "side": {
+ "enum": [
+ "buy",
+ "sell"
+ ],
+ "type": "string"
+ },
+ "signal_time": {
+ "format": "date-time",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "stop": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "target": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "target_rr": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+}decker.get_market_state1 field changedOutput schema / properties / timeframes / items / properties / unitsAdded value: +{
+ "description": "이 시간대가 **함께 보고 있는 대상 목록**(최대 6, 1순위 먼저). 한 시간대에서 대상은 하나가 아니다 — 1순위가 판정 중이어도 이전부터 있던 다른 대상이 터치되면 보조 유닛으로 각자 판정한다(수평·수직). unit_target = 그 대상 가격 · zone = 대상 자리(buy = 아래서 산 자리 · sell = 위에서 판 자리) · stage = target_selected 대상선정 | reverse_pending 반전 보류(테스트·보류 포함) | confirmed 확정 | reverse_failed 추세 변경 안 됨 · primary = 1순위 여부 · touch_kind = 터치 종류(break 종가로 돌파 · inside 꼬리만) · touched_at = 터치 봉 시각 · holds = 보류 이월 횟수 · reverse_side = 반전 측. 신호·결말(stage 최상위)과 별개 층이고 신호 아님.",
+ "items": {
+ "properties": {
+ "holds": {
+ "type": "integer"
+ },
+ "primary": {
+ "type": "boolean"
+ },
+ "reverse_side": {
+ "enum": [
+ "buy",
+ "sell",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "stage": {
+ "enum": [
+ "target_selected",
+ "reverse_pending",
+ "confirmed",
+ "reverse_failed"
+ ],
+ "type": "string"
+ },
+ "touch_kind": {
+ "enum": [
+ "break",
+ "inside",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "touched_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "unit_target": {
+ "type": "number"
+ },
+ "zone": {
+ "enum": [
+ "buy",
+ "sell",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+}decker.get_market_state5 fields changedOutput schema / properties / events / descriptionPrevious value: -"최근 사건(새것 먼저). 대상선정·신호·신호 결말·이전 판정 가격 도달(conn_arrival: 가격이 이전에 판정이 끝난 기준 가격에 닿음 — 방향·결말 판정 아님)."New value: +"최근 사건(새것 먼저). 대상선정·신호·신호 결말·추세 변경 안 됨(reverse_failed: 1순위 대상의 반전이 실패한 판정 결과, side = 유지되는 추세 쪽 — 신호 아님)·반전 테스트(reverse_tested: 1순위 대상의 반전 첫 키 결과, status beyond|short — 신호 아님)·이전 판정 가격 도달(conn_arrival: 가격이 이전에 판정이 끝난 기준 가격에 닿음 — 방향·결말 판정 아님)."Output schema / properties / events / items / properties / kind / descriptionPrevious value: -"conn_arrival(이전 판정 가격 도달) = 가격이 이전에 판정이 끝난 가격에 닿았다는 사실. 방향·결말 판정이 아니며 텔레그램으로는 보내지 않는다."New value: +"conn_arrival(이전 판정 가격 도달) = 가격이 이전에 판정이 끝난 가격에 닿았다는 사실. 방향·결말 판정이 아니며 텔레그램으로는 보내지 않는다. reverse_failed(추세 변경 안 됨, 엔진 `judge_failed`) = 1순위 대상의 판정 결과 중 반전이 실패한 것 — side = 유지되는 추세 쪽, price = 그 대상. 신호가 아니라 판정 결과 사실이며(진입·청산 사용은 진입 모드 층의 몫, 게이트는 WATCH) 텔레그램 채널 없음. reverse_tested(반전 테스트, 엔진 `judge_test`) = 1순위 대상의 B 국면 첫 반대 키 결과 — side = 반전 쪽 키, price = 대상, status = beyond(테스트 S 종가가 대상 너머 = 최소 조건 충족)|short. 신호 아님·텔레그램 없음. 보조 유닛의 결과는 표면에 올리지 않는다."Output schema / properties / events / items / properties / kind / enumPrevious value: -[
- "target_selected",
- "signal",
- "signal_resolved",
- "conn_arrival"
-]New value: +[
+ "target_selected",
+ "signal",
+ "signal_resolved",
+ "conn_arrival",
+ "reverse_failed",
+ "reverse_tested"
+]Output schema / properties / events / items / properties / status / descriptionPrevious value: -"signal_resolved 의 결말"New value: +"signal_resolved 의 결말(confirmed|failed) · reverse_tested 의 최소 조건(beyond = 테스트 S 종가가 대상 너머 마감 · short = 못 넘음)"Output schema / properties / events / items / properties / status / enumPrevious value: -[
- "confirmed",
- "failed",
- null
-]New value: +[
+ "confirmed",
+ "failed",
+ "beyond",
+ "short",
+ null
+]
Add one secure layer between your agents and this server.