Skip to main content
Glama

BotSpot: AI Trading, Backtests and Bots

Show account overview

show_account_overview
Read-onlyIdempotent

Answers "How is my account doing?" with account value, cash, unrealized P&L and position count for each connected broker account, an account value history chart from saved daily snapshots, and an allocation donut when holdings are complete. Paper and live accounts are shown separately. Accounts that need reconnecting come back with a reconnect link. Read-only. Shows an interactive panel in apps that support MCP Apps; always returns a text summary and a botspot.trade link.

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": "show_account_overview"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNoall
brokerCredentialIdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior5/5

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

Beyond the safety annotations, it discloses that history comes from saved daily snapshots and that the allocation donut depends on complete holdings. It also explains paper/live separation, reconnect links for problematic connections, conditional MCP Apps rendering, and the guaranteed text-summary-and-link fallback.

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 compact and front-loaded, progressing logically from purpose and outputs to presentation, connection problems, and fallback behavior. The opening sentence is somewhat dense, and the standalone Read-only statement repeats the annotations rather than adding new information.

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 detailed account metrics, conditional charts, reconnect behavior, and output fallback provide valuable operational completeness. The unexplained optional filters and absence of sibling routing remain gaps, but the tool's simple flat two-parameter interface keeps those gaps from being severe.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description never explains that mode filters live, paper, or all accounts with all as the default, or that brokerCredentialId can scope the request to one credential. Saying that paper and live accounts are displayed separately describes presentation rather than parameter behavior, so it does little to compensate for the undocumented schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the user question, the per-broker-account resource, and concrete outputs including value, cash, P&L, position counts, history, and allocation. This is substantially clearer than a generic overview label, but it does not explicitly draw a boundary with get_broker_account_snapshot or the narrower show_* siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The opening question provides a clear when-to-use context for a high-level account health check. There are no when-not conditions or named alternatives for users who instead need a snapshot, holdings, or an individual position.

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.