Skip to main content
Glama

BotSpot: AI Trading, Backtests and Bots

by io.github.grzesir
OverviewDiscussionsAdmin

Browse public Marketplace strategies

marketplace_strategies
Read-only

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 -20% 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.

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".
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. First observed

TDQS

A4.6/5.0
Behavior5/5

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

With only readOnlyHint=true from annotations, the description carries heavy behavioral weight and delivers: permission-filtered access rules, that publisher permissions never grant access to another owner's account, exactly what is withheld (runtime secrets, prompts, broker bindings, hidden files), and no-fabrication rules for unavailable returns. This is far beyond what the annotations declare.

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 strong: a front-loaded action map followed by per-action headings. However the prose is very long for a three-action read tool, and several admonitions repeat ('never invent' appears in multiple forms, plus lengthy downstream reporting rules about comparison rows and money-mode labels) that could be consolidated without losing instruction.

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?

Twelve parameters with no output schema would normally demand more, and the description supplies the return shape (adjustedReturn as a fraction, history indexed to 100, nextOffset/hasMore), unavailable-data semantics, and per-listing permission independence. An agent can call and interpret all three actions correctly from this text alone.

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 baseline 3 applies, but the description adds genuine semantics the schema's 'Used with action="list"' placeholders lack: return_best aliases live_allTime, return_worst sorts verified returns ascending with unavailable entries last, drawdown_best uses backtest drawdown, and quality/activity interaction when requesting unfiltered return history. Mode, asset and numeric filters are also explained as behavior, not just names.

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 opening sentence maps each of the three actions to a specific verb+resource: list searches approved listings, get reads one listing, get_code reads its published files. An agent can distinguish this from siblings like get_my_marketplace_publication or marketplace_accounts without opening the schema.

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?

Gives concrete when-to guidance: omit query for generic starter requests, include a short plain-language query only for named strategies, wait for user selection before preparing a start, and follow nextOffset while hasMore. It does not explicitly route to sibling tools (e.g. own-publication tools), so it stops short of the full when/when-not/alternative picture.

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