Nimbus BCI

Leaderboard.Submit

leaderboard.submit

Submit a BYO python_model to a leaderboard track for server-side scoring.

Nimbus scores it server-side under the track's fixed protocol — you submit code, never results. Poll leaderboard.status with the returned submissionId; scoring takes minutes (classical) to tens of minutes (deep). Requirements must be plain PyPI names/specs (max 20, no URLs). Identical code resubmission is idempotent per track (deduplicated: true).

Verification contract (tier model X10): verification="verified" (default) is the server-side-scored submission above — on the hosted backend it is Pro-only; free accounts get a structured tier response. verification="unverified_local" names the designed Account-Free lane for locally-computed results; the backend has no unverified submission kind yet (see the response it returns — nothing is stored, and no row is faked). Anonymous callers get a structured login prompt: a submission needs an identity. Local (desktop/dev) backends keep their existing server-side quota behaviour.

Input Schema

Name	Required	Description	Default
`code`	No	Python source defining a class with fit(X, y, info) and predict(X) (<=256KB; validate first with python.validate). Required unless backbone_repo is set.
`name`	Yes	Display name on the board (<=100 chars).
`track`	No	"cross_subject" (default — full-data leave-one-subject-out, seed 42) or "pretrained_few_trial" (efficiency track: LOSO with a protocol-fixed 100-trials-per-subject cap; code that imports torch must declare its trained parameter count as a class attribute — PARAMS_TRAINED = <int> — which becomes the row's paramsTrained and is cross-checked when computable).	cross_subject
`class_name`	No	Contract class to instantiate; omit to auto-detect.
`dataset_id`	Yes	A dataset id from catalog.leaderboard ``submittableDatasets`` (e.g. "BNCI2014_001"). A dataset can appear under crossSubject and still be closed for submission (BNCI2014_008 is scored there and is not in the open set).
`requirements`	No	Optional PyPI requirements (e.g. ["sklearn>=1.4"]).
`verification`	No	"verified" (default; server-side scored, Pro on the hosted backend) or "unverified_local" (Account-Free locally-computed lane; see the tool description for its current backend status).	verified
`backbone_kind`	No	Checkpoint family for the BYO backbone lane — one of the zoo's supported kinds (e.g. "cbramod", "labram").
`backbone_repo`	No	HF 'org/name' repo id for the BYO backbone lane.
`backbone_license`	No	License declared for the backbone checkpoint.
`backbone_revision`	No	Full 40-char commit SHA pinning the backbone.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 19, 2026

addedInput schema / properties / verification

Added value: +{
+  "default": "verified",
+  "description": "\"verified\" (default; server-side scored, Pro on\nthe hosted backend) or \"unverified_local\" (Account-Free\nlocally-computed lane; see the tool description for its\ncurrent backend status).",
+  "type": "string"
+}

Changed2 schema fields changedOct 18, 2026

changedInput schema / properties / code / description

Previous value: -"Python source defining a class with fit(X, y, info) and\npredict(X) (<=256KB; validate first with python.validate).\nOmit when declaring a backbone instead."New value: +"Python source defining a class with fit(X, y, info) and\npredict(X) (<=256KB; validate first with python.validate).\nRequired unless backbone_repo is set."

changedInput schema / properties / dataset_id / description

Previous value: -"Open dataset id (see catalog.leaderboard crossSubject\ndatasets, e.g. \"BNCI2014_001\")."New value: +"A dataset id from catalog.leaderboard\n``submittableDatasets`` (e.g. \"BNCI2014_001\"). A dataset can\nappear under crossSubject and still be closed for submission\n(BNCI2014_008 is scored there and is not in the open set)."

Changed9 schema fields changedOct 15, 2026

addedInput schema / properties / backbone_kind

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Checkpoint family for the BYO backbone lane — one\nof the zoo's supported kinds (e.g. \"cbramod\", \"labram\")."
+}

addedInput schema / properties / backbone_license

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "License declared for the backbone checkpoint."
+}

addedInput schema / properties / backbone_repo

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "HF 'org/name' repo id for the BYO backbone lane."
+}

addedInput schema / properties / backbone_revision

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Full 40-char commit SHA pinning the backbone."
+}

addedInput schema / properties / code / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / code / default
```
Added value: +null
```

changedInput schema / properties / code / description

Previous value: -"Python source defining a class with fit(X, y, info) and\npredict(X) (<=256KB; validate first with python.validate)."New value: +"Python source defining a class with fit(X, y, info) and\npredict(X) (<=256KB; validate first with python.validate).\nOmit when declaring a backbone instead."

removedInput schema / properties / code / type
```
Removed value: -"string"
```

changedInput schema / required

Previous value: -[
-  "dataset_id",
-  "name",
-  "code"
-]New value: +[
+  "dataset_id",
+  "name"
+]

Changed1 schema field changedOct 13, 2026

addedInput schema / properties / track

Added value: +{
+  "default": "cross_subject",
+  "description": "\"cross_subject\" (default — full-data leave-one-subject-out,\nseed 42) or \"pretrained_few_trial\" (efficiency track: LOSO with\na protocol-fixed 100-trials-per-subject cap; code that imports\ntorch must declare its trained parameter count as a class\nattribute — PARAMS_TRAINED = <int> — which becomes the row's\nparamsTrained and is cross-checked when computable).",
+  "type": "string"
+}

AddedOct 10, 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 scoring latency (minutes to tens of minutes), the requirements constraint (max 20, plain PyPI specs, no URLs), the identity requirement for anonymous callers, and tier-gated behavior on the hosted backend. One tension: it claims identical-code resubmission is idempotent per track while the annotations set idempotentHint=false; the per-track dedup is a narrower statement than the tool-level hint, so it reads as clarification rather than flat contradiction, but it does muddy retry-safety reasoning.

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 first paragraph is tightly front-loaded and earns every sentence, but the verification-contract paragraph is dense with insider phrasing ('tier model X10', 'designed Account-Free lane', 'no row is faked') and partly restates the verification parameter's own schema description, and the trailing note about local backends' quota behaviour is tangential.

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?

For an 11-parameter tool spanning server-side, BYO-backbone, and local lanes, the description covers identity requirements, latency expectations, deduplication, tier limits, and where the dataset whitelist lives; return values are carried by the output schema, so nothing an agent needs before calling is missing.

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 description coverage is 100%, so the baseline is 3, and the description adds a constraint not present in the schema: requirements must be plain PyPI names/specs, max 20, no URLs. The verification parameter is also explained in prose (Pro-only on hosted, structured tier response for free accounts) rather than only as a restatement of the enum values.

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+resource+scope: 'Submit a BYO python_model to a leaderboard track for server-side scoring,' and immediately clarifies the core contract ('you submit code, never results'), which separates it from result-oriented siblings like leaderboard.mine and leaderboard.status.

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?

Routes the agent to concrete alternatives and next steps: poll leaderboard.status with the returned submissionId, validate code with python.validate, and source dataset ids from catalog.leaderboard submittableDatasets. It also spells out which verification lane applies to which account type, though it never frames an explicit 'do not use this tool when…' rule.

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.