Skip to main content
Glama

Get a Gambit

get_gambit
Read-onlyIdempotent

Gambit's view of one ticker (pass symbol), or one of YOUR Gambits in full (pass case_id). Pass exactly one of the two. BY SYMBOL (BTC, HYPE, NVDA, or an exact Hyperliquid id such as xyz:GOOGL): Gambit's view is ONE shared, versioned view per ticker: the same view for every user, with a new version only when Gambit's view changes. Reading by symbol works for any ticker Gambit covers, a Hyperliquid listing or a US stock, even when you have no Gambit on it. A bare ticker that names a Hyperliquid listing (often a crypto perp) and also a US stock with no Hyperliquid listing reads the Hyperliquid one. Check subject_type and display_symbol against what the user meant; pass ref:eq:TICKER (for example ref:eq:IP) to read the US stock. A ticker that stays ambiguous answers 422 ambiguous_symbol with candidates (subject ids such as asset:crypto:IP); call again with one candidate as the symbol. Your answer to the user starts with since_you_last_looked: what changed in the view since this user last read this ticker, why, and what caused it (or first_look on a first read). The response also carries subject_id, display_symbol, subject_type, version, as_of and generated_at; view (the headline and summary, our view against what's priced, the horizon, what produces the price (engine), positioning, the levers as reasons — each with its state, what the price assumes about it, our read, the threshold that would change our mind, and its sources — the macro forces with this asset's exposure, instrument mechanics, the case against, what would prove us wrong and what would confirm it with dates (each tied to a lever_id), the next dated events, how likely we are to be wrong, what we can't judge, and the map of what is priced when there is no edge; price_levels only when you pass price_levels true); new_since_view (official or wire news published after the view was formed); freshness (status fresh, cached or unavailable); and what_would_change_our_view (the dated conditions that would change it, each with overdue true when its date has passed and Gambit has not yet recorded the result, and the case against). reasoning (the analyst's ledger against the previous version — what happened to each lever and test, with sources — the noise it set aside and why, its research trail: which data it read, which searches it ran and which pages it read, and dig_further: where to go for more). When the user pushes back, test their claim against the levers' thresholds and what_would_change_our_view and say what evidence would change the view; do not just restate it. To score a new hypothetical event, call what_if_gambit. mark_seen (default true) records that this user has now seen this version, so the next read reports only later changes; pass false to look without recording it. A ticker with no view yet answers status building and is queued (queuing an asynchronous Gambit view build on first read of an unseen symbol): read it again later instead of polling in a tight loop. To report a view that looks wrong, call leave_feedback (needs api:account) with category data_quality and area gambits, and name the subject_id and version in the message. Errors: 404 unknown_symbol; 422 ambiguous_symbol with candidates; 503 gambit_reads_disabled while these reads are switched off. A symbol read has no app_url. BY CASE_ID (from list_gambits or get_tracking_updates): everything list_gambits returns, plus: case_seed — the question Gambit is answering for this Gambit (monitoring_question, monitoring_lenses, relationship_focus, horizon, change_criteria: the observable conditions that would change the read, and the seed summary); provenance (where it came from: discovery, mandate_activity, market_opportunity, chat or api); original_thesis (the advisory the Gambit started from, when it came from one) and current_advisory (the advisory behind the newest judgment, when known); mandate_lineage_id; the opportunity-tracking record (opportunity_first_tracked_at, opportunity_first_price, opportunity_last_result); judgments — the dated assessment log, newest first (each entry's id, trigger_kind, update_category, judgment_before / judgment_after, delta_summary, material flag, evidence_refs, captured_price and created_at; judgment_count is the true total); and, when Gambit has a view of the Gambit's asset, gambit (subject_id, version, as_of, the same view, since_you_last_looked, what_would_change_our_view and feedback; a case_id read never records it as seen and runs no freshness check, so it has no new_since_view: read by symbol for news since the view was formed). A judgment is Gambit's read of the Gambit for YOUR account: stance (recommend | watch | stand_aside), conviction (high | medium | low), summary (the written view), changes_if (what would change it), evidence_refs, user_reported_context (things you told Gambit that shaped it) and as_of. A Gambit that is not yours answers 404, exactly like one that does not exist. A case_id read carries app_url, this Gambit's screen. (Requires api:read.)

Input Schema

NameRequiredDescriptionDefault
symbolNoa ticker such as BTC or NVDA, an exact id such as xyz:GOOGL or ref:eq:IP (the US stock), or a candidate subject id from ambiguous_symbol; pass symbol or case_id, not both
case_idNoa Gambit id from list_gambits (UUID); pass case_id or symbol, not both
mark_seenNosymbol reads only, default true: record that the user has now seen this version
price_levelsNodefault false: add the price-level add-on (key levels, and wrong-if / confirms-if closes with dates) when the view has one

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / price_levels
      Added value: +{
      +  "description": "default false: add the price-level add-on (key levels, and wrong-if / confirms-if closes with dates) when the view has one",
      +  "type": "boolean"
      +}
  2. Changed4 schema fields changed
    • changedInput schema / properties / case_id / description
      Previous value: -"a Gambit id from list_gambits (UUID)"New value: +"a Gambit id from list_gambits (UUID); pass case_id or symbol, not both"
    • addedInput schema / properties / mark_seen
      Added value: +{
      +  "description": "symbol reads only, default true: record that the user has now seen this version",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / symbol
      Added value: +{
      +  "description": "a ticker such as BTC or NVDA, an exact id such as xyz:GOOGL or ref:eq:IP (the US stock), or a candidate subject id from ambiguous_symbol; pass symbol or case_id, not both",
      +  "pattern": "^[A-Za-z0-9][A-Za-z0-9._:-]{0,63}$",
      +  "type": "string"
      +}
    • removedInput schema / required
      Removed value: -[
      -  "case_id"
      -]
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover read-only/idempotent safety, and the description adds substantial context beyond them: api:read authorization, the default-on mark_seen read-receipt side effect with an opt-out, asynchronous build queueing on first unseen symbol, freshness statuses, the fact that case_id reads neither record seen nor run freshness checks, 404 for non-owned Gambits, and specific error codes.

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?

The two-mode selection is front-loaded, and much of the length is justified because there is no output schema and the return shape must be explained. However, it is a single dense paragraph enumerating many view fields; bullets or headings would make it scannable and would trim some redundancy.

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 explaining returns: the view contents, since_you_last_looked, reasoning ledger, new_since_view, freshness, what_would_change_our_view, judgments, and case-seed fields. Combined with error states and side effects, an agent has everything needed to call it correctly.

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; the description adds the symbol resolution workflow the schema cannot express—Hyperliquid-vs-US-stock precedence, the ref:eq:TICKER escape hatch, and resubmitting an ambiguous_symbol candidate as the symbol—plus case_id provenance. Some of this duplicates schema text, so it is strong but not entirely additive.

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 the exact two resources and modes: Gambit's shared per-ticker view (symbol) or one of the user's Gambits in full (case_id). It distinguishes itself from siblings by explicitly routing hypothetical scoring to what_if_gambit, case enumeration to list_gambits, and data-quality complaints to leave_feedback.

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 gives explicit when-to-use rules for both modes, the one-of-two constraint, when to call what_if_gambit, how to handle user pushback against levers, when to use leave_feedback, mark_seen=false for silent reads, and not to poll while a view is building. Recovery from 422 ambiguous_symbol is spelled out with the exact retry pattern.

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