Skip to main content
Glama

decker

by io.github.gigshow

decker.place_order

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sideYesOrder direction (buy/long or sell/short).
symbolYesCrypto-6 only for this MCP write path.
notional_usdYesOrder size in USD (quantity = notional_usd / current price). This is the value checked against the account's tier notional cap.

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description fully shoulders the transparency burden. It discloses execution mode resolution (not caller-chosen), kill switch, eligibility caps, authoritative response mode, position netting, and pre_existing_position behavior. This is exemplary for a high-risk mutation tool.

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 single dense paragraph is long but every sentence carries essential safety/behavioral info. It's front-loaded with purpose, but the wall-of-text format could benefit from bullet points or section breaks. Slight deduction for structure, not content.

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

Completeness5/5

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

No output schema exists, yet the description explains critical return behaviors (mode authority, pre_existing_position, netting). It also covers prerequisites, constraints, and failure modes, making it complete for understanding the tool's full context.

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

Parameters5/5

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

Schema already covers parameters 100%, but description adds crucial semantics: notional_usd is checked against tier cap and used for quantity calculation, side enumerations are clarified, and symbol restriction is reaffirmed. This adds significant value beyond the schema.

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 places a market order through Decker's own execution engine, distinguishing it from other tools. It specifies the exact resource (order) and action (place), and explicitly contrasts with siblings that don't move money.

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?

Provides explicit guidance: call decker.validate_intent first, restricted to crypto-6 symbols, and notes that HL-synthetic/KRX symbols are read-only via other tools. This clearly delineates when to use this tool vs alternatives.

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