Skip to main content
Glama

decker

by io.github.gigshow

decker.get_trigger_history

ACTION axis — actual historical GO triggers (not standing WATCH/HOLD candidates) for a symbol, with entry/target/stop coordinates and realized performance (mfe_pct/mae_pct/exit_reason/exit_price from trigger_performance, null = still open). Distinct from decker.get_signals (which reflects only the current-moment state, not a searchable history — its action_gate filter answers 'what does symbol×tf look like right now', not 'when did this last fire'). Use this to answer 'what did the engine actually trigger recently and at what price' — decker.get_signals/get_market_state cannot answer that. direction is judgment_signals-native vocabulary ("long"/"short"), distinct from the "+"/"-" convention used by other tools — read as-is, no translation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
sinceNoISO8601 lower bound on trigger time (exclusive). Optional.
symbolYese.g. BTCUSDT
timeframeNoOptional — omit for all timeframes.

TDQS

A4.3/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All decker toolsInspect
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.3/5.0
Disambiguation3/5

Execution and settings tools are clearly separated, but there is a dense cluster of analytical getters (get_view, get_reading, get_signals, get_assembly) that all return market verdicts and coordinates; their boundaries are only clear after reading the long descriptions. get_market_state versus get_state_timeline is cleaner, but the overlap among the analysis-verdict tools could still cause misselection.

Naming Consistency5/5

All tools share the decker_ prefix and a consistent snake_case verb_noun pattern (get_* for reads, place_order/close_position/update_protective_stops/set_skill_overlay/validate_intent for actions). There is no mixing of naming conventions or vague generic verbs.

Tool Count5/5

Thirteen tools is within the ideal well-scoped range for an execution-plus-analysis server. Each tool maps to a distinct responsibility (state reading, timeline history, signals, execution, position management, user settings, pre-trade validation), so none feels like filler.

Completeness4/5

The lifecycle is well covered: validate_intent → place_order → get_positions → update_protective_stops → close_position, with signal/analysis and skill-overlay tools around it. Minor gaps like a dedicated account-balance or full order-history tool are absent, but the execution engine handles caps server-side and closed round-trips are included in get_positions.

Resources