Gambit

Get Gambit tracking updates

get_tracking_updates

Read-onlyIdempotent

What changed across ALL of YOUR Gambits, newest first — the call for "what changed on my Gambits". Each item names case_id, case_title, case_state, monitoring_status and occurred_at, and is one of two kinds. kind=opportunity: Gambit captured a market opportunity for that Gambit; entry.source_snapshot carries the public headline, detail, evidence and source_refs, entry.captured_price the price at capture, and entry.historical true marks context from before tracking started. kind=judgment: Gambit reassessed the Gambit; judgment.trigger_kind says why (creation | refresh | shock | chat | manual), judgment.update_category is news or assessment, judgment.material true means the stance or conviction changed, judgment.judgment_before / judgment_after are the read before and after, judgment.delta_summary says what changed and why, and judgment.evidence_refs / captured_price / created_at record when and on what. 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. Page with limit (1-100, default 20) and the next_cursor from the previous page. include_gambit_changes (default false) also returns the changes in Gambit's view of the tickers you follow (your live Gambits' assets, and the tickers you have read with get_gambit by symbol and mark_seen true that none of your Gambits is about; a live Gambit is open or watching with tracking on, and a Gambit on the ticker in any other state, including stopped, dismissed, executed or expired, ends the follow) since you last looked: 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. gambit_changes is { items, has_more }. Each item has subject_id, display_symbol, version, as_of, headline, first_look, change_lines (what changed and why) and cause_items (the sources behind it), newest first. first_look true means you follow the ticker but never marked it seen (a get_gambit read by symbol with mark_seen true, or opening its Gambit in the app): its changes count from when you started following it, not from a last look, and they come back on every call until it is marked seen; do not call them new. has_more true means older changes were left out. With it the answer is { tracking_updates, gambit_changes }; when the Gambit changes read fails, gambit_changes is null and gambit_changes_error says why. Without it the answer is the tracking updates alone. The response carries app_url, the Tracking screen. (Requires api:read.)

Input Schema

Name	Required	Description
`limit`	No
`cursor`	No	next_cursor from the previous page
`include_gambit_changes`	No	default false; true also returns gambit_changes for the tickers you follow

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 19, 2026

addedInput schema / properties / include_gambit_changes

Added value: +{
+  "description": "default false; true also returns gambit_changes for the tickers you follow",
+  "type": "boolean"
+}

AddedOct 13, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations establish read-only/idempotent/non-destructive behavior, and the description adds substantial context beyond them: pagination, response shapes, first_look repetition until marked seen, null gambit_changes with an error field, and api:read authorization.

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 and most details are useful because there is no output schema, but the description is a single dense paragraph with long semicolon-heavy clauses. It is hard to scan and could be organized into clearer sections.

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 covers item kinds, field meanings, pagination, optional gambit_changes behavior, failure handling, and auth requirements. Little an agent needs in order to call it correctly 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?

The schema documents cursor and include_gambit_changes, but the description adds the missing default for limit (20), restates the 1-100 range, and thoroughly explains the semantics of include_gambit_changes, first_look, and has_more.

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?

Opens with a specific verb, resource, and scope: what changed across all of the user's Gambits, newest first. The phrase 'the call for what changed on my Gambits' makes the tool's role immediately distinguishable from get_gambit and get_gambit_history.

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 a clear primary use case and explains when include_gambit_changes should be used, including what counts as a followed ticker. It does not explicitly name an alternative sibling or state when not to use this tool, so it falls short of full when/when-not guidance.

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?