Skip to main content
Glama

Get what a Gambit view read

get_gambit_inputs
Read-onlyIdempotent

What Gambit's shared view of one ticker read between two dates — the call for "what happened for DRAM between Nov 1 and Nov 3" or "what made Gambit change its view of NVDA this week". 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. Pass start and end as YYYY-MM-DD (UTC days: start is 00:00 UTC, end is the end of that UTC day) or full ISO times; end defaults to now and start to 3 days before end; at most 31 days. Or pass after_version and up_to_version (version numbers from get_gambit_history; at most 500 versions). Returns subject_id, display_symbol, the start and end used, and versions: each accepted version whose as_of falls after start and at or before end, oldest first, with version, as_of, path (analyst: a full review; applied: the step applied new items; step_quiet: the step found nothing that moves the view; carry_forward: the view carried over), lean_before and lean_after, shown_before and shown_after (the lean shown to users, -3 to +3), note (the change in the analyst's words), no_change, cause_item_ids (the items that caused the change), consumed_item_ids (every item that version took in), river_items (items another ticker's story routed here, with the river), driver_versions (other takes it leaned on), market (the price that version read: instrument, as_of, price, bar_end and age_seconds; price null when no bar was found), priced_numbers (the market numbers the view stored), written (the numbers its sentence was written at, when they differ), missing and inferred (fields not known, and fields worked out rather than recorded, such as market on versions written before Gambit recorded its price key). item_ids lists every item consumed in the range (cause items included); items gives title, source, source_type, url and published_at for at most 300 of them, cause items first (items_truncated says some were left out). partial true means some versions were written before Gambit recorded its inputs and were rebuilt from the change record; gaps says, per version, what is not known. Tell the user when the answer is partial. Lead with the versions where the shown lean moved, and name their cause items. Errors: 404 unknown_symbol; 422 ambiguous_symbol with candidates; 422 invalid_range or range_too_long; 503 gambit_reads_disabled while these reads are switched off. (Requires api:read.)

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": {
      "symbol": "<symbol>"
    },
    "name": "get_gambit_inputs"
  }
}

Input Schema

NameRequiredDescriptionDefault
endNoYYYY-MM-DD (end of that UTC day) or an ISO time; default now
startNoYYYY-MM-DD (00:00 UTC) or an ISO time; default 3 days before end
symbolYesa ticker such as DRAM or NVDA, an exact id such as xyz:GOOGL, or a candidate subject id from ambiguous_symbol
after_versionNoinstead of dates: the version before the range (0 = from the first)
up_to_versionNoinstead of dates: the last version in the range

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare this a read-only, idempotent, non-destructive, closed-world read, so the bar is lower. The description still adds substantial behavior beyond that: 31-day and 500-version caps, partial-rebuild semantics, items_truncated, and the full error taxonomy (404/422/503). That is well above what annotations convey.

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 dense run-on paragraph with heavy nested parentheticals that make it hard to scan. Nearly every clause carries information, yet the wall-of-text formatting works against quick comprehension for a lengthy definition.

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 complex tool with no output schema, the description thoroughly documents the return shape (versions, lean fields, market/priced_numbers, missing/inferred, gaps) and all error modes. Nothing an agent needs to call it or interpret results is missing.

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

Parameters5/5

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

Schema coverage is 100%, but the description goes far beyond it, explaining UTC-day boundary semantics, defaults (end=now, start=3 days back), the ref:eq prefix, candidate subject-id syntax, and the meaning of after_version/up_to_version. This meaningfully enriches every parameter.

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-ish action (read Gambit's shared view of one ticker between two dates) and grounds it with two concrete user questions. It also distinguishes itself from get_gambit_history by naming it as the source of version numbers, so an agent can route between them.

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?

Explicitly says when to use it (the quoted example questions), offers the version-range alternative to dates, explains the ref:eq:TICKER workaround for the US-stock-vs-Hyperliquid ambiguity, and instructs how to handle partial results (tell the user). Alternatives and exclusions are all present.

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