Loading ToolBench
MCP server exposing Nedster's code tools for file operations, bash execution, and project search
Nedster exposes 33 tools with significant quality gaps. Most tools have basic descriptions (10-50 chars), but many lack depth on WHEN to use them or what they return. Input schemas are present but inconsistent: some parameters lack descriptions (e.g., 'glob' in list_files has no description). Tool naming is reasonable (verb_noun pattern mostly followed), but composition is poor, multiple tools do similar things (read_file appears 3 times, git_diff twice, run_tests twice, write_file twice). No output schemas documented. Error handling is minimal, tools return raw subprocess output or generic errors. No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Security concerns: run_bash and run_command accept arbitrary shell input with minimal validation. Descriptions do not explain prerequisites, dependencies, or recovery paths. Baseline: 194 chars avg description; Nedster averages ~40 chars. 0% of tools have documented return types.
Check if a model is available locally (Ollama or HuggingFace cache).
Check if sufficient VRAM is available before loading a model.
Performs an exact string replacement in a file. VERIFIED ON DISK.
List all available models from Ollama and HuggingFace cache.
Get free VRAM in MB from nvidia-smi.
Stage specific files for commit.
Get the current git branch name.
Duplicate tool definitions: read_file, write_file, git_diff, run_tests appear 2-3 times with identical or near-identical signatures. LLMs cannot disambiguate and waste reasoning cycles. Consolidate into single canonical definitions.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields. Every tool must declare what it returns (e.g., 'Returns: {success: bool, output: string, error?: string}').
Descriptions are too short (avg 40 chars vs baseline 194). Most lack WHEN to use, prerequisites, or recovery guidance. E.g., 'Executes a bash command' does not explain timeout behavior, network access implications, or error recovery.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | 2026-07-28+ | v2 |
Stage all changes and commit with optional message or auto-generated conventional commit.
Run git diff HEAD [file] limited to 100 lines.
Read the current git diff.
Get the last n commits as oneline log.
Stash current changes.
Run git status --short and git log --oneline -5.
Find files matching a glob pattern.
Search for a regex pattern in files.
List project files matching a glob.
Get current market price for a trading pair.
Rank relevant project passages for a natural-language query.
Read a UTF-8 project file.
Reads the entire content of a file.
Replace text in a project file.
Executes a bash command and returns the output.
Execute a shell command in the project.
Check for and run available formatters (black, ruff format, prettier).
Check for and run available linters (ruff, flake8, eslint, mypy).
Run detected test suite and capture output with failure parsing.
Run the project test suite.
A placeholder for a high-level scaffolding tool.
Search project text with a regular expression.
Fetch and parse content from a public HTTPS URL.
Search the web using DuckDuckGo.
Write content to a project file.
Write content to a file with optional encoding.
run_bash and run_command accept arbitrary shell input with no validation or sandboxing. No mention of injection risks, allowed commands, or restrictions. Agents can be tricked into executing malicious payloads.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot distinguish safe reads from irreversible writes. Tools like delete, edit_file, git_commit should be marked destructive.