Decker
Server Details
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).
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.3/5 across 8 of 8 tools scored.
Each tool has a distinct purpose: raw state, customer reading, signals, timeline, skills, view, overlay change, and pre-trade validation. No overlap detected.
All tools follow the 'decker.verb_noun' pattern with underscores, e.g., get_market_state, set_skill_overlay. Perfectly consistent.
8 tools is well-scoped for a market analysis server, covering all necessary functionalities without bloat.
Core operations are covered, but missing tools like listing all available symbols or managing signal states slightly limit completeness.
Available Tools
8 toolsdecker.get_market_stateAInspect
Market 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 |
Tool Definition Quality
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 this is a read operation ('zero recompute'), explains output fields like game.status and action_gate, warns that 'Absent fields are null', and clarifies it is not a trade instruction. This gives good insight into behavior and limitations, though it lacks details on rate limits or performance.
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, with a long 'DOMAIN FRAME' section that reads like background documentation. It could be condensed to 2-3 concise sentences focusing on purpose, output nature, and alternatives. The current text is a wall of jargon that may hinder agent comprehension.
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?
Despite lacking an output schema, the description explains key output fields (game.status, game.target, action_gate, etc.) and states that absent fields are null. It provides necessary context for an agent to understand what the tool returns. However, the heavy technical language may reduce completeness for a general AI agent.
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 description, timeframe only has enum). The description does not add extra meaning beyond mentioning 'symbol' and 'timeframe' in the first sentence. It doesn't elaborate on format for symbol or constraints. The enum for timeframe is self-explanatory. Compared to baseline 3 for 50% coverage, this requires more compensation but fails to provide it.
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 immediately states 'Market State v0 — current engine structural state for a symbol/timeframe' with specific verb (get) and resource (market state). It distinguishes itself from siblings by noting that for human-language views one should use decker.get_view or decker.get_reading, and explicitly says it is 'NOT a trade instruction'. This clearly differentiates from other 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?
The description provides explicit guidance: 'Before placing any order through any execution tool, check the intent with decker.validate_intent' and 'for a human-language view use decker.get_view (with tf) or decker.get_reading'. It also implies this tool is for low-level engine state. While it doesn't explicitly list when not to use it, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
decker.get_readingAInspect
AI-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'). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses AI-synthesized nature, customer-facing language, and exclusion of raw fields. Lacks info on authentication or rate limits but adequate for a read-only tool.
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: first defines purpose and outputs, second clarifies what is not included and alternatives. Efficient and 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?
Comprehensive for a read tool: mentions components, alternatives, and limitations. No output schema but description covers expected return content.
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%, but description adds little to parameter meaning beyond listing outputs. It implicitly references symbol and timeframe but does not detail 'tf' or 'include_tfs' parameters.
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?
Description clearly states it provides an AI-synthesized market reading in customer-facing language, listing specific components (state description, bias scores, break targets, MTF verdict, execution hint). Explicitly distinguishes from sibling decker.get_market_state by noting raw fields are not exposed.
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?
Description explicitly tells when to use (customer-facing reading) and when not to (raw fields via get_market_state or REST contract). Provides clear alternative paths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
decker.get_signalsAInspect
Active 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). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses retention policy ('turn-retention policy'), advises to check freshness_state, clarifies action_gate as a stance not an order, and notes risk_reward_ratio computation after overlay. These details add significant behavioral context beyond a simple read operation.
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 effectively front-loaded: it first states output, then key fields, retention policy, filtering, and a cross-reference. Every sentence adds unique value; no redundancy or fluff. Length is appropriate for 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 no output schema, the description covers all critical aspects: output shape, computed fields, retention behavior, filters, and a directive to validate intent. It is complete enough for an agent to understand and use the tool correctly without missing 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?
Schema coverage is 80%, high enough for baseline 3. The description adds extra value for timeframe (explains opposite directions on different horizons and that omitting gets latest) and action_gate (explains null exclusion). This goes beyond schema definitions.
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 returns 'Active trading signals for the current user' with specific output fields like coordinates, decision, action_gate, etc. It clearly identifies the resource (signals) and verb (get), and the detailed list of output fields distinguishes its purpose from sibling tools like decker.get_market_state or decker.get_reading.
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 does not explicitly state when to use this tool vs alternatives. It implies usage for retrieving trading signals but does not compare to other get_* tools or provide exclusions. A cross-reference to decker.validate_intent is given for post-usage, but no guidance on selecting among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
decker.get_state_timelineAInspect
Market 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behaviors: ascending order by bar_ts, honest gaps (no filling), and a slimmed-down schema. It does not mention read-only nature explicitly, but the tool name (get_) implies it. Missing details on rate limits or edge cases.
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, efficient sentence that front-loads the core purpose, then adds key differentiators and behavioral notes. Every clause adds value with no wasted words.
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 4-parameter tool with no output schema, the description covers purpose, behavior, and structure comparison. However, it lacks details on return format (list of objects), pagination via limit, and error conditions. More context would help an agent interpret the response 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 description coverage is 50%, and the description does not compensate. It mentions required fields symbol and timeframe implicitly but does not add meaning to optional parameters limit and since. The description relies on the schema, but since coverage is incomplete, the agent may be underinformed.
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 per-bar state timeline for a symbol/timeframe, and contrasts with decker.get_market_state by noting the slim game tag instead of full game block. This clearly distinguishes the tool from its sibling and provides a specific, action-oriented purpose.
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 the tool's purpose in relation to decker.get_market_state, implying use for historical state transitions. However, it lacks explicit guidance on when to use this tool over others like get_signals or get_view, and does not mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
decker.get_user_skillsAInspect
Trading 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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Clearly states it returns 3 base skills and the user's selected one, with no hidden side effects. Being a getter, read-only behavior is implied.
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?
Single sentence with no filler, directly states purpose and output. Front-loaded with key info.
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, description covers what is returned. Does not explain skill meanings or overlay significance, but adequate for a simple list retrieval.
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?
No parameters in schema, so description need not add parameter meaning. Baseline 4 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 uses specific verbs (returns) and names exact skills (conservative_v0/standard_v0/aggressive_v0). It distinguishes from sibling 'decker.set_skill_overlay' which modifies, while this tool retrieves.
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?
Implied usage for checking current skill overlay, but no explicit when-to-use or when-not-to-use. Sibling tools exist but no guidance on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
decker.get_viewAInspect
The 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) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully discloses the tool's read-only nature ('market-state reading, NOT a trade instruction') and explains the output structure. It does not explicitly mention destructiveness, but the context implies safety.
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 well-structured and front-loaded with the core purpose. It is slightly verbose but every sentence contributes meaningful information, balancing detail with 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?
Without an output schema, the description thoroughly enumerates all returned elements and contextual cues (e.g., timeframe, symbol coverage), making it entirely self-sufficient for an agent to correctly invoke and interpret the 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%, and the description adds valuable context: explains tf parameter's role and default behavior, provides symbol examples and coverage notes, which goes beyond the schema alone.
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 'the engine's VIEW for a symbol' with detailed contents (verdict, alignment, narrative, coordinates, etc.), and distinguishes it from sibling get_market_state by specifying when to prefer this tool.
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 'Prefer this over get_market_state when you want the interpreted view instead of raw engine fields' and recommends checking decker.validate_intent before placing orders, providing clear when-to-use and caution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
decker.set_skill_overlayAInspect
Change 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'). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the change immediately affects subsequent get_signals calls and downstream channels, which is important behavioral context. No annotations are provided, so this adds value. It could mention permissions or reversibility, but it's sufficient.
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, efficient sentence that front-loads the action and effect. No wasted words.
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 tool with one parameter and no output schema, the description fully explains its purpose and effect, making it 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 coverage is 100% with a clear description for skill_id. The tool description adds no extra parameter information beyond the schema, so baseline 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 states the action ('change active trading skill overlay') and the resource ('for this user'), with an immediate effect on subsequent calls. It distinguishes itself from the siblings (mostly getters) as a mutation tool.
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 indicates when to use (to change the skill overlay) and the effect on get_signals calls, but does not explicitly mention when not to use or alternatives. However, the sibling context makes it clear this is the setter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
decker.validate_intentAInspect
Pre-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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: it checks intent against deterministic market state, returns engine gate and side_alignment, and explains that 'covered=false' means unknown. It also mentions persistence to an auditable ledger. No 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?
The description is well-structured, front-loading the purpose and then expanding. It is slightly verbose but each sentence adds value, balancing detail and conciseness.
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 lack of output schema, the description covers purpose, usage, parameters, and output interpretation adequately. It could mention return format explicitly but is sufficiently complete for an agent.
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%, but the description adds value by explaining the semantics of 'timeframe' (gate horizon, fallback rules) and 'order_type' (informational), and resolves symbol aliases. This goes beyond the schema's basic 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 does a pre-trade gate check for a proposed order intent, explicitly distinguishing it from sibling tools like decker.get_market_state by instructing to call it before any order through execution 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?
The description explicitly says 'Call this BEFORE placing any order through any execution tool' and clarifies it returns a stance reading, not an approval, leaving the order decision to the calling agent. It provides clear when-to-use and what-not-to-expect guidance.
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.
Discussions
No comments yet. Be the first to start the discussion!