Loading ToolBench
MCP server that lets an orchestrating agent delegate self-contained subtasks to a local model running under Ollama
Strong tool definitions with comprehensive schemas, clear descriptions, and good parameter documentation. All four tools have explicit input schemas with types and descriptions. Tool names follow verb_noun convention (delegate, list, get, transform). Descriptions are detailed and context-aware (100-300 chars), explaining WHAT, WHEN, and WHY. Parameters include constraints (enums, min/max, minLength/maxLength). However, output schemas are not formally documented in the source, responses are described narratively rather than as structured JSON Schema. Error handling guidance is minimal. No explicit idempotency or retry semantics documented.
Hand a self-contained subtask to a local model running under Ollama and return its answer. Reads files but never writes them. Intended for offloading bulk or mechanical work — summarising long logs, drafting docstrings, extracting structured data, converting formats, first-pass triage — so the orchestrating agent keeps its own context free. The local model sees only what is passed in this call, so the instructions must be complete on their own. A context file that is a PNG, JPEG, GIF or WebP is sent as an image to a vision model, not as prompt text. Any other non-text file is refused rather than decoded into unreadable bytes.
Report the capabilities of one installed Ollama model, most importantly its maximum context length. Use this to size the 'num_ctx' argument before delegating a large input. Ollama silently truncates prompts that exceed the context window, which looks like the model producing poor output rather than an error, so checking this first is worthwhile whenever the input is big.
List the models currently installed in the local Ollama instance. Use this before delegating work, so that a model tag is chosen from what is actually installed rather than guessed. It does not download, modify or run anything.
Apply one instruction to each of several files using a local Ollama model, writing the results to disk and returning a unified diff per file. Each file is processed independently in its own request, so the instruction must make sense file by file. Intended for repetitive edits that do not need cross-file reasoning: adding docstrings, renaming a symbol, converting comment style, adding type annotations, updating a licence header. Files are written in place. Review the returned diffs, and prefer running with dry_run=true first on an unfamiliar codebase. Output that comes back drastically shorter than the original is discarded rather than written, since that indicates a truncated generation.
Output schemas not formally documented. Tool descriptions explain results narratively (e.g., 'return its answer', 'return a unified diff') but do not provide JSON Schema definitions for response structure. LLMs cannot reliably parse unstructured output or plan downstream tool chains without knowing field names and types.
No error recovery guidance. Tool descriptions do not explain what errors can occur, how to classify them (retryable vs. fatal), or what the LLM should do next. E.g., 'Ollama silently truncates prompts' is mentioned but no guidance on detecting or recovering from truncation.
Destructive tool (ollama_transform_files) lacks confirmation/dry-run pattern in schema. While dry_run parameter exists, no explicit guidance that agents should call with dry_run=true first to review diffs before writing. No confirmation step enforced.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2025-06-18+ | v2 |
Parameter 'model' is optional with a default, but the default value is not stated in the parameter description itself, only in the tool description and constants. LLMs may not infer the fallback, leading to confusion about which model will run.
No idempotency semantics documented. Tools that read files (delegate_task, list_models, get_model_info) are implicitly idempotent, but transform_files writes to disk and could produce different diffs on repeated calls if the model output varies. No guidance on retry safety.