Loading ToolBench
Two Model Context Protocol (MCP) servers for self-hosted, local AI: manage and train Ollama/vLLM models, and route questions and tasks to local LLMs through Claude, ChatGPT or local models. Use the compute of your existing hardware, and let the models tap data on your machines when you wire them in.
This MCP server has severe definition quality gaps. While it exposes 19 tools with basic descriptions, the schemas are almost entirely undocumented. Of the 19 tools listed, only 2 have any visible input schema structure (fetch_model and remove_model, each with a single 'model' parameter). The remaining 17 tools lack any documented input parameters, types, or constraints. Most tool descriptions are minimal (10-30 chars), falling below the 50-200 char baseline for LLM-optimized descriptions. No output schemas are documented for any tool. Error handling, parameter validation, and recovery guidance are absent. The naming is generally acceptable (verb-first convention), but the lack of schema documentation for 89% of tools is a critical blocker for LLM selection and safe invocation.
Cancel an active training run
Check isolation configuration
Check training environment configuration
Create a model variant
Fetch a model from Ollama
Get status of a specific job
List available adapters
List all jobs on the machine
17 of 19 tools (89%) lack documented input schemas. No parameter types, constraints, enums, or descriptions visible in the provided source. LLMs cannot safely infer what parameters these tools accept or what values are valid.
Tool descriptions are uniformly short (10-35 chars), below the 50-200 char LLM-optimized baseline. Descriptions lack context on WHEN to use the tool, WHAT it returns, or any prerequisites. Example: 'Read state of the model machine' does not explain when an agent should call this vs another status tool, or what fields the response contains.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | 2026-07-28+ | v2 |
List model variants
List models on the machine
Remove a model from the machine
Remove a model variant
Show details of a model variant
Start the inference service
Start a training run
Read state of the model machine
Stop the inference service
Switch the inference service to a different model
Get status of training operations
No output schemas documented for any tool. LLMs do not know what fields, types, or structure to expect in responses. This breaks tool chaining and forces agents to guess how to extract relevant data.
No error handling or recovery guidance. Tools that fail (e.g., model not found, job already running) have no documented error responses or remediation steps. LLMs cannot distinguish retryable errors from fatal ones.
Destructive tools (remove_model, remove_variant, cancel_training) lack confirmation or dry-run support. No indication that these operations are irreversible or what safeguards exist to prevent accidental data loss.
List tools (list_jobs, list_variants, list_adapters, models_present) lack pagination parameters (limit, offset, page, cursor) and output size constraints. Returning unbounded lists risks context window exhaustion.