Loading ToolBench
Free local-first MCP server for AI-agent context, RAG, CSV/JSON cleanup and QR generation, with PDF, OCR, DOCX and image processing on the roadmap. MIT by DJAI Academy and Siamese Cat Dev.
Server has 8 tools with complete input schemas and descriptions. Naming follows verb_noun convention (count_tokens, optimize_context, chunk_for_rag, package_prompt, csv_to_json, json_to_csv, clean_csv, generate). Descriptions are substantive (100-200 chars) and include WHEN to use guidance. However, output schemas are not documented, LLMs cannot predict return structure. Parameters lack some constraints (e.g., no min/max on file sizes despite --max-file-mb config). Error handling is minimal; no recovery guidance visible. Security is strong (file-based, no secrets in params), but composition could be tighter (e.g., optimize_context + chunk_for_rag are sequential but not chained in tool design).
Split local text into deterministic o200k_base token chunks and write JSONL for a RAG knowledge base. Use after extraction and cleanup. Do not use overlap equal to or larger than chunk_size.
Count tokens and text metrics locally. Use before budgeting prompt or RAG context. Accepts inline text or an allowed local UTF-8 file; it never modifies files.
Clean repeated headers, page labels, broken line wraps, and excess whitespace from local text. Use before prompting or chunking extracted document text. Do not use when exact formatting must be preserved.
Combine multiple allowed local UTF-8 files into one agent-ready Markdown or XML-delimited context file. Use to preserve source boundaries. Do not use for binary files or more than the configured batch limit.
Trim headers and values, remove empty rows, and remove exact duplicate rows from CSV locally. Use for basic cleanup; do not use when whitespace or duplicate rows are semantically meaningful.
Output schemas not documented. LLMs cannot predict return structure (e.g., what fields does count_tokens return? Is it a count or an object with metadata?). This forces agents to guess and wastes tokens on trial-and-error.
Data conversion tools (csv_to_json, json_to_csv, clean_csv) lack descriptions of output format and structure. Users need to know: does csv_to_json return an array or object? What happens to malformed CSV? Are empty cells null or empty strings?
No error handling guidance. If chunk_for_rag fails (e.g., overlap >= chunk_size), what does the LLM do? No recovery hints, no actionable error messages visible in code.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2025-06-18+ | v2 |
Convert a header-based CSV file into a formatted JSON array locally. Use for structured imports and APIs. The input is preserved and output is written only to an allowed directory.
Convert a JSON array of flat objects into CSV locally. Use for spreadsheet import. Do not use for top-level objects or deeply nested data without flattening it first.
Generate a deterministic QR code as a local SVG file. Use for text, URLs, Wi-Fi payloads, or identifiers. It does not fetch or validate remote URLs and never embeds a remote image.
Parameter constraints incomplete. encoding enum is well-defined, but chunk_size (100 - 8000) and overlap (0 - 4000) lack guidance on typical values. What overlap is 'good'? When should chunk_size be 500 vs 2000?
Tool composition: optimize_context and chunk_for_rag are sequential but not chained. No tool returns a reference the next tool accepts. Agents must manually thread file paths between calls.