Loading ToolBench
MCP server for code management and project interaction, providing tools for file operations, code search, command execution, and session management
Codem MCP provides 12 well-structured tools with complete JSON schemas and descriptions. All tools have clear verb-noun naming (create_session, read_files, grep_codebase, write_file_small, etc.) and descriptions ranging 50 - 200 chars, which is within the 10 - 1024 baseline. Schemas are properly typed with required fields and parameter descriptions. However, output schemas are not documented, LLMs cannot predict what fields to expect from responses. Error handling is minimal; tools lack recovery guidance. Parameter descriptions are adequate but could be more prescriptive about constraints (e.g., regex patterns, timeout ranges). The write_file_* tools show good composition (small, large, full variants) but lack idempotency guarantees or confirmation patterns for destructive operations.
Create a new file with the specified content
Create a new Codem session for a project, as well as run a test command, grep the codebase, or list a directory. The session ID returned from this tool is needed for all other tools.
Search for a pattern across multiple files
Search for a pattern in a specific file
List contents of a directory with optional path regex filtering
Read the contents of one or more files. To reduce the number of times read_files is called, if you have to read many files at once, you should provide all of them to one read_files call, rather than making multiple read_files calls.
Output schemas not documented. LLMs cannot predict response structure, forcing them to guess what fields are returned and breaking tool chaining.
No error handling guidance. Tools lack recovery hints (e.g., 'File not found. Check path with list_directory()') or error categorization (retryable vs. fatal).
Destructive operations (write_file_*, create_new_file, run_command_risky) lack confirmation or dry-run patterns. Agents can accidentally overwrite or delete without safeguards.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | <=2025-11-25 | v2 |
Run a safe command in the project directory
Run a potentially unsafe command in the project directory
Run the test command configured for the project. You should always test after you finish making a change to the codebase.
Write complete new content to a file. This tool is expensive! Try to use write_file_small or write_file_large, and only use write_file_full if you need to fully rewrite the file or one of small/large fails.
Replace a large section of text between start and end markers. Useful for replacing blocks of text. The markers must be unique in the target range, cannot overlap/contain each other, and cannot appear multiple times in the range. More reliable than write_file_full for partial changes that are too large for write_file_small.
Replace a small piece of text in a file. The old_str argument must be unique within the line range provided, unless you set allow_multiple_matches to true.
Parameter descriptions lack prescriptive constraints. 'timeout' has no range (e.g., 1 - 3600 seconds); 'pattern' (regex) has no format guidance; 'context_lines' has no bounds.
Tool descriptions do not clarify when to use similar tools. E.g., grep_file vs grep_codebase distinction is clear, but write_file_small vs write_file_large vs write_file_full lacks guidance on when each is appropriate.