Skip to main content
Glama

Evaluate an opportunity

evaluate_opportunity

Evaluate one setup for YOUR account — the same action as Evaluate in the Gambit app. Requires the api:recommend scope (403 without it). This runs the recommendation pipeline (LLM calls, except when the answer comes from Gambit's view) and can take up to ~45 seconds: each call uses one run of the SAME monthly recommendation quota generate_recommendation uses (403 tier_limit_exceeded when it is spent) and one of 5 calls per minute that evaluate_opportunity and review_opportunity_trade share (429 rate_limited with Retry-After). Do not call it speculatively. Name the setup one of two ways: opportunity_id (a Today's Market card from get_opportunities, mo_ + 32 hex; scenario_id optionally picks one of its plan scenarios from get_opportunity_detail), or security_id + session_date (a Daily Move from get_daily_moves; it must be a Big Move). The answer is data.evaluation: outcome is actionable (Gambit would take it: direction, strength, sizing and trade_ticket), watch (worth watching, not yet), pass (Gambit passes on it) or insufficient (not enough evidence; decision_analysis.missing_evidence says what would settle it). execution.state says whether an actionable ticket is ready or blocked. decision_analysis carries the read, counter_case and changes_if; decisive_evidence the facts it rests on. When Gambit answers are enabled for this deployment (they ship off), for a card on an asset Gambit covers, the evaluation is Gambit's view of that ticker plus a sized plan from the user's own limits: decision_analysis is the rendered view (current_read the headline and summary, counter_case the case against, changes_if what would prove it wrong, with dates), decisive_evidence the sources of its reasons, and gambit the view block (subject_id, version, view, plan); actionable needs a real lean (|shown_lean| at least 1), a Hyperliquid listing and a current view and price, watch means no edge, no listing to trade, or a view that cannot back a ticket on this run (out of date, or no current price), and insufficient means Gambit has no view yet (the ticker is queued; evaluate again after its next update). capital_authority is always none: evaluating places NO order. An actionable evaluation also records a recommendation (ledger_id); when the evaluation comes from Gambit's view that recommendation is advisory, so execute_recommendation refuses it (409 advisory_not_executable). To refresh an actionable Today's Market card evaluation's ticket before trading, call review_opportunity_trade with the card's opportunity_id, evaluation_id, scenario_id, trade_ticket.advisory_fingerprint, trade_ticket.ticket_fingerprint and source.snapshot_fingerprint. Executing anything is a separate api:trade step that needs the human's explicit approval. The response carries app_url, the card's screen.

Input Schema

NameRequiredDescriptionDefault
scenario_idNowith opportunity_id: one of the card's plan scenarios
security_idNoa Daily Move's security_id from get_daily_moves; send with session_date
session_dateNothe Daily Move's session date, YYYY-MM-DD
opportunity_idNoa Today's Market card id from get_opportunities (mo_ + 32 hex)

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?

Annotations only give the safety profile (readOnlyHint=false, non-idempotent), but the description adds the full operational picture: ~45s latency, shared monthly quota with generate_recommendation, a 5/min shared cap yielding 429 with Retry-After, 403 scope/tier errors, that no order is placed (capital_authority none), and that a recommendation is recorded but is advisory and refused by execute_recommendation (409). readOnlyHint=false is consistent because a ledger recommendation is written, so no 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?

Purpose is front-loaded, but the body is a single dense wall of prose spanning quota, rate limits, Gambit-view internals, and execution handoff. Almost every sentence carries needed information given the tool's complexity, but the lack of segmentation makes it hard to parse and some detail (app_url, view block fields) is overload for the selection decision.

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 carries the return contract: outcome states (actionable/watch/pass/insufficient), execution.state, decision_analysis and decisive_evidence, and the Gambit-view block. Combined with the auth, quota and execution-handoff details, an agent has everything needed to call and interpret it.

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%, but the description goes beyond it by explaining the two disjoint naming modes (opportunity_id vs security_id+session_date), the mo_+32hex format, that scenario_id picks a plan scenario, and the added constraint that a Daily Move 'must be a Big Move'. It adds real meaning over the schema's per-field hints, though the mutual-exclusion/requirement structure is implied rather than stated.

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 and resource ('Evaluate one setup for YOUR account') and anchors it to a known action ('the same action as Evaluate in the Gambit app'). An agent can distinguish this from generate_recommendation, review_opportunity_trade, and the get_* siblings 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?

Explicitly says 'Do not call it speculatively', defines the two valid ways to name a setup and where each id comes from, and routes the agent to review_opportunity_trade for refreshing a ticket and to a separate api:trade step for execution. When-to-use and when-not-to-use are both present.

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