Deterministic market-state engine for trading agents — state, gate, coordinates, with receipts.
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.5/5 across 13 of 13 tools scored.
Execution and settings tools are clearly separated, but there is a dense cluster of analytical getters (get_view, get_reading, get_signals, get_assembly) that all return market verdicts and coordinates; their boundaries are only clear after reading the long descriptions. get_market_state versus get_state_timeline is cleaner, but the overlap among the analysis-verdict tools could still cause misselection.
All tools share the decker_ prefix and a consistent snake_case verb_noun pattern (get_* for reads, place_order/close_position/update_protective_stops/set_skill_overlay/validate_intent for actions). There is no mixing of naming conventions or vague generic verbs.
Thirteen tools is within the ideal well-scoped range for an execution-plus-analysis server. Each tool maps to a distinct responsibility (state reading, timeline history, signals, execution, position management, user settings, pre-trade validation), so none feels like filler.
The lifecycle is well covered: validate_intent → place_order → get_positions → update_protective_stops → close_position, with signal/analysis and skill-overlay tools around it. Minor gaps like a dedicated account-balance or full order-history tool are absent, but the execution engine handles caps server-side and closed round-trips are included in get_positions.
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, requires account linkage, has no crypto-6 restriction, automatically determines real/virtual positions, and reports execution_mode as 'mixed' if both exist. Also explains the not-found behavior in detail.
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 yet well-organized, front-loaded with the tool's category (Axis③) and priority. Every sentence adds value: comparisons, behavior, edge cases, and safety notes are all included without redundancy.
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 an output schema, the description covers all necessary contexts: what happens with real vs virtual positions, mixed execution, no-position case, and safety for speculative calls. It is complete for an AI agent to select and invoke it 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 the baseline is 3. The description adds contextual meaning like 'any symbol you actually hold' and 'partially reduces' but does not elaborate on the schema's parameter descriptions beyond what is already provided. The schema already contains examples and defaults.
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 closes or partially reduces an existing position through DECKER's own execution engine. It distinguishes itself from the sibling 'decker.place_order' by explicitly contrasting with it, 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?
It explicitly references decker.place_order as an alternative and explains when to use this tool: 'Unlike place_order, there is no crypto-6 restriction.' It also provides a when-not condition: 'No open position for the symbol = a clean not-found response, not an error — safe to call speculatively.'
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?
The description fully discloses the tool's behavior: it is the single judgment authority, combining upper/lower TF logic, and includes a critical behavioral nuance about the 'aligned' grade. Although no annotations exist, the description itself provides rich behavioral context, meeting or exceeding the need.
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 front-loaded with purpose but includes several parenthetical clarifications and a warning that add significant length. While every sentence adds value, the density might hinder rapid parsing for an agent. It could be tighter.
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 of the tool (multi-timeframe assembly, judgment authority), the description is remarkably complete. It covers direction, grade, entry, stop, target, RR, and a conditional switch, plus the critical 'aligned' caveat. No output schema exists, so the description partially compensates, but lacks explicit return structure explanation.
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 single parameter is well-described in the input schema, and schema coverage is 100%, so the description cannot add much beyond the schema. The description mentions 'omit for all 14 universe symbols' which is slightly redundant with the schema's 'Omit for the full universe' but consistent.
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 produces a multi-timeframe optimal-path assembly per symbol, acting as a single deterministic machine verdict combining all live timeframes. It distinguishes itself from sibling tools (e.g., get_reading, get_signals) by being the judgment authority, not a data source.
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 tells the agent to narrate or filter the output but not re-decide coordinates, and explains when to use symbol vs omit for the full universe. It also clarifies a common misinterpretation of 'aligned' grade, preventing misuse.
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). 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?
With no annotations provided, the description carries the full burden and does so thoroughly. It discloses that fields are engine-native, absent fields are null and never filled, object_context appears only on trigger bars, reverse_direction_conflict has a specific condition, and results are null for non-trigger bars or symbols outside the narrative universe.
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 with labeled sections and front-loaded core purpose. Every section adds meaningful context about domain, contract, or null behavior. A small amount of redundancy exists (e.g., 'Market State v0' and 'layer=STATE' both convey it is a state reading), but overall the density justifies the length.
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 provides a remarkably complete picture: what state is returned, what object_context means, when fields are null, how to interpret action_gate, and how to get a human-readable alternative. It is sufficient for an agent to know when and how to invoke 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?
The input schema already documents symbol with an example and timeframe with an enum. The description adds some value by explaining that symbols outside the narrative universe yield null and that the tool operates on a symbol/timeframe pair. However, it does not substantially enrich the meaning of the parameters themselves beyond what the schema provides, and schema coverage is only 50%.
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 opens with a specific, actionable definition: returns 'current engine structural state for a symbol/timeframe' and clarifies it reads persisted engine state with zero recompute. It also distinguishes itself from decker.get_view and decker.get_reading, which provide human-language views, making its role 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 explicitly says to use decker.get_view or decker.get_reading for human-language output, warns that this is a market-state reading and not a trade instruction, and directs users to check intent with decker.validate_intent before order placement. This gives clear when-to-use and when-not-to-use guidance relative to sibling tools.
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?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It does add context about data granularity (real vs virtual, live sl_price/tp_price, last 10 round-trips) and labels it as 'actual exposure' vs. recommendations, but it does not explicitly state read-only, permissions, or side effects. This is adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core idea ('this user's actual exposure') and is dense but efficient. The Axis③ contextual note adds useful framing without excessive verbosity, though a slightly tighter wording could improve it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description sufficiently enumerates the main return categories (real, virtual, closed round-trips per mode) and highlights key fields. It also connects to the wider tool ecosystem via sibling distinctions, making it adequate for a zero-parameter info retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There are no parameter semantics to clarify, and the description correctly focuses on the returned data instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving the user's actual exposure: real open futures positions, virtual paper positions, and closed round-trips. It also explicitly distinguishes this from decker.get_signals, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage guidance: use this before placing another order to avoid duplicate/over-exposure, and to check current protective stop/target. It also contrasts with get_signals, clarifying when NOT to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 — 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?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that object_context is present only when a recent trigger bar exists and null otherwise (including for individual KRX stocks), that internal reason codes are scrubbed, that reverse_direction_conflict appears only under specific conditions, and that execution_hint.preferred_direction is independent of the setups. This is rich, transparent context beyond any structured data.
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, densely packed paragraph with long nested clauses and parentheticals (e.g., the object_context exception, the scrubbing note, the reverse_direction_conflict condition). While every detail is relevant, the lack of sentence breaks and structured formatting makes it hard to digest. It could be improved by separating the main purpose from the detailed field behavior.
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?
Since there is no output schema, the description must explain the return values. It does this thoroughly: the main output fields (current state, bias scores, break targets, MTF verdict, execution hint) are listed, and important edge cases (null object_context, scrubbed fields, conflict detection, setup mismatch) are covered. While not exhaustive (e.g., it doesn't enumerate all possible values of stance), it provides sufficient detail for an agent to correctly interpret the tool's output for a complex domain.
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 67% (symbol and include_tfs have descriptions, tf has enum/default but no description). The tool description does not go into parameter semantics; it only generically mentions 'symbol/timeframe' and 'MTF verdict per timeframe'. It adds little beyond the schema, and since coverage is moderate (not high or low), the baseline 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 states the tool's purpose: 'AI-synthesized market reading for a symbol/timeframe' and lists the specific content (current state, bias scores, break targets, MTF verdict, execution hint). It explicitly contrasts with sibling tool decker.get_market_state by stating that 'Engine-native raw fields are NOT exposed here — use the REST raw contract (GET /public/reading) or decker.get_market_state for those', which differentiates it from its 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 provides explicit guidance on when to use alternatives: 'use the REST raw contract (GET /public/reading) or decker.get_market_state for those' when raw fields are needed. It also gives actionable usage caveats about execution_hint, warning that the preferred side must have a non-null setup before treating it as actionable, and explains when object_context.reverse_direction_conflict matters.
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, the description fully discloses behavioral traits: highlights Skill Overlay application, risk_reward computed on displayed coordinates, turn-retention policy for aged signals, freshness_state/age_bars/freshness_sec fields, object_context conditions, reverse_direction_conflict semantics, and null behavior for non-trigger bars. It also clarifies action_gate is a posture, not an order command, and that internal reason codes are scrubbed.
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 information-dense, front-loading the core purpose and then systematically covering edge cases, retention policy, object_context nuances, and related tool references. While not concise, each segment earns its place given the complexity; the structure is logical and actionable, though it could be broken into clearer paragraphs.
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 annotations, no output schema, and the tool's complexity, the description provides comprehensive context: output field meanings, staleness handling, filtering, object_context details, reverse-branch conflict explanation, and null conditions. It also cross-references other tools appropriately, making it self-sufficient for an agent to select and invoke 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 80% with detailed text on timeframe, action_gate, and min_progress. The tool description adds minimal extra parameter context beyond repeating filter options; it mentions risk_reward related to displayed coordinates, but that's output-related. This aligns with the baseline 3 for high schema coverage, as the description does not compensate significantly beyond 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 states the tool returns active trading signals for the current user, listing specific fields (coordinates, decision, action_gate, progress, MTF verdict, summary_ko) and output nuances. It differentiates from siblings by explicitly directing users to decker.get_market_state for internal reason codes and decker.get_assembly for cross-horizon judgment, establishing a distinct role.
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 explicit usage guidance: recommends decker.get_assembly instead of guessing timeframe, points to decker.get_market_state for scrubbed reason codes, and instructs users to call decker.validate_intent before any order. Also notes when results can be null and how to handle stale signals, giving clear when-to-use and when-not-to-use context.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It transparently explains that bars are ascending by bar_ts, that gaps are honest (absent bars, no filling), and that each item carries a slim game tag rather than the full game block. It also indicates the tool is a read operation (no side effects implied). It does not mention pagination or error behavior, but these are less critical for a read-only timeline. No contradiction with annotations (none provided).
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 dense sentence but well-structured: main purpose first, then schema difference, then intent, then ordering and gap behavior. Every clause carries meaning; no fluff. It could be split into two sentences for readability, but it earns its length.
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 tool has no output schema, so the description must convey the response shape and semantics. It references the sibling's schema and clarifies the divergence (slim game tag), explains ordering, gaps, and the transition history use case. It doesn't explicitly define the time range covered or how 'limit' interacts with 'since', but for a timeline tool this is largely self-evident. Given the complexity, it is reasonably 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 50% (symbol and timeframe have descriptions). The description does not add new parameter-specific semantics; it merely mentions bar_ts ordering, which relates to the 'since' parameter but doesn't go beyond the schema's own description of 'ISO8601 lower bound on bar_ts'. It doesn't explain 'limit' beyond the schema defaults/constraints. This is adequate given partial schema coverage, but not exemplary.
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 provides a per-bar state timeline for a symbol/timeframe, with a specific comparison to decker.get_market_state (slim game tag vs full block). It names the exact use case: reading status transitions across bars (forming → testing → resolved/failed). This distinguishes it from siblings, especially 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 when to use this tool: when you need the per-bar timeline with slim game tags to trace game progression, versus get_market_state which likely returns the full game block for a single state. It does not explicitly say 'use this instead of X when...', but the contrast with the sibling and the stated purpose provide clear context. Missing explicit exclusions, but adequate.
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?
The description discloses the return content (3 base skills and selected one) which is helpful. However, it does not mention side effects, read-only nature, or behavior when no skill is selected. Since no annotations are provided, the description carries the transparency burden and only partially fulfills it.
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 two concise sentences, front-loaded with the tool's purpose and directly naming the three expected skill IDs. No filler or redundant phrasing. It earns its place with specific 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?
Given the simple nature (no parameters, no output schema), the description is fairly complete. It names the exact return items and clarifies the 'catalog + overlay' structure. However, it could be slightly more complete by noting whether the selected skill can be null or how to handle multiple users, but for this simple getter it is 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?
There are no parameters, so the schema fully covers parameter information. The description adds meaning by explaining what the tool returns (the skill catalog and active overlay), which compensates for the lack of parameters. The baseline for zero parameters is 4, and no further parameter detail is needed.
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 what the tool returns: the trading skill catalog and the user's currently active overlay, including the three named base skills. It distinguishes from sibling tools by explicitly scoping to 'this user' and mentioning the active overlay, which sets it apart from other getters and the setter 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?
Usage context is implied: it is for retrieving a specific user's skills. However, it does not explicitly state when to use it over alternatives (e.g., set_skill_overlay) or provide any exclusion criteria. No exclusions or alternative recommendations are given.
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 responsibility and delivers substantial behavioral detail: the view is verbatim identical to the daily briefing card, reason codes are scrubbed on this customer surface, object_context.reverse_direction_conflict appears only under a specific local-vs-swing disagreement, and nullability conditions are spelled out. It also explicitly frames the output as a market-state reading and not a trade instruction.
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 front-loaded with the primary purpose, but the long single-paragraph format with nested parentheticals makes it less scannable than ideal. Every sentence earns its place and no content is redundant, but the structure could be improved with bullet points or shorter sentences.
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 tool with no output schema, the description thoroughly explains return content: the composed card components, object_context block and its conditional fields, null behavior, and the relationship to other tools. It covers the complexity of the domain (reversal confirmation conflicts, narrative universe) without significant gaps.
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 schema descriptions are already detailed (default TF, symbol universe examples). The tool description does not add further parameter-level meaning beyond what the schema provides, so the 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 opens with 'The engine's VIEW for a symbol' and enumerates the exact composed card contents (verdict, alignment, narrative, coordinates, receipts), making the verb+resource+scope explicit. It also distinguishes itself from get_market_state by explicitly stating when to prefer it over the alternative.
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 explicit usage guidance: 'Prefer this over get_market_state when you want the interpreted view instead of raw engine fields.' It also establishes preconditions (null on non-trigger bars or outside narrative universe), demonstrates the tool's non-trade nature, and directs the agent to check decker.validate_intent before order execution.
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, the description fully shoulders the transparency burden. It discloses execution mode resolution (not caller-chosen), kill switch, eligibility caps, authoritative response mode, position netting, and pre_existing_position behavior. This is exemplary for a high-risk mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single dense paragraph is long but every sentence carries essential safety/behavioral info. It's front-loaded with purpose, but the wall-of-text format could benefit from bullet points or section breaks. Slight deduction for structure, not content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description explains critical return behaviors (mode authority, pre_existing_position, netting). It also covers prerequisites, constraints, and failure modes, making it complete for understanding the tool's full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers parameters 100%, but description adds crucial semantics: notional_usd is checked against tier cap and used for quantity calculation, side enumerations are clarified, and symbol restriction is reaffirmed. This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool places a market order through Decker's own execution engine, distinguishing it from other tools. It specifies the exact resource (order) and action (place), and explicitly contrasts with siblings that don't move money.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: call decker.validate_intent first, restricted to crypto-6 symbols, and notes that HL-synthetic/KRX symbols are read-only via other tools. This clearly delineates when to use this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 carries the transparency burden. It discloses that the change is immediate and affects downstream channels, which is useful. However, it does not mention whether the change is reversible, if it overrides existing settings, or any permission requirements, leaving gaps.
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, front-loaded with the action verb. Every word earns its place; no redundancy or filler.
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 one-parameter setter, the description covers the core function and its immediate consequences. It lacks details about error conditions or prerequisites, but given the simplicity and single parameter, it is nearly 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?
The schema already provides 100% coverage for the single parameter skill_id, including a description and example. The tool description adds no additional meaning beyond the schema, so the 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 states the verb 'change' and the resource 'active trading skill overlay for this user', which distinguishes it from sibling getters. It is specific and 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 explains the immediate effect on subsequent get_signals calls, providing clear context for when this tool is relevant. However, it does not explicitly mention alternatives or when-not-to-use scenarios, though the sibling set of getters makes the use case obvious.
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 the full burden. It discloses the exact behavior for real vs virtual modes: real cancels old exchange orders and places new ones, with the new order placed first to avoid an unprotected window; virtual directly updates paper position columns polled by the paper monitor. It also explains the condition for mode and the rejection outcome, providing deep transparency beyond just 'modifies stops.'
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 longer than average but every sentence carries important information. It is logically structured: purpose, rationale for no cancel tool, real-mode behavior, virtual-mode behavior, parameter requirements, and mode ambiguity rule. While not as terse as a two-sentence description, the complexity of the tool justifies the length and no sentence is wasted.
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 (dual real/virtual modes, partial updates, no cancel sibling), the description is remarkably complete. It covers what the tool does, when to use it, how each mode behaves, parameter constraints, and edge case (mode required for dual positions). There is no output schema, but the description doesn't need to explain return values for this modification tool; the invocation semantics are fully specified.
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% parameter descriptions, so the baseline is 3. The description adds value by stating the 'at least one of sl_price/tp_price' requirement and clarifying that omitted parameters retain current values, which reinforces and clarifies the schema's 'Omit to leave current stop unchanged' wording. It also explains when mode is necessary, going beyond the schema's note. This elevates it above baseline, though the schema already does much of the work.
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 starts with a clear verb+resource: 'modifies the stop-loss and/or take-profit on an EXISTING open position.' It also distinguishes itself from siblings by explicitly noting there is no cancel_order tool and that this tool fills the gap of modifying protective stops on an already-held position, differentiating it from 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?
It provides explicit when-to-use context (existing position), explains why there is no cancel tool (market orders only), and gives concrete usage rules: 'Provide at least one of sl_price/tp_price', the other side is left unchanged, and mode is required only when both real and virtual positions are open. It even describes the rejection behavior if mode is omitted, which is clear guidance for the agent.
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?
With no annotations, the description carries the full burden. It discloses that the tool returns a stance, not approval, persists checks to a ledger, and explains the covered=false semantics. It also details object_context fields and reverse-direction conflicts, providing deep behavioral insight beyond any typical annotation.
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-structured, front-loading the core purpose and usage before diving into nuances. While lengthy, sentences are information-dense and non-redundant; the structure aids comprehension for a complex 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 the tool's complexity and lack of output schema, the description covers essential aspects: purpose, usage, edge cases, persistence, and object_context. It could be slightly more explicit about the exact return format (e.g., naming the stance fields), but it is sufficiently complete for an agent to use 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%, but the description enhances it further. For timeframe, it explains a detailed resolution priority (open position TF → get_assembly's entry TF → engine default). It also clarifies that order_type is informational and recorded in the ledger, adding meaning not present in the 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 explicitly states the tool's purpose: 'Pre-trade gate check for a proposed order intent.' It specifies the verb (validate) and resource (intent), and clearly distinguishes from execution tools by emphasizing it returns a stance, not an approval. It also differentiates from sibling get_* tools by focusing on the pre-trade decision step.
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 direct guidance: 'Call this BEFORE placing any order through any execution tool' and even references a broker MCP's review→place flow. It also clarifies interpretation of edge cases like covered=false and emphasizes it's not an order command. This is explicit and action-oriented.
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!
Sign in to create a connector for this server.