Gambit

Add a ticker to a theme

add_to_theme

Idempotent

Add one ticker to one of YOUR themes by hand (requires api:account). It joins as tracked with added_by user, and stays until the user removes it: a later compile of the rule never moves or drops it. On a rule theme a watched member is promoted to tracked, and a tracked rule member becomes the user's. When the tracked list is full, the tracked ticker with the oldest event moves to watched (its Gambit is stopped if the theme opened it) to make room; tickers the user named or added are never moved. When every tracked slot holds one of those, the call answers 409 tracked_full, unless watch_if_full is true: then the ticker joins as watched (no Gambit). While the theme is active the ticker is followed as a Gambit (the user's own Gambit on it is kept and nothing is linked). symbol is a ticker (MU, BTC) or an exact Hyperliquid id (xyz:MU). Returns the theme as get_theme does, plus changed (false when the ticker was already the user's) and subject_id. Each call counts against create_gambit's limit of 10 per user per hour (429 gambit_create_limit with retry_after). Errors: 404 theme_not_found; 409 tracked_full (ask the user: remove a tracked ticker, or call again with watch_if_full true), theme_archived; 422 unknown_symbol or ambiguous_symbol; 503 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": {
      "theme_id": "<theme_id>",
      "symbol": "<symbol>"
    },
    "name": "add_to_theme"
  }
}

Input Schema

Name	Required	Description
`symbol`	Yes	a ticker such as MU or BTC, or an exact id such as xyz:MU
`theme_id`	Yes	a theme id from list_themes (UUID)
`watch_if_full`	No	true: when every tracked slot is the user's, add the ticker as watched instead of 409

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 2, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses that the ticker persists across rule compiles, that adding can demote another ticker from tracked to watched (stopping its Gambit), that user-named tickers are never moved, the rate limit (10/user/hour, 429 with retry_after), and the full error taxonomy. These are exactly the side effects an agent cannot infer from readOnlyHint=false / idempotentHint=true.

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

Conciseness4/5

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

Purpose is front-loaded and nearly every clause carries non-obvious information (promotion rules, overflow, limits, errors). However it is delivered as one dense run-on paragraph with no separation of behavior, limits, and errors, which hurts scannability for an agent parsing it.

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?

For a mutating tool with no output schema, the description covers the return value (theme as get_theme plus changed and subject_id), the failure modes with recovery guidance, and the auth/rate constraints. Nothing material is left for the agent to guess.

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 adds genuine meaning: symbol accepts a ticker or an exact Hyperliquid id (xyz:MU), theme_id traces to list_themes, and watch_if_full's behavioral consequence (joins as watched, no Gambit) is explained rather than restated.

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?

States a specific verb and resource ('Add one ticker to one of YOUR themes by hand') and immediately scopes it as a manual, per-ticker operation, which separates it from save_theme, preview_theme, and remove_from_theme. The 'YOUR themes' phrasing plus 'by hand' makes the ownership and manual-vs-rule distinction explicit.

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

Usage Guidelines4/5

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

Gives concrete decision paths: on 409 tracked_full the agent is told to ask the user to remove a tracked ticker or retry with watch_if_full=true, and watch_if_full's semantics are spelled out. It lacks an explicit 'use X instead when...' comparison to siblings like save_theme or preview_theme, so it is strong but not fully routing.

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

All Gambit tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?