Skip to main content
Glama

Ask what the view would be if something happened

what_if_gambit

What the view of one ticker would be if something happened (requires api:read) — the call for "what if the ETF is approved?". 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. question (1-1000 characters): the event, in plain words. watch_id (optional): the watch_id of a pending condition, from view.prove_us_wrong[].watch_id or view.would_strengthen[].watch_id in get_gambit (from your_view.view instead when you have your own view), to ask about exactly that condition. The answer starts from your latest accepted view while get_gambit still shows it, else from the shared view (based_on names which, and the shared version it rests on). When the question matches a condition the view already lists (or you pass its watch_id), the answer is precomputed and no model runs: source precomputed, lean_if, condition, check_by and explanation; it is kept, so asking again answers from it (cached true). A question that only looks like a listed condition is not given that condition's answer, and neither is a question about the opposite event (not approved, or below instead of above). Otherwise the answer is source your_model: pack (the shared take with everything behind it, with the event added as the item marked kind assumption), rules (assume the event has happened and give the take as if it had: which levers it moves, by how much against what is priced) and output_schema. Answer it with your own model, keeping to the rules; Gambit runs no model, stores nothing and counts nothing for it. A what-if never changes any stored view. 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); 404 unknown_watch when watch_id names no open condition of the view; 503 gambit_reads_disabled while these reads are switched off.

Input Schema

NameRequiredDescriptionDefault
symbolYesa ticker such as BTC or NVDA, or an exact id such as xyz:GOOGL or ref:eq:IP, as for get_gambit
questionYesthe event to assume, in plain words
watch_idNoa pending condition's watch_id, from view.prove_us_wrong or view.would_strengthen in get_gambit

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

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 by disclosing the api:read requirement, personal-layer isolation, shared-view immutability, no-model-run behavior, precomputed-vs-your_model response paths, caching behavior, and specific error codes. The annotations alone would not communicate any of this operational context.

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

Conciseness2/5

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

The description is a sprawling mini-manual that detours into sibling workflows, personal-layer behavior, and repeated no-model/no-store claims. Although the purpose is front-loaded and some numbered structure exists, the signal is buried under excessive detail and 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?

Despite having no output schema, the description explains both possible return paths in detail: the precomputed source with lean_if, condition, check_by and explanation, and the your_model source with pack, rules, and output_schema. It also documents error conditions, making the definition complete for a complex tool.

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 already 100%, so the baseline is 3. The description adds meaningful parameter context, especially the provenance of watch_id from view.prove_us_wrong[].watch_id or view.would_strengthen[].watch_id in get_gambit, and clarifies that question is the event in plain words.

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 hypothetical-view operation for one ticker and explicitly frames it as the call for questions like 'what if the ETF is approved?' It distinguishes itself from siblings by naming get_gambit, add_gambit_evidence, get_gambit_pack, submit_gambit_view, and plan_gambit, so an agent can identify its role without opening schemas.

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?

Provides explicit usage guidance: use it for what-if questions, pass watch_id to target a listed condition, expect a precomputed answer when the question matches a dated condition, otherwise expect a pack to answer with your own model. It also names alternatives and explains when the question is not eligible for a listed condition's answer.

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