Skip to main content
Glama
Sign In

BotSpot: AI Trading, Backtests and Bots

by io.github.grzesir
OverviewDiscussionsAdmin

Browse public Marketplace strategies

marketplace_strategies
Read-onlyIdempotent

action="list" searches approved strategy listings, action="get" reads one listing, action="get_code" reads its published files when code access was granted.

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

action="list": Search public Marketplace strategies

No other fields required. Browse the same public approved catalogue as the Marketplace Live Trading page. Default discovery requires working execution evidence; verified all-time returns at or above -5% rank first, followed by working records with unavailable returns and their reasons, never an invented zero. No default account-age gate. Balances alone do not establish execution health. Paper and real proof accounts remain separate; show a money-mode label only when accountModeVerified is true. All live/performance numbers are percentage points, so 38.13 means +38.13%. Read asOf, method and unavailable reasons; never recalculate investment returns from balances. Backtests are separate. Follow nextOffset while hasMore before claiming a complete list. Generic starter requests omit query; never invent a ticker or asset preference. Named strategies use a short plain-language query. Read the selected listing requirements and wait for user selection before copying or preparing a start. Distinguish returned broker/account capability requirements from data subscriptions and API keys or secrets; saying no runtime API keys are listed does not replace a returned stock-broker or options-permission requirement. Report managed-AI credit requirements only when the returned evidence establishes them. Include every returned required key and matching secret, paid data subscription, broker permission and managed AI credit requirement; managed provider access does not mean free AI. Explicit mode, asset, history and numeric-return preferences remain supported; unavailable working records are an explicit numeric-filter exception. return_best aliases live_allTime; return_worst sorts verified observed returns ascending with unavailable entries last; drawdown_best uses backtest drawdown.

action="get": Read a permission-filtered Marketplace strategy

Required fields: listingId. Returns one approved strategy listing with the same canonical public account history and automatic paper/real selection as the Marketplace website. adjustedReturn is a fraction (0.5 means +50%); history is indexed to 100, never dollar balances. Unavailable adjusted performance stays unavailable, never replaced by the publisher's account. Holdings, filled trades and open orders require explicit permission for that same account; publisher permissions never grant access to another owner's selected account. Read each listing's returned capabilities and account projection independently: positions=true with returned holdings is shared holdings evidence, while an empty or unavailable projection is not evidence that every listing hides holdings. Describe unavailable data only for the specific listing and capability that returned it. Also returns the listing page link and required API key names, never key values, broker identifiers, sibling strategies, private setup notes or a separate account listing. Copy marketplaceUrl verbatim, including its scheme, origin, path and listing ID; do not rebuild or downgrade an HTTPS link. BotSpot-managed AI research uses BotSpot AI credits. When returned description/details establishes managed AI research, include that operating requirement in this listing's comparison row even if runtimeSecrets is empty: that empty array means no customer-supplied keys, not free managed AI. Keep customer data keys/subscriptions separate; never ask for the platform's model-provider key or invent a credit price. Before sending the comparison, check every listing's operating requirements and sharing flags against its own returned evidence; never invent aggregate permission counts. Listing updatedAt is publication metadata, not the observation time of account performance or holdings.

action="get_code": Read authorized published strategy files

Required fields: listingId. Returns only non-hidden files from the immutable published strategy revision, and only when code access was explicitly granted. Runtime secrets, setup notes, prompts, broker bindings, and hidden files are never returned.

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": {
      "action": "<action>"
    },
    "name": "marketplace_strategies"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNoUsed with action="list".
sortNoUsed with action="list".
limitNoUsed with action="list".
queryNoUsed with action="list".
actionYesWhich operation to run: "list", "get", "get_code". See the tool description for each one.
offsetNoUsed with action="list".
creatorNoOne creator's listings: their handle (as in botspot.trade/community/<handle>) or account id. Shows all of that creator's public listings. Used with action="list".
qualityNoUsed with action="list".
activityNoDefault running requires working execution. Explicit all includes stopped or unhealthy bots only when their published account has historical records; disclose the returned runtime status. Use quality=all as well when requesting any return history without the default return threshold. Used with action="list".
listingIdNoUsed with action="get", action="get_code". Required for action="get", action="get_code".
assetClassNoUsed with action="list".
minHistoryDaysNoUsed with action="list".
minAllTimeReturnNoUsed with action="list".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / creator
      Added value: +{
+  "description": "One creator's listings: their handle (as in botspot.trade/community/<handle>) or account id. Shows all of that creator's public listings. Used with action=\"list\".",
+  "maxLength": 80,
+  "type": "string"
+}
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare it read-only, idempotent and non-destructive, yet the description still adds material behavior: results are permission-filtered, get_code returns only non-hidden files from the immutable published revision and only with explicit code access, secrets and key values are never returned, holdings require permission on that same account. It also documents pagination contract (nextOffset/hasMore) and data conventions (adjustedReturn is a fraction, history indexed to 100, returns in percentage points), none of which the annotations disclose.

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?

Structure is good — action dispatch is front-loaded and each action has its own heading — but the prose is extremely dense and a large share is agent output policy (how to label money mode, how to report credit requirements, never to invent aggregate permission counts) rather than tool-invocation guidance. Several 'never invent X' rules repeat the same idea in different registers, and mixed-concern paragraphs like the list section's reporting rules slow an agent looking for argument semantics.

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 13-parameter, three-action tool with no output schema, the definition covers what an agent needs to call it correctly and interpret results: required fields per action, pagination loop termination, return-value shape (marketplaceUrl, required key names, capabilities, account projection, asOf/method/unavailable reasons). Nothing critical to correct invocation is left implicit.

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 100%, so a 3 is the baseline; the description earns above that by explaining semantics the schema cannot: return_best aliases live_allTime, return_worst sorts verified observed returns ascending with unavailable entries last, drawdown_best uses backtest drawdown, and default quality imposes a working-execution evidence threshold. sort/quality/activity meaning is substantially sharpened beyond the enum labels.

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 line crisply maps each of the three actions to a distinct verb+resource: list searches approved listings, get reads one, get_code reads published files. The scope (public approved catalogue, code only when access was granted) is unambiguous. It stops short of naming a sibling to contrast with (e.g. my_marketplace_publications or list_strategies), so an agent must infer the boundary from 'public approved' alone.

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 guidance per action: 'Set "action" to choose the operation. Only send the fields listed for that action.' It also states operating conditions an agent would otherwise guess wrong — follow nextOffset while hasMore, omit query for generic starter requests, wait for user selection before copying or preparing a start, and use quality=all for any return-history request. This is genuine when/when-not guidance, not boilerplate.

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