Deterministic market-state engine for trading agents — state, gate, coordinates, with receipts.
Scored across 16 tools
The read-side is crowded with overlapping market-state tools: get_market_state, get_view, get_reading, get_assembly, get_state_timeline, get_signals, plus two deprecated variants (get_engine_state_raw, get_price_axis_state) all surface similar engine state. The descriptions go to great lengths to distinguish them (raw vs structured vs Korean card vs AI narrative vs per-bar timeline), which helps, but the two self-declared DEPRECATED tools sitting alongside their replacements create real misselection risk. Execution tools (place_order, close_position, update_protective_stops, validate_intent) are cleanly distinct.
Every tool follows a consistent decker.verb_noun snake_case pattern: get_*, place_order, close_position, update_protective_stops, set_skill_overlay, validate_intent. No camelCase/snake_case mixing and no vague single-word verbs. One tool (close_position) drops the noun-ish sub-object but still reads clearly as verb_noun.
16 tools is reasonable for a trading engine spanning state reads, signal retrieval, execution, and skill configuration, though it sits at the heavy end and is inflated by two deprecated tools that should be pruned. With those removed, ~14 well-earned tools fit the scope cleanly.
The domain lifecycle is well covered: state/reading tools, signals, trigger history, execution (place_order, close_position, update_protective_stops), pre-trade validation, and skill overlays. The absence of a cancel_order tool is explicitly justified (Decker only places market orders), so it is not a real gap. Minor: no explicit account/balance or order-history surface outside the position-closed-round-trips view.
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.
Multi-timeframe optimal-path assembly per symbol (STRATEGY_LAYER §8): one deterministic machine verdict combining all live timeframes — direction, grade (aligned | structure+pullback | exhaustion-reversal), entry (now vs wait, with source TF), stop (risk stop), target (upper-TF target), RR, and a conditional switch coordinate on mixed structure. Upper TF supplies the target (slower = higher success), lower TF supplies the entry. This is the single judgment authority — narrate or filter it, do not re-decide coordinates. Omit symbol for all 14 universe symbols. ⚠ grade='aligned' means no OPPOSING-direction row exists among the active timeframes — it does NOT mean every timeframe's gate is GO/actionable right now. Check matrix_summary[].gate per timeframe before treating 'aligned' as 'all timeframes tradeable now'. ⚠ entry.mode='지금'(now) is a pure price-geometry verdict (STRATEGY_LAYER §8 R3 — is current price within the exhaustion-reversal zone or the ±0.3% entry band), independent of any timeframe's trigger/gate state — it does NOT mean the engine has confirmed a break event on this bar. Check the entry TF's row in matrix_summary[].gate before treating entry.mode='지금' as 'a trigger just fired, act now'.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | Optional symbol or alias (BTC, 비트코인, GOLD, 테슬라...). Omit for the full universe. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does substantial work: it discloses deterministic assembly logic, the upper/lower timeframe rule, and two critical interpretive caveats ('aligned' ≠ all gates GO; entry.mode='지금' ≠ trigger confirmed). It also enumerates the return dimensions despite having no output schema.
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 opens with a compact definition and field list, then layers role instructions, scope hint, and caveats in order of importance. Though long, every sentence contributes—the warnings prevent misinterpretation—and there is no padding.
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?
Despite no output schema and no annotations, the description enumerates all output components, explains the source/target timeframe relationship, and warns about the two most likely misreadings. The only minor gap is defining 'matrix_summary[].gate', but the description still tells the agent exactly what to check.
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 100%, and the schema already documents symbol as optional with aliases and omission behavior. The description adds the count 'all 14 universe symbols' and clarifies scope, but that is marginal over the schema, so the baseline 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 specifies that this tool produces a 'single deterministic machine verdict' combining all live timeframes, naming the exact output dimensions (direction, grade, entry, stop, target, RR, switch coordinate). It positions it as 'the single judgment authority,' so an agent can distinguish its role from other tools even without explicit sibling names.
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 provides clear usage guidance: it is the final authority for coordinates ('narrate or filter it, do not re-decide coordinates') and explains scoping with/without symbol ('Omit symbol for all 14 universe symbols'). However, it does not explicitly name sibling alternatives or state when not to use this tool, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[DEPRECATED — use decker.get_market_state (consumer contract CR1). Kept only for KRX symbols and until usage telemetry shows zero calls; will be removed.] Market State v0 — current engine structural state for a symbol/timeframe (latest evaluated bar, persisted engine emit read as-is, zero recompute). DOMAIN FRAME (why this engine exists): the market is read as a TARGET GAME — every coordinate comes from a verified anchor (a past level where a triggered move actually succeeded). The game block tells you the context that matters: game.status = forming_target (new anchor set, awaiting test) | testing_target (price is testing whether the declared target holds) | direction_resolved (game decided, price traveling); game.target = WHO is being judged (anchor id/phase/band); game.progress_dest = where price goes if the move proceeds (the opposing verified anchor to conquer); game.reverse_dest = where it goes if the move fails (the opposite house — also the stop logic's home); game.why_gate = full gate derivation chain; game.zt_regime = output canonicality (restored = deterministic delta lineage). action_gate alone (GO/WATCH/HOLD) is only a posture — the game context is the information. RAW CONTRACT: fields are engine-native vocabulary (c_state, hold_reason, R_* risk enums …), NOT customer-facing prose — for a human-language view use decker.get_view (with tf) or decker.get_reading. layer=STATE: this is a market-state reading, NOT a trade instruction. Absent fields are null (engine did not emit that axis — no filling). IMPORTANT: top-level state.c_state/action_gate/trigger_kind reflect the TRIGGER SNAPSHOT (only populated on a bar that actually had a trigger event) — null on most bars is normal, not a data gap. For the always-present, every-bar-populated view of the same axes use game.phase.c_state / game.phase.action_gate instead (different freshness, same underlying engine state machine). Don't read a null top-level field as 'engine has no state' — check game.phase first. current_price (top-level, 2026-09-03): {price, bar_ts} — the single latest completed-bar close for this symbol ACROSS ALL timeframes (not just the requested tf), useful when comparing multiple timeframes' target bands against one 'now' price. null for KRX individual-stock symbols. Before placing any order through any execution tool, check the intent with decker.validate_intent.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 behavioral burden and does so well: it discloses raw engine-native vocabulary (c_state, hold_reason, R_*), that absent fields are null rather than filled, that top-level state.c_state/action_gate/trigger_kind reflect a trigger snapshot and are normally null, and that current_price spans all timeframes. It does not state permission/auth or rate-limit characteristics, so it falls just short of full disclosure.
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-loading is excellent: the deprecation/successor notice leads, so an agent immediately knows not to prefer this tool. However, the body is a dense wall of domain framing and field-level caveats that is long relative to a two-parameter raw read, and several paragraphs (e.g. the anchor/target-game exposition) could be trimmed or deferred.
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 complex, no-output-schema tool the description compensates well: it explains the likely return shape (game block sub-fields, phase axes), null semantics, snapshot-vs-always-present freshness divergence, and the special current_price field. An agent has enough to interpret the response without an 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 coverage is 50% (symbol has only 'e.g. BTCUSDT', timeframe is an enum). The description references a symbol/timeframe pair and notes current_price is null for KRX individual-stock symbols and spans all timeframes, which adds marginal context, but it never defines the timeframe semantics or any constraints on the parameters themselves.
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 first operative clause states a specific verb and resource: 'current engine structural state for a symbol/timeframe (latest evaluated bar, persisted engine emit read as-is, zero recompute).' It explicitly distinguishes itself from siblings by naming decker.get_market_state as the successor, decker.get_view/get_reading for prose, and marking itself deprecated and KRX-only.
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_market_state instead, this is kept only for KRX symbols and until telemetry hits zero. It also directs to decker.get_view (with tf) / decker.get_reading for human-language output and to decker.validate_intent before placing any order. When-to-use and alternatives are both spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current swing-judgment state of a symbol across timeframes, as structured data (consumer contract CR1). Per timeframe (top→short): stage = target_selected (대상선정) | pending (판정보류: the close is still inside the signal bar) | confirmed (확인) | failed (실패) | none; side = buy/sell; signal_time; signal_bar {time, low, high} (the bar whose edges decide confirm/fail); confirmed_at / resolved_close; entry (= close at the signal, the fill basis); stop; target (opposite-side confirmed-signal edge at least 2% from entry, else null + target_reason); unit_target (the price this timeframe is judging now); prev_signal; turn = reverse (the signal flips the previous signal's direction = it changes the standing action) | same (continues it) | null; levels = nearby prices above/below the close. state_text = ready-to-show Korean status (title with price, then two compact lines: 상위·중간 / 단기, timeframes without a signal omitted, a failed row carries the price that decided it, plus nearby prices; no interpretation). Marks in state_text: color = state, shape = direction — 🟢▲ buy confirmed · 🔴▼ sell confirmed (action-worthy) · ⚪▲/⚪▼ pending (signal exists, unconfirmed) · 🟡 target selected / judging · ✖️ failed (void signal, NOT the opposite side). timeframe_summary = the same rows merely listed by (stage, side), e.g. confirmed.buy = ['1d','4h'] — a listing, not a verdict: no weights, scores or votes, and failed is NOT counted as the opposite side. events = recent target_selected / signal / signal_resolved / conn_arrival, newest first. Each timeframe reports its own state side by side — there is NO cross-timeframe verdict, no probability/confidence/bias fields; combining timeframes into a view is the caller's job. HOW TO ANSWER: this tool is the source of truth for direction. Show state_text, then explain in your own words using only these values (what each timeframe confirmed/failed/is waiting on, and which prices to watch); do not invent probabilities or targets. decker.get_view shows the same values as ready-made text. Read as persisted (no recompute). layer=STATE: a market-state reading, NOT a trade instruction. Crypto and Hyperliquid synthetics only (KRX: use decker.get_reading). Before placing any order through any execution tool, 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 | 최근 사건(새것 먼저). 대상선정·신호·신호 결말·기준 가격 도달(conn_arrival: 가격이 이전에 판정이 끝난 기준 가격에 닿음 — 방향·결말 판정 아님). |
| 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 full burden and mostly delivers: it declares 'Read as persisted (no recompute)', layer=STATE (not a trade instruction), no cross-timeframe verdict, and explicitly denies probability/confidence/bias fields. It omits auth/permission and rate-limit behavior, but for a read-only state snapshot the coverage is strong.
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 purpose, but the body is a very long semicolon-chained run-on that is hard to parse and spends many clauses detailing return fields that a present output schema already covers. Density is justified by complexity, yet it is over-sized relative to what an agent needs to select and call it.
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 complex state-reading tool with a sibling ecosystem and an existing output schema, the description covers scope, domain limits, behavioral guarantees, interpretation rules, and routing. An agent has everything required to call it correctly and use the result without hallucinating probabilities.
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%, so most parameters are documented in the schema itself (symbol examples, timeframe alias, timeframes subset, events_limit default/range). The description adds no per-parameter meaning or format detail beyond what the schema already supplies, so it sits at the 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+resource ('Current swing-judgment state of a symbol across timeframes, as structured data') and explicitly frames it as 'the source of truth for direction'. It differentiates itself from siblings by name: get_view (same values as ready-made text), get_reading (KRX), and validate_intent (before orders).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit 'HOW TO ANSWER' section plus routing rules: use this for direction, get_view for ready-made text, get_reading for KRX, and validate_intent before any order. The domain restriction ('Crypto and Hyperliquid synthetics only') is stated as an exclusion, which is exactly what a routing agent needs.
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: 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, the description carries the full burden. It discloses the tool returns real open positions with live sl_price/tp_price, virtual positions, and closed round-trips, which gives a clear picture of what the agent will receive. It does not explicitly state read-only behavior or edge cases like data freshness, but for a 0-parameter getter, the provided behavioral context is strong and goes beyond a simple verb.
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 well-organized, with a clear lead-in 'Axis③ (Order/Execution)' followed by specifics. Every sentence earns its place: it lists data types, differentiates from a sibling, and gives usage context. Slightly long due to the repeated mention of axes, but not wasteful.
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 zero parameters and no output schema, the description provides essential return-value context (real/virtual positions, closed round-trips, stop/target data). It also covers why this tool matters for decision-making. For a simple read-only listing tool, this is comprehensive.
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 accepts zero parameters, so there is no parameter semantics to explain. As per the baseline for 0-param tools, this is scored high since the description does not need to compensate for schema gaps. The absence of parameters is clear from the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies this as a tool for retrieving the user's actual trading exposure, specifically listing real open futures positions, virtual/paper positions, and recent closed round-trips. It distinguishes itself from the sibling tool decker.get_signals ('axis②, what the engine recommends') by explicitly stating it shows 'what your money actually did', making it unambiguous which tool to use.
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 provides explicit usage guidance: 'use this before deciding whether to place another order (avoid duplicate/over-exposure) and to check current protective stop/target on a real position.' It also names the alternative (decker.get_signals) and clarifies the difference in axes, effectively telling when to use this vs that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[DEPRECATED — use decker.get_market_state (CR1); this raw price-axis dump is superseded and will be removed after usage telemetry shows zero calls.] Price-axis (close-based target selection) state, read from engine_bar_state as persisted (Store-Output-Read, no recomputation). One voice: signal is the current state — side (+ buy / - sell), the signal bar (judgment bar '2' sealed by S) with its low/high, entry candidates (target, close two bars before the signal, bar-2 open, bar-2 close), and the outcome stated as WHAT crossed WHAT: status 'confirmed' = a close beyond the signal-bar edge in the signal's direction (resolved_ts, resolved_close), 'failed' = beyond the opposite edge, 'inside' = 판정보류 (close still inside the signal bar). prev/history = earlier signals with the same fields. active_target = the target this unit is labeling from (price, touch_kind, touched_ts); label = this bar's labeler output (t1/t2/1/2/+S/-S); pending_targets/rolling_target/conn_stems = coordinates. goal = exit target measured from the entry (signal bar-2 open): nearest opposite confirmed-signal edge at least 2% away, plus ladder = nearest such level at >=2% / >=4% / >=8% from entry (empty tier = no structure there, never filled with a percentage); goal.price null + reason = no level >=2% from entry. event_flow = the persisted event history (oldest→newest, last 20): target_selected / signal / signal_resolved (signal bar confirmed/failed with the close that decided it) / conn_arrival — compare the current state against how the events flowed. Omit timeframe for the multi-timeframe view: one row per TF {readable, target, signal, close} — side by side, no cross-TF verdict (cross_tf_verdict stays null). IMPORTANT — action_gate is always null BY DESIGN: this axis is diagnostic-only and not wired to any gate or order path. For GO/WATCH/HOLD use decker.get_market_state (MAIN axis). null when the engine has not evaluated the symbol/TF.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | e.g. BTCUSDT | |
| timeframe | No | OMIT for the multi-timeframe view (all TFs side by side) — that is the intended way to read this axis. Pass one TF only when you deliberately want a single horizon. |
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: it discloses the read source (no recomputation), the diagnostic-only nature, that action_gate is null by design and not wired to any gate/order path, that the result is null when the engine hasn't evaluated the symbol, and the full deprecation lifecycle.
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?
Being dense and front-loaded with the deprecation notice is correct, and each field bundle (signal/prev/history, goal, event_flow) earns its place. It is nonetheless a very long block for a deprecated tool, and the read would be faster split into return-field prose plus a short deprecation line.
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 explain return values, and it covers signal states (confirmed/failed/inside), goal/ladder semantics, event_flow contents, and the null case comprehensively. Nothing an agent needs to interpret or safely avoid this axis is 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 description coverage is 100%, so both parameters are already documented — including the 'omit for multi-TF view' guidance, which the description merely echoes. The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.
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 and resource — a persisted read of 'price-axis (close-based target selection) state' from engine_bar_state — and explicitly names its replacement sibling (decker.get_market_state, CR1). An agent can immediately distinguish it from the MAIN-axis market_state tool.
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 says the tool is superseded and should be replaced by get_market_state, gives the migration reason (CR1), and states the removal condition (zero-call telemetry). It also tells the agent the intended invocation pattern (omit timeframe for the multi-TF view) and routes GO/WATCH/HOLD queries to the MAIN axis instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AI-synthesized market reading for a symbol/timeframe, in customer-facing language: current state description, directional bias scores, bidirectional break targets, MTF verdict per timeframe, and an execution hint (stance + long/short setups). Engine-native raw fields are NOT exposed here — use the REST raw contract (GET /public/reading) or decker.get_market_state for those . execution_hint.preferred_direction is derived from key_direction alone and is NOT guaranteed to have a matching long_setup/short_setup (they come from an independent break-target resolver) — check that the setup for the preferred side is non-null before treating preferred_direction as an actionable side.
| 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 exist, so the description carries the full burden and does meaningful work: it discloses that raw engine fields are deliberately withheld and that execution_hint.preferred_direction is derived from key_direction alone and may not correspond to a real setup. It omits read-only/auth/rate-limit traits, but the derivation caveat is a genuinely useful behavioral disclosure.
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?
Purpose and output inventory are front-loaded in the first sentence, followed by two dense but high-value caveats (raw-field exclusion, preferred_direction trap). No filler; every clause carries information.
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 by enumerating returned fields and flagging the main pitfall in acting on the execution hint. It is largely complete, though it does not state the read-only nature or default-timeframe behavior.
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%, with tf's enum and default documented in the schema itself. The description implies timeframe selection and multi-TF output but adds no syntax or semantics for tf or include_tfs 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?
Names a specific verb+resource ('AI-synthesized market reading for a symbol/timeframe') and enumerates the payload it returns (state description, bias scores, break targets, MTF verdict, execution hint). It also explicitly differentiates itself from siblings by pointing to decker.get_market_state and the REST raw contract for engine-native 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?
Gives clear when-not guidance: for engine-native raw fields use GET /public/reading or decker.get_market_state instead. It also warns to verify a non-null setup before acting on preferred_direction. Lacks an explicit 'use this tool when you want the customer-facing view' framing, but the context is inferable.
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.
Market State v0 — per-bar state timeline for a symbol/timeframe (v0 per-bar schema — NOT the structured CR1 of decker.get_market_state; for the persisted event list use decker.get_market_state events or GET /public/state/{symbol}/{tf}/events; each item carries a SLIM game tag {status, target_id, zt_regime, provenance} instead of the full game block — read status transitions across bars to see how the target game unfolded (forming → testing → resolved/failed); ascending by bar_ts). Bars the engine did not emit are simply absent (honest gaps, no filling).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| since | No | ISO8601 lower bound on bar_ts (exclusive). Optional. | |
| symbol | Yes | e.g. BTCUSDT | |
| timeframe | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full burden and does disclose real return-shape behavior: a SLIM game tag {status, target_id, zt_regime, provenance} instead of the full block, ascending order by bar_ts, and that absent bars are honest gaps with no filling. It omits auth, rate limits, and pagination behavior, but the core behavioral traits are covered.
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?
Information-dense and front-loaded with the core purpose, but delivered as one run-on sentence with heavy nested parentheticals that make it hard to scan. Every clause is relevant, yet the structure 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?
With no output schema and no annotations, the description steps in to describe the return shape, ordering, and gap behavior, which is what an agent most needs. It leaves out pagination/limit behavior and the meaning of fields like zt_regime/provenance, so it is strong but not fully 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?
Schema description coverage is only 50% and the description adds little parameter-level meaning: it does not explain `limit`, the `timeframe` enum choices, or how `since` interacts with pagination. `symbol` and `since` are already documented in the schema, and the bar_ts/ordering remarks are return-format notes rather than parameter semantics.
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 and scope: 'per-bar state timeline for a symbol/timeframe'. It explicitly distinguishes itself from decker.get_market_state (structured CR1) and its persisted event list, so an agent can separate this tool from its closest sibling 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?
It names alternatives and the condition that routes to them ('NOT the structured CR1 of decker.get_market_state; for the persisted event list use decker.get_market_state events'). It also implies the use case (read status transitions across bars). It does not spell out a crisp when-to-pick-this-tool-vs-siblings rule, keeping it below a 5.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It transparently states the exact output content (eight named skills and the selected one). It does not disclose any side effects (none expected for a getter) or error conditions, but for a simple read operation this is sufficient and not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the core purpose ('Trading skill catalog + currently active overlay') and then provides the specific skill identifiers. Every word earns its place; there is 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 parameterless getter with no output schema, the description fully specifies what the agent will receive: the complete list of skills and the active one. Nothing an agent needs to understand the tool's contract is 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 schema coverage is trivially 100%. The description adds no parameter-specific information, which is fine; the baseline of 4 applies per the rubric for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a trading skill catalog and the user's active overlay. It enumerates the exact skill identifiers, leaving no ambiguity about what is returned. It is easily distinguished from siblings like set_skill_overlay, which modifies the overlay.
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 purpose is self-evident: to read the skill catalog and current selection. It provides clear context for when to use it (e.g., before decision-making or before set_skill_overlay), but it does not explicitly state when not to use it or name an alternative. The absence of parameters and the clear read-only intent make it a minor gap.
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.
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 side_alignment (aligned/opposed vs the active signal's direction). covered=false means the engine does not emit state for this symbol — treat as unknown, not as HOLD. top-level action_gate can be null even when covered=true — this is not a missing field, it means the current bar has no fresh trigger reading; check gate_null_reason ('no_gate_available' = neither the current bar nor the carried-forward signal had a gate at all, vs 'signal_stale' = a value existed but the underlying signal exceeded the staleness threshold and was deliberately suppressed rather than served as a confident-but-old answer). The order decision and responsibility remain with the calling agent/user. Every check is persisted to an auditable decision ledger (check_id).
| 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 does so thoroughly: it defines the return vocabulary, explains covered=false (unknown, not HOLD), the null action_gate case, both gate_null_reason values, and the deliberate staleness suppression. It further discloses ledger persistence (check_id) and that responsibility stays with the caller.
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?
Purpose and call timing are front-loaded, and the dense edge-case material on null gates is justified by the tool's complexity. It is a single unbroken block, so structure could be tighter, but nearly every sentence carries decision-relevant information.
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 complex gate-check tool with no output schema and no annotations, the description covers return semantics, the covered/null/stale edge cases, and the decision boundary. Nothing an agent needs to interpret the response correctly is 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 description coverage is 100%, so the schema already documents symbol aliasing, side sign convention, and the timeframe defaulting chain. The description adds only marginal parameter context ('symbol + side') beyond the structured fields, so the baseline 3 applies.
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 immediately separates itself from execution siblings by naming the review→place flow it precedes. An agent can distinguish it from decker.place_order and decker.get_engine_state_raw without opening a 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?
Explicitly prescribes timing ('Call this BEFORE placing any order through any execution tool') and references the alternative (broker MCP review→place). It also states the decision boundary — the tool reads a stance, it does not approve/reject — leaving no ambiguity about when to invoke it.
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.get_market_state1 field changedOutput schema / properties / timeframes / items / properties / target_rrAdded value: +{
+ "description": "확인된 목표 좌표(target)가 없는 자리(신고점·신저점)에서 **손익비 2:1 기계값**. 새 상수 없이 손절 거리의 2배에서 파생되며 자동주문의 목표와 같은 값이다. 좌표가 아니라 계산값이므로 target 과 섞이지 않는다. target 이 있으면 null",
+ "type": [
+ "number",
+ "null"
+ ]
+}decker.get_market_state1 field changedOutput schema / properties / timeframes / items / properties / target_source_tfAdded value: +{
+ "description": "목표가 **상위 시간대**의 확인된 반대 신호 경계(연계 좌표, 규칙표 R20.5·C4)일 때 그 시간대(예: '1w'). 자기 시간대 좌표면 null. 거리는 진입가 대비 단계 규칙 그대로이며 상위 시간대 좌표라 멀 수 있다",
+ "enum": [
+ "1w",
+ "1d",
+ "8h",
+ "4h",
+ "1h",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+}decker.get_market_state1 field changedOutput schema / properties / timeframe_summaryAdded value: +{
+ "description": "시간대 행을 단계(confirmed 확인·pending 판정보류·failed 실패)와 방향(buy·sell)별로 나열만 한다. 우세·점수·투표 없음 — 실패는 반대 방향을 뜻하지 않는다. target_selected = 대상선정 중인 시간대 목록",
+ "properties": {
+ "confirmed": {
+ "properties": {
+ "buy": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "sell": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ "failed": {
+ "properties": {
+ "buy": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "sell": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ "pending": {
+ "properties": {
+ "buy": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "sell": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ "target_selected": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}decker.get_market_state2 fields changedOutput schema / properties / events / descriptionPrevious value: -"최근 사건(새것 먼저). 대상선정·신호·신호 결말·연결 도착."New value: +"최근 사건(새것 먼저). 대상선정·신호·신호 결말·기준 가격 도달(conn_arrival: 가격이 이전에 판정이 끝난 기준 가격에 닿음 — 방향·결말 판정 아님)."Output schema / properties / events / items / properties / kind / descriptionAdded value: +"conn_arrival(기준 가격 도달) = 가격이 이전에 판정이 끝난 기준 가격에 닿았다는 사실. 방향·결말 판정이 아니며 텔레그램으로는 보내지 않는다."decker.get_market_state4 fields changedOutput schema / properties / state_textAdded value: +{
+ "description": "사용자에게 그대로 보여 줄 수 있는 현재 상태 문면 — 상위·중간·단기로 묶어 시간대마다 방향+단계, 마지막에 주목 가격. 해석·전망 문장은 없다(그건 호출자 몫). 시간대 행이 없으면 null",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / timeframes / items / properties / prev_signal / properties / stage / descriptionPrevious value: -"target_selected=대상선정 · pending=판정보류 · confirmed=확인 · failed=실패 · none=신호 없음"New value: +"target_selected=대상선정 · pending=판정보류 · confirmed=확인 · failed=실패 · none=신호 없음. failed = that signal's judgment broke (the close crossed the signal bar's opposite edge) — it does NOT assert the opposite direction; read the timeframe's own fields (signal_bar / resolved_close / confirmed_at) for which price decided it."Output schema / properties / timeframes / items / properties / stage / descriptionPrevious value: -"target_selected=대상선정 · pending=판정보류 · confirmed=확인 · failed=실패 · none=신호 없음"New value: +"target_selected=대상선정 · pending=판정보류 · confirmed=확인 · failed=실패 · none=신호 없음. failed = that signal's judgment broke (the close crossed the signal bar's opposite edge) — it does NOT assert the opposite direction; read the timeframe's own fields (signal_bar / resolved_close / confirmed_at) for which price decided it."Output schema / properties / timeframes / items / properties / turnAdded value: +{
+ "description": "신호가 살아 있는 단계(pending·confirmed)에서 직전 신호와 방향이 바뀌면 reverse(기존 행동을 바꾸는 신호), 같으면 same(이어짐). 실패(failed)·신호 없음·직전 신호 없음은 null",
+ "enum": [
+ "reverse",
+ "same",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+}decker.get_market_state3 fields changedOutput schema / properties / timeframes / items / properties / levelsAdded value: +{
+ "description": "주목 가격 — 종가 위·아래 가까운 가격 3개씩 {price, distance_pct, kind}. kind=target(지금 판정 기준)|next_target|connection|candidate",
+ "properties": {
+ "down": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "up": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+}Output schema / properties / timeframes / items / properties / prev_signal / properties / stage / descriptionPrevious value: -"target_selected=대상선정 · pending=판정보류(종가가 신호봉 안) · confirmed=확인(종가가 신호 방향 경계 밖) · failed=실패(반대 경계 밖) · none=신호 없음"New value: +"target_selected=대상선정 · pending=판정보류 · confirmed=확인 · failed=실패 · none=신호 없음"Output schema / properties / timeframes / items / properties / stage / descriptionPrevious value: -"target_selected=대상선정 · pending=판정보류(종가가 신호봉 안) · confirmed=확인(종가가 신호 방향 경계 밖) · failed=실패(반대 경계 밖) · none=신호 없음"New value: +"target_selected=대상선정 · pending=판정보류 · confirmed=확인 · failed=실패 · none=신호 없음"decker.get_engine_state_rawdecker.get_market_state7 fields changedInput schema / properties / events_limitAdded value: +{
+ "default": 10,
+ "maximum": 50,
+ "minimum": 0,
+ "type": "integer"
+}Input schema / properties / symbol / descriptionPrevious value: -"e.g. BTCUSDT"New value: +"e.g. BTCUSDT, XYZ_GOLDUSD"Input schema / properties / timeframe / descriptionAdded value: +"Alias for a single-element `timeframes` (backward compatible)."Input schema / properties / timeframe / enumPrevious value: -[
- "30m",
- "1h",
- "4h",
- "8h",
- "1d"
-]New value: +[
+ "30m",
+ "1h",
+ "4h",
+ "8h",
+ "1d",
+ "1w"
+]Input schema / properties / timeframesAdded value: +{
+ "description": "Subset to return. Omit for all timeframes.",
+ "items": {
+ "enum": [
+ "30m",
+ "1h",
+ "4h",
+ "8h",
+ "1d",
+ "1w"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / requiredPrevious value: -[
- "symbol",
- "timeframe"
-]New value: +[
+ "symbol"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "as_of": {
+ "description": "가장 최근 평가 봉의 마감 시각",
+ "format": "date-time",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "events": {
+ "description": "최근 사건(새것 먼저). 대상선정·신호·신호 결말·연결 도착.",
+ "items": {
+ "properties": {
+ "kind": {
+ "enum": [
+ "target_selected",
+ "signal",
+ "signal_resolved",
+ "conn_arrival"
+ ],
+ "type": "string"
+ },
+ "price": {
+ "description": "signal/signal_resolved=종가 · 그 외=대상 가격",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "side": {
+ "description": "buy=매수 · sell=매도",
+ "enum": [
+ "buy",
+ "sell",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "status": {
+ "description": "signal_resolved 의 결말",
+ "enum": [
+ "confirmed",
+ "failed",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "time": {
+ "format": "date-time",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "timeframe": {
+ "enum": [
+ "1w",
+ "1d",
+ "8h",
+ "4h",
+ "1h",
+ "30m"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "time",
+ "timeframe",
+ "kind"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "missing_timeframes": {
+ "description": "아직 평가값이 없는 시간대",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "price": {
+ "description": "가장 최근 평가 봉의 종가",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "symbol": {
+ "type": "string"
+ },
+ "timeframes": {
+ "description": "상위→단기 순. 각 시간대가 낸 상태를 나란히 — 시간대 간 종합 판정은 없다(종합은 호출자 몫).",
+ "items": {
+ "properties": {
+ "bar_close_time": {
+ "description": "이 시간대의 마지막 평가 봉 마감 시각",
+ "format": "date-time",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "close": {
+ "description": "그 봉 종가",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "confirmed_at": {
+ "description": "결말(확인/실패)이 난 봉 시각",
+ "format": "date-time",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "entry": {
+ "description": "체결 기준 가격 = 신호 시점 종가",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "prev_signal": {
+ "properties": {
+ "side": {
+ "description": "buy=매수 · sell=매도",
+ "enum": [
+ "buy",
+ "sell",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "signal_time": {
+ "format": "date-time",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "stage": {
+ "description": "target_selected=대상선정 · pending=판정보류(종가가 신호봉 안) · confirmed=확인(종가가 신호 방향 경계 밖) · failed=실패(반대 경계 밖) · none=신호 없음",
+ "enum": [
+ "target_selected",
+ "pending",
+ "confirmed",
+ "failed",
+ "none"
+ ],
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "resolved_close": {
+ "description": "결말을 정한 종가",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "side": {
+ "description": "buy=매수 · sell=매도",
+ "enum": [
+ "buy",
+ "sell",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "signal_bar": {
+ "description": "신호봉(판단봉 2) — 종가가 이 범위 밖으로 나가면 확인/실패, 안이면 판정보류",
+ "properties": {
+ "high": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "low": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "time": {
+ "format": "date-time",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "signal_time": {
+ "description": "신호 시각(판단봉 2를 봉인하는 S 봉)",
+ "format": "date-time",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "stage": {
+ "description": "target_selected=대상선정 · pending=판정보류(종가가 신호봉 안) · confirmed=확인(종가가 신호 방향 경계 밖) · failed=실패(반대 경계 밖) · none=신호 없음",
+ "enum": [
+ "target_selected",
+ "pending",
+ "confirmed",
+ "failed",
+ "none"
+ ],
+ "type": "string"
+ },
+ "stop": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "target": {
+ "description": "진입가 대비 2% 이상 거리의 반대 측 확인 신호 경계. 없으면 null",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "target_reason": {
+ "description": "target 이 null 인 이유",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "timeframe": {
+ "enum": [
+ "1w",
+ "1d",
+ "8h",
+ "4h",
+ "1h",
+ "30m"
+ ],
+ "type": "string"
+ },
+ "unit_target": {
+ "description": "이 시간대가 지금 판정 중인 대상 가격",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "unit_target_touch": {
+ "enum": [
+ "break",
+ "inside",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "timeframe",
+ "stage",
+ "side"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "symbol",
+ "as_of",
+ "price",
+ "timeframes",
+ "events",
+ "missing_timeframes"
+ ],
+ "type": "object"
+}decker.get_price_axis_state3 fields changedInput schema / properties / timeframe / descriptionAdded value: +"OMIT for the multi-timeframe view (all TFs side by side) — that is the intended way to read this axis. Pass one TF only when you deliberately want a single horizon."Input schema / properties / timeframe / enumPrevious value: -[
- "30m",
- "1h",
- "4h",
- "8h",
- "1d"
-]New value: +[
+ "30m",
+ "1h",
+ "4h",
+ "8h",
+ "1d",
+ "1w"
+]Input schema / requiredPrevious value: -[
- "symbol",
- "timeframe"
-]New value: +[
+ "symbol"
+]decker.get_price_axis_statedecker.get_trigger_historyDeterministic, receipted digital microservices. Gate A is simulation-only.
Cryptographically anchored evidence for agents: verified run receipts, proof-gated settlement.
Bounded agent exploration with persistent progress, deterministic receipts, and return contracts.
Governed local-first memory and continuity for AI agents — signed receipts, optional hosted lane.
Add one secure layer between your agents and this server.
