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).
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'.
| 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 the full behavioral burden and excels. It discloses the deterministic nature, the TF hierarchy (upper supplies target, lower supplies entry), and provides a crucial warning that grade='aligned' does not mean all timeframes are GO, explaining what 'aligned' actually means. This goes well beyond a generic read.
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 efficiently structured: a summary line, a dash-separated list of output components, a clear directive, and a warning. Every sentence earns its place, and the length is justified by the need to prevent misinterpretation of 'aligned'.
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?
Even without an output schema, the description enumerates all output components, explains the TF logic, and references matrix_summary[].gate for per-TF status. For a tool with one optional parameter and no output schema, this is fully self-contained.
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 covers the single symbol parameter at 100%, so the baseline is 3. The description adds valuable alias examples (BTC, 비트코인, GOLD, 테슬라) and clarifies the omit-symbol behavior for all 14 universe symbols, slightly exceeding the schema's 'Optional symbol or alias'.
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 uses a specific verb ('assembly') and names the resource ('multi-timeframe optimal-path per symbol'). It enumerates the exact outputs (direction, grade, entry, stop, target, RR, switch coordinate) and explicitly calls itself 'the single judgment authority,' which sharply distinguishes it from siblings like get_signals or get_market_state.
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 tells the agent when to use this tool ('This is the single judgment authority — narrate or filter it, do not re-decide coordinates') and gives a practical usage note for omitting the symbol to get all 14 symbols. However, it does not explicitly name alternatives for other contexts, so it misses the top score for explicit when-not/alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Market State v0 — current engine structural state for a symbol/timeframe (latest evaluated bar, persisted engine emit read as-is, zero recompute). DOMAIN FRAME (why this engine exists): the market is read as a TARGET GAME — every coordinate comes from a verified anchor (a past level where a triggered move actually succeeded). The game block tells you the context that matters: game.status = forming_target (new anchor set, awaiting test) | testing_target (price is testing whether the declared target holds) | direction_resolved (game decided, price traveling); game.target = WHO is being judged (anchor id/phase/band); game.progress_dest = where price goes if the move proceeds (the opposing verified anchor to conquer); game.reverse_dest = where it goes if the move fails (the opposite house — also the stop logic's home); game.why_gate = full gate derivation chain; game.zt_regime = output canonicality (restored = deterministic delta lineage). action_gate alone (GO/WATCH/HOLD) is only a posture — the game context is the information. RAW CONTRACT: fields are engine-native vocabulary (c_state, hold_reason, R_* risk enums …), NOT customer-facing prose — for a human-language view use decker.get_view (with tf) or decker.get_reading. layer=STATE: this is a market-state reading, NOT a trade instruction. Absent fields are null (engine did not emit that axis — no filling). IMPORTANT: top-level state.c_state/action_gate/trigger_kind reflect the TRIGGER SNAPSHOT (only populated on a bar that actually had a trigger event) — null on most bars is normal, not a data gap. For the always-present, every-bar-populated view of the same axes use game.phase.c_state / game.phase.action_gate instead (different freshness, same underlying engine state machine). Don't read a null top-level field as 'engine has no state' — check game.phase first. object_context (top-level, W1-C1 standard object block, present when a recent trigger bar exists): my_anchor/opp_anchor(reversal destination)/judgment_ref/geometry/why(engine reason_codes)/reverse_branch context (object_context.reverse_direction_conflict is present only when a local reversal shows stage='confirmed' but the swing's confirmed direction still disagrees — read it before treating reverse_branch.stage='confirmed' as a swing-level reversal). null on non-trigger bars or symbols outside the narrative universe (e.g. individual KRX stocks). current_price (top-level, 2026-09-03): {price, bar_ts} — the single latest completed-bar close for this symbol ACROSS ALL timeframes (not just the requested tf), useful when comparing multiple timeframes' target bands against one 'now' price. null for KRX individual-stock symbols. Before placing any order through any execution tool, check the intent with decker.validate_intent.
| 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 full burden, and it excels: zero recompute, read-as-is persisted emit, null semantics explained as normal rather than data gaps, KRX stock exceptions, and cross-timeframe current_price behavior. It also discloses the object_context conflict condition and warns about validate_intent before ordering.
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 opening sentence is front-loaded and gives a good summary, but the description is very long and dense, with a large DOMAIN FRAME digression and heavily nested parentheticals. The details are valuable, but the structure could be tighter without losing meaning.
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?
Without an output schema, the description thoroughly documents the important output blocks, field semantics, null behavior, freshness differences, and cross-references to validate_intent. This is about as complete as a description of a complex state-tool can reasonably be.
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 covers symbol with an example and timeframe via enum, and the description does not add significant parameter-level meaning. It refers to 'requested tf' and symbol context, but the input parameters are simple enough that the schema plus a small reference is nearly adequate.
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 this is a read-only retrieval of 'current engine structural state for a symbol/timeframe' with a specific verb and resource. It does not explicitly name sibling tools to differentiate, but the 'persisted engine emit read as-is, zero recompute' framing helps separate it from signal/reading getters.
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 solid context for when fields are populated (trigger bars, non-trigger bars, KRX exclusions), and explicitly says to use game.phase for always-present state and to check validate_intent before orders. However, it does not directly say when to use get_market_state versus get_reading/get_signals/get_assembly.
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.
AI-synthesized market reading for a symbol/timeframe, in customer-facing language: current state description, directional bias scores, bidirectional break targets, MTF verdict per timeframe, and an execution hint (stance + long/short setups). Engine-native raw fields are NOT exposed here — use the REST raw contract (GET /public/reading) or decker.get_market_state for those — except object_context (W1-C1 standard object block, explicit exception: my_anchor/opp_anchor/judgment_ref/geometry/reverse_branch + why limited to action_gate/trigger_kind (internal reason codes scrubbed on this customer surface), present when a recent trigger bar exists, null otherwise incl. individual KRX stocks). object_context.reverse_direction_conflict is present only when a local reversal shows stage='confirmed' but the swing's confirmed direction still disagrees — read it before treating reverse_branch.stage='confirmed' as a swing-level reversal. execution_hint.preferred_direction is derived from key_direction alone and is NOT guaranteed to have a matching long_setup/short_setup (they come from an independent break-target resolver) — check that the setup for the preferred side is non-null before treating preferred_direction as an actionable side.
| 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?
The description explains certain output semantics (e.g., reverse_direction_conflict, preferred_direction derivation) which adds transparency about the meaning of fields. However, it does not disclose any side effects, permissions, rate limits, or error conditions. Since no annotations are provided, the description carries the full burden, and it only partially addresses behavioral aspects.
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 excessively long and repetitive, with dense technical jargon like 'W1-C1 standard object block' and long clauses about internal logic. It reads as a wall of text rather than a clear, structured summary. Key information is buried, and the description would benefit from a concise overview followed by details.
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 is incomplete in that it does not cover input parameter usage or provide a clear usage context. It does explain some output field semantics, which helps, but the lack of guidance on when to use the tool and what the parameters mean leaves significant gaps. The description focuses excessively on output details while neglecting the overall context.
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 description does not explain any of the input parameters (symbol, tf, include_tfs). While the schema provides minimal examples (e.g., 'e.g. BTCUSDT'), the description adds zero value to parameter understanding. The schema coverage is 67% but only with examples, not meaningful descriptions. With no added clarification, parameter semantics are severely lacking.
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 it provides an 'AI-synthesized market reading' with customer-facing language, which clearly identifies the tool's purpose. It distinguishes itself from raw data tools by mentioning 'Engine-native raw fields are NOT exposed here' and referencing alternatives like decker.get_market_state. However, the distinction is buried in verbose output details, so it's not maximally clear.
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 lacks explicit guidance on when to use this tool versus siblings. It mentions using 'the REST raw contract or decker.get_market_state' for raw fields, but that's about output content, not tool selection. There is no statement like 'use this when you need a customer-friendly summary' or 'use get_market_state for raw data.'
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. object_context (W1-C1 standard object block, present when a recent trigger bar exists): my_anchor / opp_anchor (reversal destination) / judgment_ref / geometry / why (action_gate + trigger_kind only — internal reason codes are scrubbed on this customer surface, use decker.get_market_state for those) / reverse_branch context (object_context.reverse_direction_conflict is present only when a local reversal shows stage='confirmed' but the swing's confirmed direction still disagrees — read it before treating reverse_branch.stage='confirmed' as a swing-level reversal). null on non-trigger bars or symbols outside the narrative universe (e.g. individual KRX stocks). Before placing any order through any execution tool, check the intent with decker.validate_intent.
| 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?
With no annotations, the description carries full behavioral burden and delivers: decision semantics (WAIT/SKIP standing candidates, not executed triggers), action_gate as a stance rather than order command, risk_reward computed on displayed post-overlay coordinates, turn-retention policy with freshness_state/age_bars/freshness_sec, and null behavior for non-trigger bars or symbols outside the narrative universe. It even flags the reverse_branch nuance before treating stage='confirmed' as swing-level.
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 extremely dense and front-loaded with the core purpose, and every sentence earns its place for such a complex tool. However, it is a single long paragraph with many caveats, so it could be improved with breaks or bullet-like separation for faster agent scanning.
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 is sufficient to call the tool correctly: it lists the returned field groups, explains freshness/retention, defines null cases, flags cross-horizon conflicts, and points to the right sibling tools for missing internal details. An agent has enough context to decide when to invoke it and interpret results.
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?
While schema description coverage is already high (80%), the description adds material meaning beyond the schema: action_gate filters current representative state and excludes rows with no gate; timeframe rows can hold opposite directions with other_horizon_conflict; and symbols outside the narrative universe are null. It clarifies semantics that raw enum/schema cannot convey.
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 resource ('Active trading signals for the current user') with Skill Overlay and a precise output shape (coordinates, decision, action_gate, progress, MTF verdict, summary_ko). It also differentiates from siblings by explicitly routing historical GO events to get_trigger_history, internal reason codes to get_market_state, and cross-horizon judgment to get_assembly.
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 when/when-not guidance: action_gate filters the current-moment representative state, not history, and past GO events should use get_trigger_history. It also says to prefer get_assembly instead of guessing a timeframe, and to check decker.validate_intent before placing orders.
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 (same schema as decker.get_market_state, except each item carries a SLIM game tag {status, target_id, zt_regime, provenance} instead of the full game block — read status transitions across bars to see how the target game unfolded (forming → testing → resolved/failed); ascending by bar_ts). Bars the engine did not emit are simply absent (honest gaps, no filling).
| 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 are provided, so the description must carry the full burden. It discloses that bars are ascending by bar_ts and that missing bars are absent (honest gaps). However, it does not mention whether the tool is read-only, authentication requirements, or any side effects. Given the lack of annotations, this is adequate but not comprehensive.
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 paragraph that front-loads the tool's name, purpose, and key differentiating points. It is reasonably concise, but could be slightly tighter by removing the parenthetical note about ascending order, which is implied by 'timeline'.
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 lack of an output schema, the description provides a good overview of the output structure (SLIM game tag, ascending order, honest gaps). It references another tool's schema for comparison, adding context. However, it does not explain pagination or the behavior of the 'limit' parameter, which limits completeness.
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 50%, and the description does not add any parameter-specific details beyond what is in the schema. For example, it does not explain the 'limit' or 'since' parameters or how they affect results. The description focuses on output structure rather than parameter usage.
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 is a 'per-bar state timeline for a symbol/timeframe' and distinguishes itself from a sibling tool (decker.get_market_state) by noting a different schema (SLIM game tag vs full game block). The verb 'get' combined with 'state_timeline' makes the tool's purpose specific and actionable.
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 to 'read status transitions across bars to see how the target game unfolded (forming → testing → resolved/failed)', providing a clear use case. It also notes that missing bars are absent, which guides interpretation. However, it does not explicitly state when not to use this tool or mention alternatives beyond the sibling comparison.
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 the full burden, and it delivers: it clarifies these are actual GO triggers rather than standing candidates, explains that null performance fields mean 'still open', and flags that direction uses 'long'/'short' vocabulary and must be read as-is. This goes well beyond a generic 'get history' statement.
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 and front-loaded with the core purpose, and most clauses earn their place (field semantics, sibling distinction, vocabulary warning). It is slightly repetitive in saying both 'Distinct from decker.get_signals' and 'get_signals/get_market_state cannot answer that', but overall it is efficient for the complexity.
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, the description compensates by listing the meaningful returned fields and their semantics (null = still open, no direction translation) and by covering when to use the tool. It does not describe the overall return structure, ordering, or limit behavior, but those are minor for a history-query tool with a well-covered 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 75%, so the schema already documents symbol, since, and timeframe; the description adds no further input-parameter meaning. The direction vocabulary note relates to returned data, not to the four input parameters, 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 opens with a specific definition: 'ACTUAL historical GO triggers (not standing WATCH/HOLD candidates) for a symbol', and enumerates the returned content (entry/target/stop, mfe/mae, exit_reason/exit_price). It also distinguishes itself from decker.get_signals and decker.get_market_state, so an agent can tell exactly what this tool uniquely provides.
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 an explicit use case: "Use this to answer 'what did the engine actually trigger recently and at what price'" and states that decker.get_signals/get_market_state cannot answer that. It also contrasts historical searchability with get_signals' current-moment action_gate view, which is exactly the kind of when-to-use guidance needed.
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 burden. It does disclose the exact returned content (8 published skills plus the active selection), which is helpful. However, it does not explicitly state that this is a non-mutating read, how freshness works, or what happens when no skill is selected.
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 entire description is one efficient, front-loaded sentence. The exact skill list adds useful precision without unnecessary length, and every phrase earns its place.
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 output schema, the description gives the agent a clear expectation of both the fixed catalog and the active overlay. It could be slightly more explicit about the return shape of the 'selected one,' but this is a minor gap.
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 and 100% schema coverage, so there is nothing for the description to add about arguments. The baseline of 4 applies because the schema fully covers this dimension.
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 uses a precise verb and resource: 'Returns 8 published skills... and the user's selected one.' It enumerates every skill name, making the tool's purpose concrete and unambiguous, and it is clearly distinct from mutation siblings like set_skill_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 description implies a read-only catalog/overlay use case but gives no explicit guidance about when to use this tool versus alternatives such as set_skill_overlay or get_reading. It lacks any when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The engine's VIEW for a symbol — the same composed card the daily briefing sends (single composer, verbatim): overall verdict, big/main timeframe alignment, the current game narrative in plain language, coordinates (baseline ref_price / target / invalidation), 'at this price, this view', and recent self-scoring verdicts (receipts). layer=STATE_VIEW: a market-state reading, NOT a trade instruction. Prefer this over get_market_state when you want the interpreted view instead of raw engine fields. object_context (W1-C1 standard object block, present when a recent trigger bar exists): my_anchor/opp_anchor(reversal destination)/judgment_ref/geometry/why(action_gate+trigger_kind only, reason codes scrubbed on this customer surface)/reverse_branch context (object_context.reverse_direction_conflict is present only when a local reversal shows stage='confirmed' but the swing's confirmed direction still disagrees — read it before treating reverse_branch.stage='confirmed' as a swing-level reversal). null on non-trigger bars or symbols outside the narrative universe. Before placing any order through any execution tool, check the intent with decker.validate_intent.
| 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?
With no annotations, the description carries full behavioral disclosure. It extensively describes output components (verdict, alignment, narrative, coordinates), states 'NOT a trade instruction', explains null cases, details object_context fields, and warns about reverse_branch conflicts. This is exemplary transparency beyond 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?
Although long, every sentence adds unique information. It front-loads the core purpose, then details output structure, then provides usage distinctions and caution. No fluff; dense but well-organized. The length is justified by the tool's complexity and the absence of annotations.
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 fully explain return semantics. It enumerates the vew's contents, defines null conditions, details object_context fields and reverse_branch logic, and references sibling tool validate_intent. This provides complete context for an agent to use the tool 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 100%, so baseline is 3. However, the description adds meaningful context: for 'tf' it explains the timeframe semantics ('grounded narrative is composed on this TF's bar') and provides default behavior ('Omit for the engine's default action TF...'). For 'symbol' it gives examples and coverage caveats. This exceeds 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?
The description clearly states the tool's purpose: 'The engine's VIEW for a symbol' and explicitly differentiates it from get_market_state by saying 'Prefer this over get_market_state when you want the interpreted view instead of raw engine fields.' It also names the specific resource (symbol) and output composition, making it unmistakable.
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 provides when-to-use guidance: 'Prefer this over get_market_state...' and warns before trading: 'Before placing any order through any execution tool, check the intent with decker.validate_intent.' Also notes conditions for null returns (non-trigger bars), giving clear usage context.
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 bears full burden. It discloses that the change is immediate and affects subsequent calls, but does not specify reversibility, error behavior, or whether other tools are also affected.
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, no wasted words. Front-loaded with the action and provides a clear effect statement.
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 mutation with one parameter and no output schema, the description sufficiently explains what the tool does and its impact. Missing details about error cases or default behavior but overall adequate.
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 the description adds no extra detail beyond what the schema provides for the single parameter skill_id. Baseline score 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?
The description clearly states the verb 'Change' and the resource 'active trading skill overlay'. It distinguishes from sibling tools which are primarily getters and validators, making this the only tool for setting overlays.
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 mentions that changes immediately affect get_signals calls and downstream channels, implying when to use. However, it does not specify prerequisites (e.g., authentication), when not to use, or alternatives from siblings.
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). signal.object_context (W1-C1 standard object block, present when a recent trigger bar exists): my_anchor/opp_anchor(reversal destination)/judgment_ref/geometry/why(action_gate+trigger_kind only, reason codes scrubbed)/reverse_branch context (object_context.reverse_direction_conflict is present only when a local reversal shows stage='confirmed' but the swing's confirmed direction still disagrees — read it before treating reverse_branch.stage='confirmed' as a swing-level reversal) — null when there is no active signal or no trigger bar.
| 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 full disclosure burden and excels: it explicitly states it returns a stance, not an approval; explains 'covered=false means ... treat as unknown, not as HOLD'; and details top-level action_gate null semantics with 'gate_null_reason' distinguishing 'no_gate_available' vs 'signal_stale.' It also reveals persistence of every check to an auditable ledger (check_id) and warns about reverse_direction_conflict. This is far more than a typical description and prevents many misinterpretations.
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 and dense, but it front-loads the purpose and timing in the first two sentences, then methodically addresses critical edge cases: covered=false versus HOLD, null action_gate with gate_null_reason, the non-authoritative stance, the ledger persistence, and object_context nuances. Every sentence earns its place by clarifying a distinct behavior that could otherwise be misread. It is not merely verbose; it is information-dense. A slight deduction for a single unwieldy final block that could be structured into clearer sub-bullets.
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 there is no output schema, the description must and does explain the full range of response semantics: the stance vocabulary, side_alignment, coverage flag, null action_gate with its two reasons, and the entire signal.object_context structure, including the obscure reverse_direction_conflict condition. It even specifies when object_context is null. This fully equips an agent to call the tool and correctly interpret any permitted response. Nothing needed for correct invocation or understanding 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 coverage is 100% and each parameter (side, symbol, timeframe, order_type) already has a detailed schema description, including alias resolution and timeframe precedence. The main description adds the conceptual role of symbol+side in the gate check and references how the timeframe default is derived, but these are already present in the schema. Thus the description adds modest incremental value beyond the structured fields, meeting the baseline for high-coverage schemas.
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 tool as a 'Pre-trade gate check for a proposed order intent' with the explicit purpose of validating symbol and side against Decker's deterministic market state. It distinguishes itself from order execution by stating 'Call this BEFORE placing any order' and clarifies it returns 'a stance reading, NOT an approval or rejection,' separating it from decision-making and state-query tools. This is a specific verb+resource with unambiguous contrast to siblings.
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 an explicit temporal context: 'Call this BEFORE placing any order through any execution tool,' including an example flow ('a broker MCP's review→place flow'). It also sets boundaries on result interpretation: 'NOT an approval or rejection' and 'the order decision and responsibility remain with the calling agent/user.' While it doesn't enumerate alternative sibling tools to avoid, the when-to-use is unambiguous. A deduction for not naming explicit exclusion or alternative tools for other needs.
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. Dates show when Glama detected each change.
decker.get_trigger_historydecker.update_protective_stopsdecker.get_signals1 field changedInput schema / properties / timeframe / descriptionPrevious value: -"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)."New value: +"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."decker.validate_intent1 field changedInput schema / properties / timeframe / descriptionPrevious value: -"Gate horizon. Omit = the active signal's timeframe if one exists, else the engine's default action TF (4h)."New value: +"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)."decker.close_positiondecker.get_positionsdecker.place_orderdecker.get_assemblydecker.get_market_statedecker.get_readingdecker.get_signalsdecker.get_state_timelinedecker.get_user_skillsdecker.get_viewdecker.set_skill_overlaydecker.validate_intentClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Each tool targets a distinct purpose: state readings (raw vs. view vs. AI-synthesized), signals vs. historical triggers, execution (place/close/update stops), pre-trade validation, and skill management. Cross-references between tools (e.g., get_signals vs. get_trigger_history) explicitly clarify boundaries, leaving no ambiguity about which tool to call.
All tools follow a consistent verb_noun pattern with the 'decker.' prefix: get_* for reads, place/close/update for actions, set_* for settings, and validate_* for checks. This uniformity makes the tool surface predictable and easy to navigate.
14 tools is well-scoped for a comprehensive trading engine MCP, covering state observation, signal generation, execution, risk management, and user configuration. Each tool earns its place and there are no redundant or missing core functions.
The tool surface covers the full trading lifecycle: reading market state (multiple layers), obtaining signals and historical triggers, checking positions, opening/closing positions, updating protective stops, validating intent before orders, and managing skill overlays. The absence of a cancel_order tool is explicitly justified (only market orders), and the domain shows no obvious gaps.