Skip to main content
Glama

Preview a theme rule's tickers (saves nothing)

preview_theme

Show which tickers a theme rule would hold, before saving it (requires api:account). rule_text is the user's own words, such as "trending biotech names" or "the AI memory and compute bottleneck". Gambit compiles it with two model calls over its own market data (a pre-screen of the Hyperliquid listings and liquid US stocks, then a ranking from daily returns, dollar volume, card and news counts and recent headlines; a number Gambit holds no data for stays empty) into up to 100 candidates, best first, each with symbol, subject_id, display_symbol, reason (one line: why it fits), tradable (true when it has a Hyperliquid listing; a name without one can only be watched for trading), listing (its Hyperliquid id), signal (the numbers the ranking saw: r5, r20, r60 returns in percent, volz, dv20_usd_m, cards7, news7, and bars, the price source) named_in_rule, last_event (the newest card or news item on it in the last 7 days), and tier and tracked_by (what saving it now would track at the default caps, and why). signal at the top level is how the theme is ranked: anchored (a rule that names a thesis or tickers) or trend (a "trending" rule). exclusions are names the model left out on purpose, with why; dropped lists the symbols that did not resolve to one asset. Nothing is saved: to keep it, call save_theme with action create and the same rule_text (that compiles again). Each preview counts against the limit of 10 compiles per user per UTC day (preview, a rule create, and an edit with rule_text each count). Show the list to the user before saving. Errors: 429 theme_compile_limit with retry_after; 502 theme_compile_failed; 503 theme_compile_unavailable or themes_disabled.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "rule_text": "<rule_text>"
    },
    "name": "preview_theme"
  }
}

Input Schema

NameRequiredDescriptionDefault
rule_textYesthe user's own words describing the theme

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior4/5

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

With annotations already declaring the mutation/safety profile, the description nevertheless adds substantial context the annotations cannot: an auth scope requirement, a quota (10 compiles per user per UTC day shared across preview, create and edit-with-rule_text), the fact that each call triggers two model calls, and enumerated error codes with retry semantics. The only slight gap is that it never says the call is idempotent=false in practical terms (same rule_text can yield different results), though 'compiles again' hints at it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the body is a single overstuffed mega-sentence enumerating every returned field inside nested parentheses, which is hard to scan. All the content is relevant, yet it would benefit from being broken into a return-value block and a separate quota/errors block.

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

Completeness5/5

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

There is no output schema, so the description carries the full burden of return-value documentation, and it does: candidates with symbol/subject_id/reason/tradable/listing/signal fields, top-level signal classification, exclusions, dropped symbols, tier and tracked_by. Combined with quota and error paths, an agent has everything needed to call and interpret the result.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by characterizing rule_text as free-form user wording and supplying concrete examples ('trending biotech names', 'the AI memory and compute bottleneck'). It also notes the same rule_text must be passed to save_theme, which is a semantic constraint the schema does not encode.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a precise verb and resource (show which tickers a theme rule would hold) plus a scope qualifier ('before saving it'), which immediately separates it from save_theme. Sibling tools like get_theme, save_theme and list_themes are distinguishable without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly names the alternative and the condition that selects it: 'Nothing is saved: to keep it, call save_theme with action create and the same rule_text'. It also gives a workflow directive ('Show the list to the user before saving') and states the precondition (requires api:account).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources