Skip to main content
Glama

decker

by io.github.gigshow

decker.get_positions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.3/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden for behavioral disclosure. It does add context about data granularity (real vs virtual, live sl_price/tp_price, last 10 round-trips) and labels it as 'actual exposure' vs. recommendations, but it does not explicitly state read-only, permissions, or side effects. This is adequate but not fully transparent.

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?

The description is front-loaded with the core idea ('this user's actual exposure') and is dense but efficient. The Axis③ contextual note adds useful framing without excessive verbosity, though a slightly tighter wording could improve it.

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?

With no output schema, the description sufficiently enumerates the main return categories (real, virtual, closed round-trips per mode) and highlights key fields. It also connects to the wider tool ecosystem via sibling distinctions, making it adequate for a zero-parameter info retrieval tool.

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

Parameters4/5

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

The tool has zero parameters, so the baseline is 4. There are no parameter semantics to clarify, and the description correctly focuses on the returned data instead.

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 identifies the tool as retrieving the user's actual exposure: real open futures positions, virtual paper positions, and closed round-trips. It also explicitly distinguishes this from decker.get_signals, 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.

Usage Guidelines5/5

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

It provides explicit usage guidance: use this before placing another order to avoid duplicate/over-exposure, and to check current protective stop/target. It also contrasts with get_signals, clarifying when NOT 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