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.3/5 across 9 of 9 tools scored.
Each tool serves a distinct purpose: assembly, raw state, synthesized reading, active signals, timeline, skills, view, skill overlay, and validation. Even though some provide market state, they are clearly differentiated by raw vs. synthesized vs. view vs. timeline, and descriptions emphasize their unique roles.
All tool names follow a consistent verb_noun pattern using underscores: get_*, set_*, validate_*. The naming is predictable and unambiguous across the entire set.
9 tools is well-scoped for a market analysis and validation server. Each tool covers a necessary function without redundancy, and the count is within the ideal 3-15 range.
The tool surface covers the full lifecycle: reading market state (multiple views), retrieving signals, managing user skills, and validating trade intents. There are no obvious gaps for its intended purpose of analysis and pre-trade validation.
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.
| 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?
No annotations provided, but the description fully explains the output fields (direction, grade, entry, stop, target, RR, conditional switch) and the decision logic (upper TF target, lower TF entry). It is read-only in nature, though not explicitly stated.
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?
Compact two-sentence description, front-loaded with purpose. While dense, every phrase adds value. Could be slightly more structured for easier parsing.
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, the description adequately explains the return values and their significance. It covers the key aspects of the assembly process, though lacks detailed structure of the 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?
With 100% schema coverage, the description adds meaningful context: explains the effect of omitting symbol (returns all 14 symbols) and allows aliases, going beyond the schema's basic description.
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's function: 'Multi-timeframe optimal-path assembly per symbol', and distinguishes it from siblings by calling it the 'single judgment authority' and instructing not to re-decide coordinates.
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?
Provides clear when-to-use guidance: for the machine verdict combining all timeframes. Includes explicit instructions: 'narrate or filter it, do not re-decide coordinates' and 'omit symbol for all 14 universe symbols'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
decker.get_market_stateAInspectMarket 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). 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?
With no annotations provided, the description carries full burden and is transparent about behavior: zero recompute, absent fields return null, the output is a snapshot of persisted engine state. It also notes that fields like c_state, hold_reason, R_* risk enums are engine-vocabulary.
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 structured with sections (DOMAIN FRAME, RAW CONTRACT, layer=STATE) and front-loads the purpose. However, it is verbose and includes some redundant context (e.g., 'action_gate alone...') that could be trimmed for clarity.
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 and absence of output schema or annotations, the description is fairly complete. It explains the domain context, warns about null fields, and contrasts with sibling tools. However, it lacks an exhaustive list of returned fields and a concrete example.
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 50% (only symbol has a brief description). The description mentions symbol/timeframe in passing but adds no additional semantic detail beyond what the schema provides (enum for timeframe). No examples or formats are given, failing to compensate for the low schema coverage.
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 returns current engine structural state for a symbol/timeframe, with 'zero recompute'. It distinguishes from siblings by contrasting with decker.get_view and decker.get_reading, and explicitly labels the output as 'NOT a trade instruction'.
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: for human-readable views use decker.get_view or decker.get_reading, and before placing orders check intent with decker.validate_intent. It also warns the output is engine-native, not customer-facing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
decker.get_readingAInspectAI-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.
| 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?
Despite no annotations, the description comprehensively lists the output components and clarifies it returns AI-synthesized, customer-facing data. It does not explicitly state that it is a read-only operation, but the name and context imply as much. Provides good transparency without contradictions.
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 concise, well-structured sentences. First sentence front-loads the primary purpose and output components; second sentence sets boundaries with alternatives. No extraneous information.
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 (multiple output fields, multi-timeframe support) and lack of output schema, the description sufficiently outlines what is returned. Could briefly mention response format or preconditions, but overall adequate for agent understanding.
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 67% (high but not >80%), and the description does not add parameter details beyond what the schema already conveys (e.g., symbol example, tf enum, include_tfs description). Parameter understanding is adequate but not enhanced by description.
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?
Clearly states the tool provides an AI-synthesized market reading in customer-facing language, detailing specific output components (state description, bias scores, break targets, MTF verdict, execution hint). Explicitly distinguishes from sibling tools by noting what it does NOT expose.
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 advises when to use alternative tools (REST raw contract, decker.get_market_state) for raw engine-native fields, providing clear when-not guidance. Implies its use when customer-facing language reading is desired.
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. 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). | |
| 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, the description fully discloses behavioral traits: Skill Overlay, computation of risk_reward_ratio, turn-retention policy, freshness_state, and that action_gate is a posture not an order. This is 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 detailed yet concise, with no redundant sentences. Each part adds value, from output fields to retention policy and cross-tool advice. Well-structured.
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, the description covers output shape, behavioral nuances, and filtering. It lacks pagination details for the limit parameter but is otherwise very complete.
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 80%, so baseline is 3. The tool description mentions filters but does not add significant meaning beyond the schema's parameter 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 it retrieves 'Active trading signals for the current user' and lists the output fields and filtering. It distinguishes from sibling tools by focusing on signals and mentions cross-tool guidance.
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 specifies when to use the tool (for active signals, with filters) and advises checking intent before ordering. It lacks explicit 'do not use when' or direct sibling comparisons, but the context is clear.
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. 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 provided, the description carries full burden. It discloses that the tool provides a 'market-state reading, NOT a trade instruction' and specifies the output fields (verdict, coordinates, receipts). It lacks details on side effects or auth, but the read-only nature is implied by 'view' and context.
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, well-structured paragraph that front-loads the purpose. Every sentence adds value: definition, contents, usage guidance, and a precaution. No redundancy or fluff.
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 output schema and only two parameters, the description is fairly complete. It details what the output contains, provides use-case guidance, and includes a safety note. It does not cover error states or pagination, but those are not critical for this tool.
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. The description adds meaningful context: it explains the `tf` parameter's purpose ('the grounded narrative is composed on this TF's bar') and gives symbolic and coverage details for `symbol`. This goes beyond the schema 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 it returns 'the engine's VIEW for a symbol — the same composed card the daily briefing sends' and lists contents (verdict, alignment, narrative, coordinates, etc.). It also distinguishes from sibling get_market_state: 'Prefer this over get_market_state when you want the interpreted view instead of raw engine fields.' This provides a specific verb+resource and explicitly differentiates from siblings.
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 gives explicit guidance: 'Prefer this over get_market_state...' and advises checking decker.validate_intent before ordering. It does not explicitly state when not to use it, but the context is clear enough for correct selection.
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.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).
| 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 = the active signal's timeframe if one exists, 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?
No annotations provided, so description carries full burden. It details the components checked (engine gate, structural state, signal direction/invalidation) and the return values (stance reading, side_alignment). Mentions persistence to an auditable ledger. Implies read-only nature through 'pre-trade gate check' but does not explicitly state no side effects, preventing a perfect score.
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?
Descriptive and well-structured with multiple sentences, each adding value. Front-loaded with purpose. Could be slightly tighter (e.g., consolidating some phrases), but no redundant information.
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?
Thorough description covering purpose, usage, return values, and edge cases. No output schema exists, so description compensates by explaining stance reading, side_alignment, and the meaning of 'covered=false'. Also mentions the decision ledger, providing complete context for tool invocation.
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% with descriptions for all four parameters. The description adds value by explaining defaults (timeframe omission), optionality (order_type informational), and edge cases (covered=false). Supplements schema effectively.
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 pre-trade gate check for a proposed order intent, specifying what it checks (symbol + side against Decker's market state and signals). It distinguishes itself from sibling tools like decker.get_market_state or decker.get_signals by being a validation step before execution.
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 instructs 'Call this BEFORE placing any order through any execution tool.' Explains that it returns a stance reading, not approval/rejection, and how to interpret 'covered=false'. Leaves the final decision to the agent/user, clarifying 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!
