Nimbus BCI

Grouped Statistics

stats.grouped

Read-onlyIdempotent

Cluster-aware group statistics across executions.

REQUIREMENT (read first): each execution must have been run with an evaluation plan that STORED per-SUBJECT accuracies for at least 3 subjects — e.g. leave-one-subject-out (LOSO) or grouped CV over

= 3 subjects. Session groups within one subject (multi-session single-subject runs) are refused with nimbus.stats.non_subject_groups — those are not independent subjects. A plain single-subject CV run with no subject/session grouping stores no group stats and fails with nimbus.stats.insufficient_groups.

HOW to get grouped stats: in the train graph set public_data.subject to >= 3 subjects (e.g. "S01,S02,S03", mode "all"), add an evaluation_plan node wired right after public_data with method: "loso" and evaluationTargetNodeId = your model node id, and keep an epoching node. See catalog.node_schema("evaluation_plan") and the mi_bciiv2a_csp_cv template for a working plan.

What it does: pools the per-subject accuracies each run's evaluation plan stored, then reports the between-group summary — mean accuracy with a t-interval and a one-sample t-test vs chance. Responses label groupKind, real groupKeys (subject ids like S01 when stamped or recoverable), perGroup (key + accuracy pairs), overall.pooledExecutionIds, and kindBreakdown / overall.kindBreakdown (per_subject vs loso etc. with n + mean — #470; between-group pooled mean is unchanged).

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": {
      "execution_ids": "<execution_ids>"
    },
    "name": "stats.grouped"
  }
}

Input Schema

Name	Required	Description	Default
`chance`	No	Chance level in [0, 1]; default 1/nClasses per execution.
`execution_ids`	Yes	1–25 executions (from execution.run) to pool. Runs without subject group stats are reported with nulls but do not fail the request — unless NONE qualifies (``nimbus.stats.insufficient_groups``) or only session groups are present (``nimbus.stats.non_subject_groups``).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 19, 2026

changedInput schema / properties / execution_ids / description

Previous value: -"1–25 executions (from execution.run) to pool. Runs\nwithout stored group stats (fewer than 3 groups) are reported\nwith nulls but do not fail the request — unless NONE of them\nhas group stats (then ``nimbus.stats.insufficient_groups``)."New value: +"1–25 executions (from execution.run) to pool. Runs\nwithout subject group stats are reported with nulls but do not\nfail the request — unless NONE qualifies\n(``nimbus.stats.insufficient_groups``) or only session groups\nare present (``nimbus.stats.non_subject_groups``)."

Changed1 schema field changedOct 18, 2026

changedInput schema / properties / execution_ids / description

Previous value: -"1–25 executions (from execution.run) to pool. Runs\nwithout stored group stats (fewer than 3 groups) are reported\nwith nulls but do not fail the request."New value: +"1–25 executions (from execution.run) to pool. Runs\nwithout stored group stats (fewer than 3 groups) are reported\nwith nulls but do not fail the request — unless NONE of them\nhas group stats (then ``nimbus.stats.insufficient_groups``)."

AddedOct 10, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds real behavioral context beyond them: which runs are silently reported with nulls versus which fail the whole request, and the named failure modes (nimbus.stats.insufficient_groups, nimbus.stats.non_subject_groups). It also discloses the response labeling scheme (groupKind, groupKeys, perGroup, pooledExecutionIds, kindBreakdown), which is more than the annotations convey.

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?

The purpose is front-loaded and the sectioning is readable, but the middle block is a pipeline-construction tutorial (public_data.subject, evaluation_plan node wiring, epoching) that belongs with catalog.node_schema and is not needed to invoke a two-parameter read tool. The '#470' issue reference and repeated error codes are developer-facing noise.

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 read-only aggregation tool with an output schema, this covers prerequisites, failure modes, and interpretation thoroughly. It is somewhat over-complete in one dimension (pipeline setup) while re-explaining return fields already carried by the output schema, but no information an agent needs to call it correctly 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% and both parameters are already documented in the schema, including the chance default of 1/nClasses per execution and the 1–25 execution cap. The description adds only the pooling framing and a restatement of the null/failure behavior already present in the execution_ids schema text, so the baseline 3 applies.

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 names a specific verb and resource — pooling per-subject accuracies stored by each run's evaluation plan and reporting a between-group summary with a t-interval and one-sample t-test vs chance. It also scopes exactly what input qualifies (subject-group stats only), which distinguishes it from a per-execution results tool.

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?

It states explicit preconditions (>= 3 subjects, LOSO or grouped CV) and explicit disqualifiers (session groups within one subject, plain single-subject CV), each tied to a specific error code. It even routes the agent to catalog.node_schema and the mi_bciiv2a_csp_cv template when the prerequisite is unmet.

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

All Nimbus BCI 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.