Skip to main content
Glama

BotSpot: AI Trading, Backtests and Bots

by io.github.grzesir
OverviewDiscussionsAdmin

Broker daily snapshots

broker_snapshots

Read stored daily broker snapshot automation data. For realtime holdings use get_broker_positions. action="run_now" requests a fresh no-trade snapshot for the saved account and starts read-only snapshot compute.

Set "action" to choose the operation. Only send the fields listed for that action.

action="list": List broker daily snapshots

No other fields required. Lists the authenticated user's daily broker snapshot automation metadata and latest sanitized telemetry. Each broker credential has a deterministic snapshot bot id. Returned data can include accountDisplay (a safe label such as 'Account ending in 4821'), lifecycle status, last run status, latest portfolio value, cash, positions count, and timestamps. Never infer an account suffix from brokerCredentialId. Raw broker credentials and full account numbers are never returned. This is not the only source of position evidence. If this returns no accounts, no positions, stale data, or unavailable telemetry while the user asked for actual positions/holdings, continue with list_deployments(status="running", limit=50) and get_deployment_position_telemetry before concluding no live-bot positions are available.

action="portfolio": Get broker snapshot portfolio series

Required fields: brokerCredentialId. Returns portfolio-value snapshot data for one saved broker credential owned by the authenticated user. Use broker_snapshots(action="list") first to find brokerCredentialId and snapshot status. Raw broker credentials are never returned.

action="positions": Get broker snapshot positions

No other fields required. Returns stored normalized position snapshot data for saved broker snapshot automation. Use this only when the user explicitly asks about snapshot history, snapshot status, or stored snapshot diagnostics. For realtime holdings questions like 'how much Tesla stock do I own?', use get_broker_positions with symbol=TSLA. Use broker_snapshots(action="list") first to find brokerCredentialId and snapshot status. brokerCredentialId is optional. For all linked broker accounts, all broker positions, or 'not just the count' across accounts, prefer one aggregate call with brokerCredentialId omitted instead of many parallel per-account calls; the aggregate result preserves brokerCredentialId, accountDisplay, botId, broker, paperOrLive, positions[], and results[] so account-to-position mapping stays intact. Use accountDisplay in user-facing account labels and never infer an account suffix from brokerCredentialId. Raw broker credentials and full account numbers are never returned. If broker snapshot positions are empty, stale, or unavailable and the user asked for actual positions/holdings, continue with live-bot evidence through list_deployments(status="running", limit=50) and get_deployment_position_telemetry. Empty broker snapshots do not prove running deployments have no positions.

action="diagnostics": Get broker snapshot diagnostics

Required fields: brokerCredentialId. Read-only diagnostics for one broker snapshot automation owned by the authenticated user. Returns Node snapshot identity/latest telemetry, sanitized Bot Manager scheduled/ECS status, and optionally recent sanitized logs. Use this when broker_snapshots(action="list") shows setup pending, pending last run, no latest snapshot, or failed status. Raw broker credentials, Vault ids, runtime secret ARNs, and secret values are never returned.

action="run_now": Run broker snapshot now

Required fields: brokerCredentialId. Requests one immediate no-trade portfolio snapshot run for a saved broker credential owned by the authenticated user. This starts read-only snapshot compute through Bot Manager and the normal Vault-backed runtime secret path. It does not accept or return raw broker credentials, Vault ids, runtime secret ARNs, API keys, raw runtime configuration, or inline code.

Input Schema

NameRequiredDescriptionDefault
endNoUsed with action="portfolio".
sortNoUsed with action="positions".
limitNoUsed with action="portfolio", action="positions".
startNoUsed with action="portfolio".
actionYesWhich operation to run: "list", "portfolio", "positions", "diagnostics", "run_now". See the tool description for each one.
symbolNoUsed with action="positions".
historyNoUsed with action="positions".
logLimitNoUsed with action="diagnostics".
frequencyNoUsed with action="portfolio".
includeLogsNoUsed with action="diagnostics".
brokerCredentialIdNoUsed with action="portfolio", action="diagnostics", action="run_now", action="positions". Required for action="portfolio", action="diagnostics", action="run_now".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already state readOnlyHint=false, idempotentHint=false, and destructiveHint=false, but the description adds substantial context: authenticated-user ownership, sanitized telemetry, no raw broker credentials or account numbers, and that run_now starts read-only snapshot compute through Bot Manager/Vault-backed runtime secrets. This goes well beyond the structured annotations without contradicting them.

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 well structured and front-loaded, with a short summary followed by per-action sections. It is long for a tool definition, and repeated security disclaimers such as raw credentials never being returned appear in multiple action sections where one consolidated statement would likely suffice.

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?

For a complex five-action tool with 11 parameters and no output schema, the description covers all action branches, required fields, security constraints, return-data expectations, and fallback evidence paths. An agent has enough information to select the action and call it correctly.

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%, so the schema already documents parameters at a baseline level, but the description adds strong action-specific semantics: required fields per action, optional brokerCredentialId for positions, and guidance to omit brokerCredentialId for aggregate account queries. It also explains field usage such as accountDisplay and warns against inferring account suffixes from brokerCredentialId.

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 resource and operation family: read stored daily broker snapshot automation data, with clearly enumerated actions list, portfolio, positions, diagnostics, and run_now. It explicitly distinguishes snapshot data from realtime holdings by directing users to get_broker_positions for live position questions.

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 explicit when-to-use guidance per action, including using list first to find brokerCredentialId, using positions only for snapshot history/status/diagnostics, and preferring get_broker_positions for realtime holdings. It also provides a fallback path to list_deployments and get_deployment_position_telemetry when snapshots are empty or stale.

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

All BotSpot: AI Trading, Backtests and Bots 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