Loading ToolBench
Context Engineering Tool for AI Coding Agents - provides MCP server capabilities for building context prompts from workspace files with token budgeting, git integration, and file system scanning
RepoPrompt exposes 6 read-only tools with basic schemas and descriptions. All tools have names starting with action verbs (build_, list_, read_, count_, get_) and descriptions 30-80 chars. However, parameter descriptions are sparse or missing entirely. Most parameters lack type constraints (enums, ranges, patterns). Output schemas are not documented. Error handling guidance is absent. The server is a Tauri desktop app with TCP transport to MCP, not a standalone MCP server, tool definitions are embedded in Rust code (src-tauri/src/engine/mcp/mod.rs) but not visible in the provided source excerpt. This limits verification to the declared tool metadata.
Build a context prompt from workspace files. Specify root directories and optional file filters.
Count tokens in a text string.
Get git diff for a repository.
Get information about a git repository.
List files in a directory, respecting ignore rules.
Read the contents of a specific file.
Parameter descriptions missing or incomplete. 'path', 'roots', 'selected_files', 'token_budget', 'include_git_diff', 'user_instructions' lack actionable guidance on format, constraints, or valid ranges. LLMs cannot infer whether 'path' is absolute/relative, whether 'token_budget' has min/max bounds, or what 'user_instructions' format is expected.
No output schemas documented. Callers cannot know what fields build_context, list_files, read_file, or get_repo_info return. This forces LLMs to guess at response structure and breaks tool chaining (e.g., if list_files returns 'files' vs 'entries' vs 'items', downstream tools cannot reliably extract the list).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | <=2025-11-25 | v2 |
No enum constraints on boolean/categorical parameters. 'include_hidden' and 'include_git_diff' are booleans (good), but 'path' and 'roots' accept free-form strings with no validation hints. No guidance on path format (absolute vs relative, Windows vs POSIX), encoding, or max length.
No error handling guidance. If read_file fails (file not found, permission denied, encoding error), no recovery hints are provided. LLMs cannot distinguish retryable errors from user-fixable ones.
Tool definitions inferred from metadata, not directly visible in source code. The Rust implementation in src-tauri/src/engine/mcp/mod.rs is not provided, limiting verification to declared schemas.