Loading ToolBench
Local-first chat UI for Ollama with a constrained MCP tool bridge.
The server implements 3 read-only tools with basic descriptions and schemas. Naming follows verb_noun convention (list_files, grep_text, system_info), which is positive. However, descriptions are minimal (15-48 chars, well below the 194-char baseline), lack actionable context for LLM selection, and parameters have sparse documentation. Schemas are present but incomplete, many params lack descriptions entirely, and no output schemas are documented. Error handling is minimal (returns ok/error dict but provides no recovery guidance). The tools are well-scoped and appear to have reasonable input validation (sandbox path checks), but the overall packaging falls short of production readiness.
Busca needle en archivos de texto/código dentro de data/sandbox.
Lista archivos/carpetas dentro de data/sandbox (modo seguro).
Info básica del sistema (restringida).
Descriptions are critically short (15 - 48 chars vs 194-char baseline). 'Info básica del sistema (restringida)' for system_info lacks actionable context: What does 'restringida' mean? When should an LLM choose this over alternatives? Does it return CPU, memory, disk? Description must state WHAT, WHEN, and output structure.
Output schemas are not documented. The code returns dicts with 'ok', 'error', 'dir', 'items' (list_files), 'hits' (grep_text), but LLMs have no formal schema to expect the structure. This forces LLMs to parse unstructured responses and guess at field names.
Parameter descriptions are missing or too terse. 'rel_dir' has 'Relative directory path within sandbox' (good), but 'max_items' has 'Maximum number of items to return' without explaining the practical range (hard-capped to 1000 in code but not mentioned in schema). 'needle' in grep_text lacks any guidance on regex vs literal, case-sensitivity, or expected format.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 11 | - | v1 |
system_info has no documented parameters and no input schema clarity. The code returns platform, disk usage, but the JSON schema shows empty properties and required=[]. An LLM cannot know what fields to expect or how to interpret the response.
Error messages are generic ('No existe o no es directorio'). They do not tell the LLM what to try next or suggest alternatives. E.g., if a directory doesn't exist, should the agent list the parent? Search for similar names? Current errors provide no recovery guidance.
No input validation constraints documented in schemas. max_items is hard-capped to 1000 in code; max_hits to 100. These caps should appear as maxItems in the JSON schema AND be explained in parameter descriptions ('Will be clamped to 100 to prevent resource exhaustion').
Tools accept only English parameter names but descriptions are in Spanish. This creates a disconnect: 'rel_dir', 'max_items', 'needle' are English; descriptions 'Lista archivos/carpetas', 'Busca needle' are Spanish. Consistency is mixed, which may confuse LLMs about expected language for parameters vs output.