Skip to main content
Glama

Submit your own model's view of a ticker

submit_gambit_view

Submit the view YOUR OWN model formed from get_gambit_pack (requires api:account). 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. view: the take your model produced, as a JSON object matching the pack's output_schema. model (1-80 characters): your model's name, for example claude-opus-5.5; the stored view is labelled with it. based_on_version: the based_on_version of the pack your model used; when the shared view has moved on since, the answer is 409 pack_changed: call get_gambit_pack again and form the view again. Gambit checks the take the way it checks its own: it must parse, cite only item_ids from the pack (your own facts included), keep price levels out of the shared tests (they belong in price_levels), give no price targets, market timing or rate forecasts of its own, and say why when it sees no edge. Gambit does not smooth it toward the shared view: it is your model's view. It is stored in YOUR personal layer, accepted or rejected, and never changes the shared view. Returns status (accepted: it is now your view; rejected: it is stored but is not your view), user_view_id, produced_by, based_on_version, the view as rendered (sources are shown only for items of the pack), differs (how it differs from the shared view) and problems. When status is rejected, fix each problem and submit again; a view that cannot be read at all is rejected the same way, with view null. 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); 409 pack_changed; 422 reserved_model_name when model is "gambit"; 503 gambit_personal_disabled while the personal layer is switched off.

Input Schema

NameRequiredDescriptionDefault
viewYesthe view your model produced, as a JSON object matching output_schema
modelYesyour model's name, e.g. claude-opus-5.5
symbolYesa ticker such as BTC or NVDA, or an exact id such as xyz:GOOGL or ref:eq:IP, as for get_gambit
based_on_versionYesthe based_on_version of the pack your model used (from get_gambit_pack)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Far exceeds what annotations provide: it discloses the personal-layer storage model, that the shared view is never altered, the Gambit validation rules applied, rejected-vs-accepted status semantics, daily limits with 429/retry_after, and the full error taxonomy (409/404/422/503). Annotations only say non-readonly, non-idempotent.

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 and organized, but it doubles as a dump of the whole Gambit workflow, devoting four numbered sections to describing sibling tools (add_gambit_evidence, what_if_gambit, plan_gambit) that have their own definitions. Length is partially justified by the absent output schema, but much of the middle does not directly serve calling this tool.

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?

With no output schema, the description fully specifies the return payload (status, user_view_id, produced_by, based_on_version, view, differs, problems, view null on unreadable input) and every failure mode. Nothing an agent needs to invoke and interpret the result is missing.

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 baseline is 3, but the prose adds real meaning: based_on_version conflict behavior (409 pack_changed and re-form the view), model naming rules including reserved_model_name for "gambit", and that view must match the pack's output_schema. The schema itself already documents these fields well, so the gain is incremental rather than decisive.

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: submitting YOUR OWN model's view of one ticker over the gambit connector, and explicitly frames the personal-layer nature. An agent can distinguish it from get_gambit_pack and get_gambit 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?

Gives the exact workflow (call get_gambit_pack, form the take with the pack's rules and output_schema, then call submit_gambit_view) and enumerates when/why each sibling is used instead (add_gambit_evidence, what_if_gambit, plan_gambit). Recovery paths on 409 pack_changed are spelled out.

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