Loading ToolBench
An MCP server implementation in C# providing tools for file operations, code patching, shell command execution, and LLM-assisted development workflows
Mogzi presents a mixed picture. Tool naming follows verb-first conventions (apply_, generate_, preview_, replace_, search_, list_, read_), which is good. However, descriptions vary significantly in quality and completeness. Some tools like 'apply_code_patch' and 'replace_in_file' have detailed, actionable descriptions (160-320 chars), while others like 'search_file_content' and 'list_directory' are more terse (80-130 chars). Most critically, NO input schemas are visible in the provided source code. The repository file references (src/Mogzi.Core/Tools/*.cs) indicate the tools exist, but actual JSON Schema definitions are not shown. Per the hard scoring rules, this means schema scores must be 0 across the board. Parameters ARE described in the narrative text (e.g., 'path' described as 'absolute path', 'patch' described as 'unified diff'), but without visible JSON Schema, LLMs cannot validate inputs programmatically. The tool descriptions themselves are generally strong and context-aware (explaining WHY to use diff tools vs string replacement), which partially compensates. However, the absence of formal schemas is a critical gap for production use.
Apply code changes using Git-style unified diff patches. More robust than string replacement for handling whitespace and formatting variations.
Generate a unified diff patch showing the changes between original and modified content.
Lists the names of files and subdirectories directly within a specified directory path. Can optionally ignore entries matching provided glob patterns.
Preview what changes a patch would make without actually applying them.
Reads an image file from the local filesystem and returns it as multimodal content for AI analysis. Supports PNG, JPG, JPEG, GIF, WEBP, SVG, and BMP formats. The image will be included in the conversation as visual content that can be analyzed by the AI model.
Replaces text within a file. By default, replaces a single occurrence, but can replace multiple occurrences when `expected_replacements` is specified. This tool requires providing significant context around the change to ensure precise targeting. Always use the read_file tool to examine the file's current content before attempting a text replacement. Expectation for required parameters: 1. `file_path` MUST be an absolute path; otherwise an error will be thrown. 2. `old_string` MUST be the exact literal text to replace (including all whitespace, indentation, newlines, and surrounding code etc.). 3. `new_string` MUST be the exact literal text to replace `old_string` with (also including all whitespace, indentation, newlines, and surrounding code etc.). Ensure the resulting code is correct and idiomatic. 4. NEVER escape `old_string` or `new_string`, that would break the exact literal text requirement. **Important:** If ANY of the above are not satisfied, the tool will fail. CRITICAL for `old_string`: Must uniquely identify the single instance to change. Include at least 3 lines of context BEFORE and AFTER the target text, matching whitespace and indentation precisely. If this string matches multiple locations, or does not match exactly, the tool will fail. **Multiple replacements:** Set `expected_replacements` to the number of occurrences you want to replace. The tool will replace ALL occurrences that match `old_string` exactly. Ensure the number of replacements matches your expectation.
No visible JSON Schema input definitions for any tool. All 7 tools lack formal parameter schemas in the provided source code. Per hard scoring rules, schema scores must be 0.
Parameter descriptions present in narrative text but not formalized in JSON Schema. While 'path' is described as 'absolute path' and 'patch' as 'unified diff patch', these descriptions lack formal type constraints (e.g., minLength, pattern, enum). LLMs cannot validate these constraints without JSON Schema.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Searches for a regular expression pattern within the content of files in a specified directory (or current working directory). Can filter files by a glob pattern. Returns the lines containing matches, along with their file paths and line numbers.
replace_in_file requires absolute paths and exact literal string matching. The description is very lengthy (~400 chars, above the 200-char ideal for description length) and reads like a detailed specification document rather than a tool description. This risks token waste and may confuse LLMs about when to prefer replace_in_file vs apply_code_patch vs generate_code_patch.
search_file_content uses regex patterns but does not document regex syntax constraints or performance implications. The 'include' parameter accepts glob patterns but lacks examples or validation guidance. Users may pass invalid glob syntax without feedback.
No documented output schemas for any tool. The rubric requires tools returning lists (search_file_content, list_directory) to document pagination parameters (limit, offset, next_cursor) and return structures. No such documentation is visible.
Error handling guidance is absent. Tools like replace_in_file (which can fail on whitespace mismatches) and apply_code_patch (which can fail on fuzzy matching) lack recovery guidance. What should an LLM do if 'old_string' does not match exactly?
list_directory 'ignore' parameter accepts 'List of glob patterns' but the input schema shows it as a string. Is this a single glob or a CSV list? Array type not confirmed. Parameter relationship between 'path' and 'respect_git_ignore' is under-documented.