Skip to main content
Glama
Sign In

BotSpot: AI Trading, Backtests and Bots

by io.github.grzesir
OverviewDiscussionsAdmin

Browse public Marketplace accounts

marketplace_accounts
Read-onlyIdempotent

action="list" lists approved account publications; action="get" reads one account publication.

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

action="list": List public Marketplace accounts

No other fields required. Lists approved account publications. Strategy identities and broker account identifiers are never included. Performance fields remain absent unless the owner explicitly granted them.

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

Required fields: publicationId. Returns account performance, positions, and verified filled trades only when each capability was explicitly granted. Exact quantities are separately permissioned. Broker account and credential identifiers 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_accounts"
  }
}

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". See the tool description for each one.
offsetNoUsed with action="list".
publicationIdNoUsed with action="get". Required for action="get".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations, the description discloses important permission behavior: performance fields appear only with explicit grants, exact quantities are separately permissioned, and broker account and credential identifiers are never returned. It also states that strategy identities and broker account identifiers are omitted from list results. This adds strong operational context for a read-only, open-world tool.

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 front-loaded and organized by action, with useful section headings and minimal filler. There is some repetition between the opening action summary and the later action-specific headings. It remains readable and appropriately sized.

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?

Given seven parameters and no output schema, the definition covers the key invocation rules, required fields, and permission-filtered return behavior well. It is less complete about list response shape, pagination behavior, and defaults for sorting and limits, though the schema documents those parameters. The overall definition is sufficient for correct invocation but not fully comprehensive.

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 already 100%, so the baseline would be 3. The description adds action-dependent meaning by clarifying that "list" requires no additional fields and "get" requires publicationId, and it reinforces that only fields listed for the selected action should be sent. It does not add much detail about mode, sort, limit, query, or offset beyond the schema descriptions.

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 description uses specific verbs and resources: "lists approved account publications" and "reads one account publication." It clearly scopes the tool to public Marketplace account publications and distinguishes the list and get operations. The public/approved framing also separates it from owner-side publication management.

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?

It explicitly tells the agent to set "action" to choose the operation and to send only fields valid for that action. It also states that "list" needs no other fields and "get" requires publicationId. It does not name sibling alternatives or when not to use this tool, so it falls short of full alternative routing.

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