Decker

decker.get_market_state

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

Input Schema

TableJSON Schema

Name	Required	Description	Default
`symbol`	Yes	e.g. BTCUSDT
`timeframe`	Yes

TDQS

A4.2/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden and does so thoroughly. It discloses it's read-only (zero recompute), returns engine-native vocabulary (not customer-facing prose), explains null handling (absent fields are null, top-level fields only on trigger bars), and clarifies the difference between top-level and game.phase fields. It also warns about object_context null conditions. This is exemplary 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.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely verbose, containing multiple sections (DOMAIN FRAME, RAW CONTRACT, IMPORTANT, etc.) with dense jargon. It is not front-loaded; the essential purpose is only in the first sentence, but the rest is a long domain dissertation. While information-rich, it overwhelms the agent and could be significantly pruned without losing critical value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema, the description does a strong job of explaining the return structure: it describes game fields, top-level fields, object_context, and even provides interpretation guidance (nulls are normal, check game.phase). It also points to validate_intent for order flow. It's complete for a complex tool, though the verbosity slightly hurts clarity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50% (symbol has a description, timeframe only an enum). The description adds no parameter-specific meaning beyond what the schema provides. It mentions 'symbol/timeframe' generically but doesn't elaborate on formats, constraints, or how they affect the output. Given the low coverage, the description should compensate but doesn't.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns the current engine structural state for a symbol/timeframe (latest evaluated bar, persisted engine emit read as-is, zero recompute). It explicitly distinguishes from siblings like decker.get_view and decker.get_reading, which provide human-language views. The verb-resource pair 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.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly tells when not to use this tool: 'for a human-language view use decker.get_view (with tf) or decker.get_reading.' It also advises checking intent with decker.validate_intent before placing orders, and clarifies that this is a market-state reading, not a trade instruction. This gives clear routing to alternatives and expected usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Decker tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness5/5

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.

Resources

Need Help?