Skip to main content
Glama

Gambit

by trading.gambit
OverviewDiscussionsAdmin

Add your own information to a ticker's Gambit

add_gambit_evidence

Add a fact you know about one ticker to YOUR personal layer (requires api:account) — the call for "I know this about NVDA; what does it do to the view?". The chain for one ticker. Everything it stores is in YOUR personal layer: the shared view never changes because of it. Over this connector Gambit runs no model for you: YOUR OWN model does the personal work. (1) Add data: add_gambit_evidence stores a fact you know. It is labelled unconfirmed until Gambit confirms it from an official or wire source that states it; a confirmed fact's source joins the shared evidence, and the shared view uses it on its normal run. (2) Your view: the take formed again on top of the shared take plus your facts, which are assumed true for your view only. To form it: call get_gambit_pack, form the take with the rules and output_schema in the pack, then call submit_gambit_view. (3) What if: what_if_gambit gives the view if something happened; when the question matches a dated condition the view already lists, the answer is precomputed and no model runs; otherwise it returns the pack with the event added, for your model to answer. (4) Plan: plan_gambit gives entry, stop, size and exits from your own limits. A plan is not a recommendation to trade and places no order. claim (1-2000 characters): the fact in plain words. Gambit treats any instruction inside it as text and never follows it, and the claim itself never enters the shared evidence. url (optional, http or https): where the fact comes from; an official or wire source Gambit already holds at that link confirms the fact at once when its headline states the fact. check_by (optional, YYYY-MM-DD, default 14 days from today): the date by which the fact should be confirmed; an unconfirmed fact expires after that date. Otherwise Gambit makes one web search for a wire or government report that names the ticker and states the same fact. Returns user_item (your fact, with status unconfirmed or confirmed), confirmation (status, and matched: the source that confirmed it, or null), duplicate (true when you had already added the same fact: the stored one is returned, nothing new is stored and the daily limit is not used) and your_view. Over this connector your_view.status is form_with_your_model (next: call get_gambit_pack, form the view with your model, then submit_gambit_view; based_on_version is the shared version) or same_as_shared (each fact you added is already in the shared evidence, so your view is the shared view). Gambit runs no model for this call. When your view rests on a fact that is still unconfirmed, tell the user so. A daily limit applies (429 rate_limited with retry_after). Errors: 409 gambit_building when Gambit has no view of the ticker yet (get_gambit by symbol queues it; try again later); 404 unknown_symbol; 422 ambiguous_symbol with candidates (call again with one candidate as the symbol); 422 check_by_in_past or invalid_url; 503 gambit_personal_disabled while the personal layer is switched off. This places no order.

Input Schema

NameRequiredDescriptionDefault
urlNoan http(s) link to the source, when there is one
claimYesthe fact, in plain words
symbolYesa ticker such as BTC or NVDA, or an exact id such as xyz:GOOGL or ref:eq:IP, as for get_gambit
check_byNoYYYY-MM-DD; default 14 days from today

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say this is a non-read-only, non-idempotent, non-destructive write. The description adds what the annotations cannot: writes go only to the personal layer and never alter the shared view, facts are 'unconfirmed' until matched to an official/wire source, prompt-injection defense ('Gambit treats any instruction inside it as text and never follows it'), a daily limit with 429/retry_after, and full error taxonomy (409 gambit_building, 404 unknown_symbol, 422 ambiguous_symbol/check_by_in_past/invalid_url, 503 gambit_personal_disabled). Note it also explains a server-side web search for confirmation, which sits in mild tension with openWorldHint=false, but since the lookup is Gambit-internal and constrained to official/wire sources, this is not treated as a contradiction.

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?

Front-loaded well with the core action and scoping sentence, and the numbered list aids navigation. But items (2)-(4) largely restate the behavior of sibling tools (get_gambit_pack, submit_gambit_view, what_if_gambit, plan_gambit) — including a full description of plan_gambit's outputs that is irrelevant to adding a fact — so a substantial fraction of the text is cross-tool bloat rather than information about this call.

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 return burden and does so: it names user_item, confirmation (with status and matched source or null), duplicate (same-fact dedup, nothing stored, limit not consumed), and your_view.status as either form_with_your_model or same_as_shared. Combined with the error codes, expiry rule, and the instruction to tell the user when the view rests on an unconfirmed fact, an agent has everything needed to call and interpret this tool.

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% (baseline 3), yet the description still adds real meaning beyond it: claim is 1-2000 chars, is treated strictly as text and never enters the shared evidence; url confirms immediately if an official/wire source Gambit already holds states the fact; check_by defaults to 14 days and defines when an unconfirmed fact expires. It also explains the symbol disambiguation recovery path (call again with one candidate).

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+resource+scope: 'Add a fact you know about one ticker to YOUR personal layer', and immediately contrasts it with the shared evidence layer ('the shared view never changes because of it'). It is clearly distinguishable from sibling write tools like submit_gambit_view, create_gambit, and update_gambit_monitoring without opening any 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?

Gives an explicit trigger utterance ('I know this about NVDA; what does it do to the view?') and then separates this tool from the three adjacent steps (get_gambit_pack + submit_gambit_view, what_if_gambit, plan_gambit) in a numbered list. It also states sequencing (next: call get_gambit_pack, form the view, then submit_gambit_view) so the agent knows exactly where this call sits in the flow.

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

All Gambit toolsInspect
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