Skip to main content
Glama
Sign In

Runcrate

by io.github.aeonmindai
OverviewDiscussionsAdmin

Test a cluster interconnect

run_cluster_nccl_test

Start an NCCL all-reduce test across every GPU on every node, once every machine of the cluster is up, to measure how fast the machines move data together before a long run. It uses every GPU, and the cluster is billed meanwhile as always. One test runs at a time per cluster; it takes a few minutes and at most 10. Returns the test with status running. The result is in get_cluster (last_test) once its status is passed or failed: result.sizes has the bus bandwidth in GB/s (busbw_gb_s) per message size, peak_busbw_gb_s the best, and result.note why it stopped early on a slow link.

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": {
      "id": "<id>"
    },
    "name": "run_cluster_nccl_test"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesCluster ID
workspaceNoWorkspace ID (optional: defaults to the authenticated workspace)
environmentNoEnvironment name (optional: defaults to the environment this session acts in)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare readOnly=false, idempotent=false, destructive=false, openWorld=false; the description adds substantive context beyond them — that all GPUs are consumed, that billing accrues during the test, that only one runs at a time per cluster, and that it takes a few minutes up to 10. It also discloses the async return (status running) and where the terminal state appears.

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?

Front-loaded with the action and its purpose, then constraints, then return format. It is longer than most, but the later clauses about result.sizes and peak_busbw_gb_s earn their place because there is no output schema; a slightly tighter phrasing could trim the billing aside.

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?

With no output schema, the description compensates fully: it explains that the call returns immediately with status running, that the final result must be fetched via get_cluster's last_test, and names the specific fields (busbw_gb_s per size, peak_busbw_gb_s, note) the agent will need. Nothing required to invoke or interpret the call is 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 coverage is 100% with only three simple, self-documented parameters (id, workspace, environment), so the schema carries the semantics. The description adds nothing about the parameters themselves, which is acceptable given the high coverage but earns only the baseline.

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?

States a specific verb and resource — start an NCCL all-reduce test across every GPU on every node — plus its purpose (measure interconnect speed before a long run). It is clearly distinguishable from siblings, and it explicitly names get_cluster as the place the result lands, so the agent knows this is the async-trigger half of a two-tool flow.

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?

Gives the precondition (once every machine of the cluster is up), the motivation (before a long run), the concurrency limit (one test at a time per cluster), and the routing to get_cluster for the outcome. Little is left to inference about when and how to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Runcrate 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