Loading ToolBench
An MCP server implementation in C# (.NET) providing file editing tools and local Ollama integration for Claude
Claude Sidekick has 9 tools with visible schemas and descriptions. File tools (read_file, write_file, patch_file, list_files, move_file, search_files) have clear verb-noun naming and reasonable parameter documentation. However, descriptions are inconsistently detailed. Ollama tools (ollama_chat, ollama_code_generation, ollama_embed_text) have good descriptions with caveats about when to use them, but lack output schema documentation. No tool annotations (readOnlyHint, destructiveHint) are present despite clear risk classifications. Parameter descriptions are present but minimal. Error handling guidance is missing from all tools. Overall, this is a functional but not optimized toolkit.
List files and directories in a specified path.
Move or rename a file or directory.
Have a conversation with local Ollama for SIMPLE Q&A, factual questions, or basic explanations that don't require deep reasoning. Prefer for routine queries to save Claude tokens. AVOID for complex analysis, nuanced discussions, or tasks requiring sophisticated reasoning.
Generate SIMPLE code like getters/setters, basic CRUD operations, validation rules, boilerplate code, or routine functions. Use for mechanical coding tasks that follow established patterns. AVOID for architectural decisions, complex business logic, or code requiring sophisticated design patterns.
Generate text embeddings using local embedding models like nomic-embed-text. Ideal for batch embedding tasks, semantic search, similarity comparisons, and clustering. Use this for routine embedding generation to save Claude tokens.
Apply changes to a file by replacing multiple occurrences of text.
Output schemas not documented. Tools return MCPContent[] but structure is not described in tool definitions. LLMs cannot infer what fields to expect in responses, forcing them to guess about downstream data extraction.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Risk field exists in metadata but is not exposed to LLM via MCP annotations. write_file, patch_file, and move_file modify state but lack destructiveHint annotation. This prevents agents from understanding operation safety.
Error handling lacks recovery guidance. Handlers throw exceptions but no guidance on what the LLM should do next. No actionable error messages (e.g., 'File not found. Check path with list_files()' or 'Invalid search pattern. Use regex syntax.')
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | <=2025-11-25 | v2 |
Read the contents of a file from the file system.
Search for a pattern in files within a directory.
Write content to a file. Warning: This will overwrite the file if it already exists.
Parameter descriptions minimal for file paths. 'The path to the file to read' and 'The path to list' lack format guidance. Should clarify: absolute vs relative, Unix vs Windows paths, whether symlinks are followed, max length, forbidden characters.
Ollama tool descriptions omit output format. ollama_chat description says 'Have a conversation' but does not document whether response is a single string, structured JSON, token count, or multi-turn history. Same for ollama_code_generation (does it return code only or explanation+code?) and ollama_embed_text (vector dimensions, format?).
patch_file schema is complex (nested array of objects) but lacks examples or clarification. The 'patches' array description states 'An array of patches to apply' but does not explain order of evaluation, overlap handling, or rollback behavior if one patch fails.
No confirmation/dry-run pattern for destructive operations. write_file, patch_file, and move_file can destroy data, but there is no option for agents to preview changes before committing. Recommending 'This will overwrite' is not sufficient, agents should be able to test safely.
list_files pagination not addressed. No 'limit' or 'offset' parameter visible in schema. If a directory has thousands of files, the tool will return all, blowing context window. Rubric baseline: tools returning lists should support limit and pagination.
search_files lacks result limit documentation. Pattern parameter is free-form regex with no example or format guidance. No mention of how many matches are returned, whether results are capped, or if partial results are possible.