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).
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.2/5 across 13 of 13 tools scored. Lowest: 2.3/5.
Tools are generally distinct: get_market_state, get_reading, get_view, and get_state_timeline all provide market state/reading but with clear delineation (raw vs interpreted, current vs timeline). get_signals vs get_positions are clearly separated by axis. The main overlap is among get_market_state, get_reading, get_view, and get_signals, which all offer market state but the descriptions explicitly differentiate them (raw vs synthesized, engine-native vs customer-facing, signals vs view). Slight ambiguity between get_reading and get_view—both are customer-facing interpretations, though get_view is described as the same composed card as the daily briefing, while get_reading is a broader market reading. Acceptable.
Naming mostly follows a consistent verb_noun pattern (get_, place_, close_, update_, set_, validate_). All tool names start with a verb, with get_ dominating. Minor deviations: tool names like get_assembly, get_state_timeline, get_user_skills are consistent. But close_position and update_protective_stops are more specific than the get_ prefix. No mixed case or chaotic patterns. Minor inconsistency: 'user_skills' vs 'skill_overlay' (get_user_skills vs set_skill_overlay), slightly different noun forms.
13 tools for a trading/analysis server is well-scoped. The set covers analysis (get_assembly, get_market_state, get_state_timeline, get_reading, get_view, get_signals), user management (get_user_skills, set_skill_overlay), execution (place_order, close_position, update_protective_stops), and safety (validate_intent). This is a reasonable breadth for the domain, not bloated, and each tool appears to have a purpose.
The tool surface covers the core lifecycle: get signals/state, validate intent, place order, close position, update protective stops. There is no explicit get_order_history or get_specific order details, but get_positions returns last 10 closed round-trips. Also missing a cancel_order, but the description explicitly justifies why (market orders only). Notable gap: no tool to manage risk parameters beyond protective stops (e.g., position size limits), but for a trading server the main flows are covered. Slight gap could be ability to get detailed historical performance beyond last 10 closed, but acceptable.
decker.close_positionAInspectAxis③ (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.
decker.get_assemblyAInspectMulti-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.
decker.get_market_stateBInspectMarket 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). 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.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | e.g. BTCUSDT | |
| timeframe | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies read-only behavior through phrases like 'zero recompute' and 'persisted engine emit read as-is', but it never explicitly states that the tool has no side effects or side-effect-free nature. Some behavior is disclosed (e.g., null on non-trigger bars), but overall transparency is limited.
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 verbose, repetitive, and poorly structured. It cycles through the same explanations about the game block and anchor concepts multiple times, mixing domain jargon with technical details. This makes it difficult to parse and unnecessary for a tool definition.
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 that no output schema is provided, the description attempts to explain the structure of the returned state (e.g., game.status, game.target, etc.), which is helpful. However, it lacks a clear, organized summary of the full output shape and misses edge cases like error responses. The completeness is average.
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 add meaningful semantics for the parameters 'symbol' and 'timeframe' beyond what the schema provides. The schema already includes an enum for timeframe and an example for symbol, but the description repeats them without deeper explanation, failing to improve parameter understanding.
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 that it returns the current engine structural state for a symbol/timeframe, with specifics like 'latest evaluated bar' and 'persisted engine emit read as-is'. This effectively communicates the tool's core purpose and differentiates it from similar state-related tools.
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 alternative tool suggestions ('use decker.get_view (with tf) or decker.get_reading' for human-language views) and a critical instruction to check intent with decker.validate_intent before placing orders, which helps when to use this tool versus related ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
decker.get_positionsAInspectAxis③ (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.
decker.get_readingCInspectAI-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.
decker.get_signalsAInspectActive trading signals for the current user (with Skill Overlay applied), in customer-facing shape: coordinates (entry/target/stop), decision (ENTER/WAIT/SKIP), 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. 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 provided, the description carries full responsibility for behavioral disclosure and excels: it explains risk_reward_ratio is computed on displayed coordinates after overlay, signals are retained rather than cut (turn-retention policy) with freshness fields to read, object_context has internal reason codes scrubbed (pointing to decker.get_market_state), and reverse_direction_conflict only appears under specific conditions. It also warns against misinterpreting action_gate as an order command, all without contradicting any annotations (since none exist).
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 structured and information-dense. It front-loads the core purpose (active signals with overlay, list of components), then layers specifics about risk_reward_ratio, retention policy, object_context, null conditions, and ends with safety guidance. Every sentence adds value, though it could be slightly trimmed without losing essential detail, making it concise relative to the tool's 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 the complexity (no output schema, 5 parameters, 12 siblings), the description is quite complete: it explains the return shape (coordinates, decisions, gates, progress, MTF verdict, summary_ko), covers filtering, aliasing with other tools, edge cases (null, aged rows, reverse conflicts), and safety mandates. Missing are explicit semantics for the limit parameter and details on result ordering/pagination, but these are minor given the tool's richness.
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 80% (4 of 5 params described), so baseline is 3, but the description adds substantial meaning: it explains that timeframe can yield opposite directions on different horizons and flags other_horizon_conflict, clarifies action_gate grammar and exclusion of rows with no gate, and specifies symbols filter usage. The limit parameter lacks a description in both schema and description, which is a minor gap, but the added context for other params justifies a 4.
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 returns active trading signals for the current user, with specific customer-facing shape (coordinates, decision, action_gate, progress, MTF verdict, summary_ko). It distinguishes itself from siblings by explicitly mentioning alternatives like decker.get_assembly for cross-horizon judgment and decker.get_market_state for internal reason codes, making its scope distinct.
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 guidance: it advises using decker.get_assembly for composed cross-horizon judgment, instructs to read freshness_state before treating old rows as current, and mandates checking decker.validate_intent before placing orders. It also clarifies when null is returned (non-trigger bars, outside narrative universe) and that action_gate is a stance not an order command, giving clear context for when and 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.
decker.get_state_timelineAInspectMarket 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.
decker.get_user_skillsAInspectTrading skill catalog + currently active overlay for this user. Returns 3 base skills (conservative_v0/standard_v0/aggressive_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?
With no annotations, the description bears the burden. It clearly states the return values (3 base skills and the selected one). As a parameterless getter, no side effects are expected, and the description is adequate for the tool's simplicity.
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 concise sentence (21 words) that communicates the tool's purpose and output without unnecessary words. It is front-loaded and efficient.
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 parameterless tool with no output schema, the description fully explains what is returned (3 base skills and the active overlay). It provides sufficient context for an agent to understand the tool's output.
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?
There are zero parameters, and schema description coverage is 100%. The description does not need to elaborate on parameters; the baseline of 4 applies, and it adds context about the return values.
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 explicitly states the tool returns a 'Trading skill catalog' and the 'currently active overlay', listing the three base skills. This clearly identifies the resource and action, distinguishing it from sibling tools like get_assembly 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 implies usage context (viewing skills and current overlay) but does not provide explicit guidance on when to use this tool versus alternatives like set_skill_overlay. Usage is implied but not formally stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
decker.get_viewAInspectThe 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.
decker.place_orderAInspectAxis③ (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.
decker.set_skill_overlayAInspectChange 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.
decker.update_protective_stopsAInspectAxis③ (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.
decker.validate_intentAInspectPre-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. 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?
Since no annotations are provided, the description carries the full burden. It explicitly discloses that the tool does NOT approve/reject (returns engine gate and side_alignment), states that covered=false means unknown, and mentions persistence to a decision ledger. It also explains subtle behavioral aspects like reverse_direction_conflict warnings and null object_context, which is valuable transparency. Minor gap: does not explicitly state whether it may be slow or has side effects, but it does cover core behaviors.
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 packed with useful information, but it is long (around 150 words) and covers multiple complex topics. It is front-loaded with the core purpose, which is good, but the later parts (object_context lineage) are dense and could be simplified or moved to tool output documentation. It earns its place but could be more elegantly structured; however, given the tool's complexity, the length is 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 there is no output schema and no annotations, the description does a good job explaining what the tool returns (stance reading, side_alignment, covered flag, check_id) and how to interpret null object_context and reverse_direction_conflict. It covers key edge cases (covered=false semantics) and provides a complete workflow integration note (call before orders, records to ledger). It lacks explicit mention of error conditions or rate limits, but for a gate check tool, this is fairly complete. The absent output schema makes the description the only source for return semantics; while it covers most, it could be slightly richer on exactly what fields appear in the stance reading.
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 already provides 100% coverage for all four parameters with detailed enums and descriptions (symbol aliases, side, timeframe precedence, order_type informational). The description adds context on how timeframe falls back to position TF / assembly TF / engine default, and clarifies that order_type is recorded but does not change the verdict, which goes beyond the schema. This is a case of high schema coverage, so a baseline 3, but the description adds meaningful extra semantics, warranting a 4.
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 'Pre-trade gate check' for a proposed order intent, and specifies it should be called BEFORE placing orders, distinguishing it from other Decker tools. It details what it checks (engine action_gate, structural state, signal direction) and the return vocabulary. The scope (per-symbol, state-aware) and its placement in the workflow are explicit, effectively distinguishing it from siblings like get_market_state or place_order.
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 call this BEFORE placing any order through execution tools (e.g., broker MCP's review→place flow), and clarifies that it returns a stance, not an approval/rejection. It gives an explicit exclusion (covered=false means unknown, not HOLD) and discusses object_context nuances, giving the agent clear when-to-use guidance. Although it does not mention alternatives like decker.get_market_state, it clearly specifies the sequencing and decision responsibility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!
