BotSpot: AI Trading, Backtests and Bots

List deployment artifact runs

list_deployment_runs

Read-onlyIdempotent

Lists owner-scoped artifact runs for one live/scheduled deployment, or for up to 10 related deployments via deploymentIds. Every returned row includes deploymentId so run IDs remain paired with the deployment that owns them. Use this when the user asks what evidence is available for a deployment, or before inspecting why an agent bought, sold, or did nothing. For batches, partial=true and errors identify unavailable deployment lookups; do not treat those failures as proof that runs do not exist. When reporting event times, retain the returned timestamp and its time zone. Quoting the original UTC timestamp is valid; convert to a local zone only with its correct date-specific offset, and never apply an offset twice. This reads only manifest.json files in the deployment's artifact namespace; it does not read arbitrary S3 keys.

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_deployment_runs"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No
`deploymentId`	No
`deploymentIds`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Well beyond the annotations, it discloses owner scoping, the 10-deployment batch ceiling, partial=true plus errors on unavailable lookups with the warning not to infer absence of runs from those failures, and the read-boundary to manifest.json only. Annotations already cover read-only/idempotent/non-destructive, and the description adds real operational context on partial batch results.

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?

Purpose is front-loaded in sentence one, followed by batch-failure semantics and then timestamp handling, so the structure degrades gracefully. The two-sentence time-zone/offset-double-counting passage is a bit long for a listing tool but is defensible guidance, not filler.

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?

For a tool with no output schema and zero documented parameters, the description supplies scope, batch partial-failure semantics, read boundaries, and timestamp-reporting rules, which is most of what an agent needs. The remaining gap is pagination/limit behavior, which matters given a limit with maximum 100 and no explanation.

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 carries the burden and mostly succeeds: deploymentId is implicitly singular, deploymentIds is explicitly 'up to 10 related deployments', and the deploymentId-per-row guarantee ties output back to input. The limit parameter is never mentioned, so its meaning (page size vs. cap) is left entirely to the schema's numeric bounds.

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 gives a specific verb and resource ('Lists owner-scoped artifact runs'), states the two scoping modes (one deployment vs. up to 10 via deploymentIds), and the final sentence draws a hard boundary against generic file reads ('reads only manifest.json... does not read arbitrary S3 keys'), which is exactly the distinction an agent needs against the file/artifact-listing siblings.

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 names the triggering user intents ('what evidence is available for a deployment', or before investigating why an agent bought, sold, or did nothing), which is concrete when-to-use guidance. It lacks an explicit when-not-to-use clause or a named alternative for the single-artifact case, so it stops short of full routing guidance.

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.