io.github.bdbais/routeai
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| fleet_statusA | Nodes, health, loaded models, routing preview per category, token savings and whether a benchmark or the first setup is due. |
| fleet_setupA | Create or replace the fleet configuration by probing the user's Ollama servers: picks installed models per category and lists recommended models that are missing (with size and hardware). Without |
| fleet_nodesB | Add, remove, enable or disable ONE machine in the fleet configuration, keeping every other machine's settings and comments. 'add' probes the new server and picks its models per category; 'list' only shows the current machines. The previous file is kept as a backup. |
| fleet_delegateA | Delegate ONE small task to a local model and get the result. The server reads |
| fleet_delegate_batchA | Apply the same instruction to many files in parallel across all nodes (one task per file). Returns a job_id immediately; poll fleet_job. Use |
| fleet_jobC | Progress and results of a background job (batch, long task, benchmark or pull). |
| fleet_feedbackA | Tell the fleet how good a delegated result was, after you reviewed it. good = used as is, fixed = needed corrections, rejected = unusable. This trains the router. |
| fleet_benchA | Start the self-learning benchmark in the background: graded coding tasks per category on every node/model, plus optional resource probes. Returns a job_id; the finished job contains a report with recommendations for fleet.toml. |
| fleet_usageA | How much the fleet was used and what it saved: tokens processed per node (local machines and providers) and per model, cost in USD, today's quota use, Claude tokens saved, and a breakdown per category. This project by default; scope 'all' for every project, |
| fleet_queueA | Queue work the fleet finishes on its own, so it keeps going while you are paused (usage limit reached, session closed) - slow but steady. Actions: 'add' (same fields as fleet_delegate; give an output_path so the result lands on disk), 'list' (queued, running and finished, with results to review), 'cancel' one by id, 'clear' (done | pending | all). |
| fleet_pullA | Download a model onto a node (ollama pull). Downloads can be many GB and take minutes: only with the user's approval. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
Each tool has a mostly distinct purpose, with action and resource clearly separated. The main overlaps are fleet_status vs fleet_usage on usage/savings metrics and fleet_job vs fleet_queue on background work status, but the descriptions clarify the boundaries.
All tools share the fleet_ prefix and use lowercase snake_case throughout. The verb/noun suffixes are intuitively matched to each operation, making the naming pattern highly predictable.
With 11 tools, the set is well-scoped and covers the fleet lifecycle without redundancy or bloat. Each tool has a clear role, and the count is comfortably within the ideal range.
The core workflow is well covered: set up the fleet, manage nodes, delegate single/batch tasks, queue work, monitor jobs, provide feedback, benchmark, and track usage. Minor gaps include no way to cancel a running background job or remove a pulled model.