Skip to main content
Glama

Get a ticker's evidence pack for your own model

get_gambit_pack
Read-onlyIdempotent

The evidence pack for one ticker, so YOUR OWN model can form a view of it (requires api:read). 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. Returns based_on_version (the shared version the pack is built from), pack (the shared take with everything behind it: its levers with state, what is priced and thresholds, its tests with watch ids, macro, mechanics and the analyst's ledger; the market numbers; and items, each with its item_id: the sources the shared take rests on, plus your own facts marked kind user with negative ids), rules (Gambit's analyst method; items marked kind user are the user's own information: assume they are true and say so), output_schema (the JSON schema of the take to return) and submit_with (submit_gambit_view). Gambit runs no model for this call. Next: form the take with your model, following the rules and output_schema, cite only item_ids from this pack, and pass the JSON object to submit_gambit_view with your model's name and this pack's based_on_version. 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); 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

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?

Beyond the readOnly and idempotent annotations, the description discloses authentication requirements (api:read), that Gambit runs no model for this call, that personal-layer data never changes the shared view, and exact error codes for building, unknown symbol, ambiguity, and disabled reads.

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 description is front-loaded with the core purpose and uses numbered sections for workflow, error handling, and next steps. It is somewhat verbose and repeats the no-model point, but the length is largely justified by the multi-step workflow it must explain.

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?

Even without an output schema, the description fully explains the return structure: based_on_version, pack contents, rules, output_schema, and submit_with. It also covers error recovery and how this call fits into the broader personal-view workflow.

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 symbol's format and examples are already documented. The description adds meaningful parameter behavior by explaining the 422 ambiguous_symbol error and instructing the caller to retry with one candidate as the symbol.

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 description states a specific verb and resource: retrieving the evidence pack for one ticker so the caller's own model can form a view. It distinguishes the tool from siblings by naming get_gambit for queueing and submit_gambit_view as the required next step.

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 an explicit workflow: call get_gambit_pack, form the take with the pack's rules and output_schema, then call submit_gambit_view. It also routes related tasks to add_gambit_evidence, what_if_gambit, and plan_gambit, with clear when-to-use conditions.

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