BotSpot: AI Trading, Backtests and Bots

Fetch linked account history for a deployment

get_portfolio_series

Read-onlyIdempotent

Returns the owned linked-account history plus a fresh direct broker balance through the same canonical source used by Python internal_data.get. This is the whole linked account, not strategy-attributed or cash-flow-adjusted investment performance. Use show_bot_activity first for a current account report; use this reader for a requested historical graph or benchmark comparison. Inspect the executed account rows and select their actual observed endpoints for the requested sessions. Do not look up fabricated midnight or shifted next-day timestamps; a calendar-day label is not the observation clock. Claim a numerical mismatch only when an executed comparison establishes it. Unverified funding or mark timestamps do not prove that returned holding values fail to add up or differ from quantity times matched prices. For whole-account attribution, retain cash in the opening account-value denominator. Explain its dilution of market exposure separately from measured gains; cash has no demonstrated price gain unless a returned cash-interest or other gain record establishes one. An unknown cash gain is not a measured zero. This dataset does not calculate per-holding price contributions. For a portfolio-movement explanation, fetch the matched holding prices and execute the calculation with run_data_analysis; a supplied-input card or mental arithmetic does not execute it. Recover a missing required symbol with dated public search before declaring it unknown, while preserving any known partial subtotal. Supports frequency filtering ('all' retains every observation; 'hour' and 'day' retain the latest observation per UTC bucket). start/end constrain the returned window; limit bounds the newest displayed rows to 1-1000. fullDatasetObservationCount counts the complete registered dataset; count counts only this filtered display. A later analysis execution refreshes its broker endpoint, so derive chart captions and statistics from the rows actually executed, never from a preview count. Copy analysisDatasetId into capabilities.internalData.datasetIds and read it with internal_data.get to register portfolio provenance; never use this tool name as sourceIds or hardcode its rows. Preserve the returned observation/retrieval time basis; neither establishes a market-price timestamp. Broker-read failures are visible tool errors, not permission to label old telemetry current.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "deploymentId": "<deploymentId>"
    },
    "name": "get_portfolio_series"
  }
}

Input Schema

Name	Required	Description	Default
`end`	No
`limit`	No
`start`	No
`frequency`	No
`deploymentId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), and the description adds genuine behavior: what the dataset includes and excludes, that broker-read failures surface as visible tool errors, that a later analysis execution refreshes the broker endpoint, and that no per-holding price contributions are computed. Some sentences are agent-conduct warnings rather than tool behavior, which keeps it below 5.

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 in the first sentence, but the body is a dense wall of run-on sentences mixing invocation semantics with anti-hallucination policy (fabricated timestamps, midnight labels, numerical mismatch claims) that does not help an agent decide or invoke. Useful facts about analysisDatasetId and the count fields are present but hard to extract.

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?

No output schema exists, so the description must carry return-value context, and it does: analysisDatasetId registration flow via internal_data.get, fullDatasetObservationCount vs count, observation/retrieval time basis, and the absence of per-holding price contributions. Complete enough for a read-only analytics fetch.

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 0% schema description coverage, the description compensates well: it defines frequency semantics per enum value ('all' keeps every observation, 'hour'/'day' keep the latest per UTC bucket), the start/end window, the limit range of 1-1000, and the distinction between fullDatasetObservationCount and count. Only deploymentId is left implicit.

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 opening sentence names a specific verb and resource ("Returns the owned linked-account history plus a fresh direct broker balance") and distinguishes the dataset from siblings by stating it is "not strategy-attributed or cash-flow-adjusted investment performance." Firm scope boundaries make it identifiable, though the core statement is somewhat buried under later elaboration.

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?

Explicit routing: "Use show_bot_activity first for a current account report; use this reader for a requested historical graph or benchmark comparison," plus a second alternative path via run_data_analysis for portfolio-movement calculations. Both when-to-use and when-not-to-use are stated with named siblings.

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 tools Inspect

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.