gpu-router

Overview Schema Source Related Servers Discussions Admin

Gpu Route

gpu_route

Read-only

Preview where a training job would run and why, without submitting it. Shows routing candidates, approval rules, and which files would ship.

Instructions

Dry run: where a job would run and why, without submitting anything. Same arguments as gpu_submit. Returns {"spec", "route": {outcome place|wait|no_fit, chosen, candidates (ranked, each with a one-line reason and quota left), rejected (provider + why), reason, hours, hours_source}, "approval": {would_ask, reason} (what the approval rules say right now), "bundle" (what would ship, bundle.left_out = git-ignored paths that would not), "guidance"}. Use it before a long or big-VRAM job, when the user asks where something would run, or to check that the files the job needs ship. Read-only.

Input Schema

TableJSON Schema

Name	Required	Description
`gpu`	No	GPU type constraint, e.g. T4. Usually omit.
`args`	No	Arguments passed to the script, e.g. ["--epochs", "10"].
`data`	No	Datasets as [NAME=]PATH (relative to project_dir, or absolute) or hf://datasets/... URIs. Uploaded once, cached by content, readable at gpu.data_dir()/NAME on the GPU.
`hours`	No	Honest expected wall-clock runtime in hours (e.g. 0.25 for 15 minutes). Agent jobs with no hours or over 1 hour wait for approval, and a job still running well past its hours is stopped for approval.
`smoke`	No	A quick smoke test: prefers this Mac (MPS) and runs in minutes.
`script`	No	Script to run, relative to project_dir (e.g. train.py or scripts/train.py). Omit to use gpu.yaml's `script`. A non-.py value runs as a command line, split like a shell would, e.g. `bash jobs/run.sh`. Paths in it and in args are relative to project_dir and must ship (see bundle.warnings).
`include`	No	Paths or globs relative to project_dir that ship even if git ignores them, e.g. ["third_party/", "data/crops/.png", "experiments/*/out"] (a directory ships whole; nested git repos too). Added to gpu.yaml `include:`. For code and small files; pass datasets as data. Credential files never ship.
`verbose`	No	Return the full documents (null fields, every event) instead of the trimmed ones.
`vram_gb`	No	GB of GPU memory the job needs (a hard filter).
`provider`	No	Pin one provider (kaggle, colab, local, ...). local = this Mac through gpu-router's queue, one job at a time. Usually omit and let gpu-router choose.
`project_dir`	Yes	Absolute path of the project directory on this Mac (where the script and gpu.yaml live; inside a git repo the whole repo ships). Example: /Users/me/code/yolo

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Oct 17, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations declare readOnlyHint=true and openWorldHint=false; the description's 'without submitting anything' and 'Read-only' are consistent and reinforce that no job is launched. It adds substantial behavioral context beyond annotations — the approval rules ('would_ask, reason'), and that bundle.left_out are git-ignored paths that would not ship. It stops short of describing latency or limits, so 4 rather than 5.

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?

Purpose and usage are front-loaded, but the middle is a dense minified enumeration of the return payload (route, approval, bundle, guidance) that duplicates an existing output schema. That enumeration is heavy relative to its marginal value and crowds out the concise framing.

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?

The tool is well covered: annotations carry the safety profile, the input schema is fully documented, and an output schema exists. The description is complete enough to call it correctly, though its return-value walkthrough partly restates what the output schema already provides.

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 100%, so the schema already documents all 11 parameters thoroughly; the description adds only the meta-hint that it takes 'Same arguments as gpu_submit.' Per the baseline rule, a 3 is appropriate when the schema does the heavy lifting and the prose adds little parameter-level meaning.

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 — 'Dry run: where a job would run and why, without submitting anything' — and immediately contrasts it with the sibling it mirrors ('Same arguments as gpu_submit'). An agent can separate it from gpu_submit without opening either schema.

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?

Explicit trigger conditions: 'before a long or big-VRAM job, when the user asks where something would run, or to check that the files the job needs ship.' It also names the counterpart action (gpu_submit) and the safe/read-only nature, leaving nothing to inference.

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

Deploy Server