Skip to main content
Glama

BotSpot: AI Trading, Backtests and Bots

List saved broker credentials

list_broker_credentials
Read-onlyIdempotent

Lists saved broker credential metadata for the authenticated user. Raw credential values are never returned. Use an item's id as start_deployment.brokerCredentialId only when the user explicitly named that exact saved broker connection/account for this deployment. If no matching credential exists, call broker_connections(action="connect_existing") only when the user asks to create one. Returned metadata includes broker, displayName, paperOrLive, accountDisplay, keyNames, status, timestamps, brokerDataExecution, and one recommendedForReadOnlyAnalysis marker when an eligible connection exists. Interactive Brokers credentials are never eligible for isolated analysis or graphing; that data source is reserved for the separate backtesting path. All supported broker-data operations execute through the LumiBot adapter selected by the saved connection. For an ordinary read-only request where the user did not name an account, use the exact id of the item marked recommendedForReadOnlyAnalysis=true. Use another active item's exact id only when the user named that saved connection and it is not Interactive Brokers. accountDisplay is a safe label such as 'Account ending in 4821'; never infer an account suffix from the brokerCredentialId UUID. The tool never includes full account numbers, raw keys, Vault secret ids, or broker account secrets. connectionStatus explains whether the connection is usable, reconnectRecommended tells the Agent whether the user must reconnect, and connectionUpdatedAt is the latest safe renewal or connection update time. backtestData reports, for each asset class, the data source a backtest would use now, whether the user must link their own connection or key first, which ones qualify with this user's status for each, the first day of history when it is limited, and the next step. Read it before promising or starting a backtest that may need the user's own data. For a named broker, use brokerProvider; for one exact saved connection, use brokerCredentialId. These optional filters scope both returned items and recovery actions. An unrelated active account cannot suppress recovery for the selected connection. When no selected account is active and at least one item status is reconnect_required, the structured result includes a reconnect_broker recovery action. If any account is active, no global connection recovery action is returned; use an active account matching the requested broker and treat stale account statuses individually. Empty credentials return a connect_broker action. Present the returned action.message directly: identify the affected broker, explain that access is unavailable because its connection needs reconnecting, and provide the returned recovery action. BotSpot chat renders these structured actions as cards. Codex, Claude, Cursor, and other clients without native BotSpot cards must present the exact returned action.url as a clickable Markdown link; never refer to a card that the client did not render. Do not use a reconnect_required item for broker data, place_trade, or start_deployment until the user reconnects it. For a broker or exchange API key used to trade, tell the user to enable trading. Before setup or replacement, give this warning only when the broker offers those permissions separately: Warning. Only turn on trading permissions. Leave deposits and withdrawals off. Use the broker’s actual settings. If a broker bundles transfers with trading, explain that when relevant and keep trading available. Never ask the user to paste credentials into chat. For interactive setup or replacement, send the user to BotSpot Broker Connections (/account-settings/broker-connections) to enter the key there.

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

Input Schema

NameRequiredDescriptionDefault
brokerProviderNo
brokerCredentialIdNo

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?

Beyond the readOnlyHint and idempotentHint annotations, the description discloses that raw credentials are never returned, lists the returned metadata fields, explains reconnect_required handling, describes structured recovery actions, and states that Interactive Brokers credentials are never eligible for isolated analysis. It also covers client rendering differences and credential-handling safety, which materially exceeds what the annotations provide.

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 purpose and primary routing rule are front-loaded, and most sentences carry useful operational context for a safety-sensitive listing tool. The description is still very long for a two-optional-parameter read tool, and some setup/replacement warnings about trading permissions are only indirectly related to listing credentials, which keeps it below a 5.

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?

Given that there is no output schema and no schema parameter descriptions, the description is unusually complete: it describes returned metadata, recovery actions, filtering behavior, Interactive Brokers exclusions, reconnect handling, and presentation requirements. Nothing essential for calling the tool or interpreting its structured result appears missing.

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

Parameters3/5

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

Schema description coverage is 0%, so the description has to compensate for two undocumented parameters. It does explain the distinction: use brokerProvider for a named broker and brokerCredentialId for one exact saved connection, and notes that these optional filters scope both returned items and recovery actions. However, it does not clarify what happens when both filters are supplied, whether brokerProvider expects a canonical provider name, or how the filters interact beyond scoping.

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 first sentence states a specific verb and resource: it lists saved broker credential metadata for the authenticated user, and immediately clarifies that raw credential values are never returned. It also distinguishes this listing tool from broker_connections, start_deployment, and broker data/backtesting paths by explaining how returned ids and eligibility markers are meant to be used.

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?

The description gives explicit routing rules: use broker_connections(action="connect_existing") only when the user asks to create a matching credential, use start_deployment.brokerCredentialId only when the user names that exact saved connection, and use the recommendedForReadOnlyAnalysis marker for ordinary read-only requests. It also explains named-account exceptions and the Interactive Brokers exclusion, so the agent can choose correctly without guessing.

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.