Skip to main content
Glama

BotSpot: AI Trading, Backtests and Bots

Get broker positions

get_broker_positions
Read-onlyIdempotent

Read-only: fetches current positions directly from saved broker credentials, not from deployment telemetry or snapshot automation. For current performance of a named bot or a follow-up about its holdings, use show_bot_activity first; it performs its own exact-linked broker read. Use this tool after that report for a failed or stale current read, not as a preflight before the report. For general standalone holdings or allocation questions, use show_holdings first; it fetches and separates the accounts itself. Use this raw reader for specifically requested raw position details or a missing/failed report read. When the user asks what they own across one broker provider, omit brokerCredentialId, pass brokerProvider using the exact provider returned by list_broker_credentials, and call this tool once. For all connected accounts, omit both fields. The tool safely aggregates matching active saved accounts and returns per-account partial failures without discarding successful holdings. Every successful account, flattened position, and partial failure includes accountDisplay when saved account metadata is available. Use that safe label (for example, 'Account ending in 4821') in user-facing account breakdowns; never infer an account suffix from brokerCredentialId. Full account numbers are never returned. Pass brokerCredentialId only when the user explicitly identifies one saved account. Present current values and quantities as plain numbers/tables; gain/loss bars belong only to profits or returns. A single position needs metrics, not a market-value-versus-P&L bar chart. Complete positive holdings allocation can use a labeled pie/donut; missing or negative data cannot establish a pie. Keep account modes and currencies separate. For expiration option payoff, require verified entry premium, contract inputs and explicit fee assumptions, not current market value. External MCP clients should use readable Markdown tables and exact returned clickable action URLs rather than claim BotSpot cards are visible. Use symbol to narrow to one asset. includeCashPositions defaults to false. Never pass raw broker credentials.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_broker_positions"
  }
}

Input Schema

NameRequiredDescriptionDefault
symbolNo
outcomeNoSelected prediction contract outcome; Kalshi uses yes or no.
assetTypeNo
brokerProviderNo
brokerCredentialIdNo
includeCashPositionsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / symbol / maxLength
      Previous value: -64New value: +256
  2. Changed2 schema fields changed
    • changedInput schema / properties / assetType / enum
      Previous value: -[
      -  "stock",
      -  "option",
      -  "future",
      -  "crypto_future",
      -  "cont_future",
      -  "forex",
      -  "crypto",
      -  "index"
      -]New value: +[
      +  "stock",
      +  "option",
      +  "future",
      +  "crypto_future",
      +  "cont_future",
      +  "forex",
      +  "crypto",
      +  "index",
      +  "prediction_contract"
      +]
    • addedInput schema / properties / outcome
      Added value: +{
      +  "description": "Selected prediction contract outcome; Kalshi uses yes or no.",
      +  "maxLength": 64,
      +  "minLength": 1,
      +  "type": "string"
      +}
  3. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the safety profile is covered; the description nonetheless adds real behavior: aggregation across matching active saved accounts, per-account partial failures that do not discard successful holdings, accountDisplay labeling, and the guarantee that full account numbers are never returned. The only gap is that it does not characterize rate limits or result ordering/size.

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?

The selection and parameter rules are correctly front-loaded, but the bulk of the text is presentation policy (pie/donut eligibility, gain/loss bars, option payoff premium requirements, Markdown tables, BotSpot card claims) that does not help an agent decide whether or how to call this tool. Roughly half the description is off-topic for tool invocation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/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 usefully sketches the return shape (per-account results, flattened positions, partial failures, accountDisplay, no full account numbers), and routing is fully specified. It falls short only on two schema parameters (assetType, outcome) and on any statement of result limits or ordering.

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?

With schema coverage at only 17% over six parameters, the description carries most of the burden and does so for four of them: brokerProvider (must be the exact provider returned by list_broker_credentials), brokerCredentialId (only when the user explicitly identifies one saved account), the omit-both rule for all accounts, symbol (narrow to one asset), and includeCashPositions defaulting to false. assetType is never mentioned and outcome is left entirely to the schema.

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?

Opens with a specific verb and resource ('fetches current positions directly from saved broker credentials') and immediately disambiguates the source ('not from deployment telemetry or snapshot automation'). It names the sibling tools it is not (show_bot_activity, show_holdings) so an agent can route 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?

Gives explicit ordering rules ('use show_bot_activity first... use this tool after that report for a failed or stale current read, not as a preflight'), a second alternative for standalone holdings ('use show_holdings first'), and the precise condition for using this tool ('specifically requested raw position details or a missing/failed report read'). It also states the branching rule for brokerProvider vs brokerCredentialId vs omitting both.

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.