Loading ToolBench
OpenCode plugin for Fast Apply - High-performance code editing with OpenAI-compatible APIs (LM Studio, Ollama)
Single tool 'fast_apply_edit' has a detailed description (1200+ chars) but lacks a proper input schema in the source code. The tool is registered via @opencode-ai/plugin framework, but no explicit JSON Schema with type definitions is visible. Parameters (target_filepath, original_code, code_edit) are documented in the description text only, not in a machine-readable schema. This violates the critical rule: 'If a tool has NO input schema at all: its schema score MUST be 0.' The description is verbose and instructional but exceeds the 1024-char baseline and reads more like a prompt template than a tool definition. No output schema is documented. Error handling is absent, no guidance on what happens if the file is not found, if the API fails, or if the merge produces invalid code.
DEFAULT tool for editing existing files. Use INSTEAD of native 'edit' tool. For EXISTING files ONLY. Use 'write' for new files. Workflow: 1. Read the file to understand current content 2. Extract relevant section (50-500 lines with context) 3. Call fast_apply_edit with original_code (partial) and code_edit. Partial editing: You DON'T need to provide the entire file. Provide 50-500 lines of context around the area you want to change. Include 2-5 lines before and after the target section. Tool will automatically find and replace that section in the file.
No input schema visible in source code. Tool parameters (target_filepath, original_code, code_edit) are documented only in prose description, not as a JSON Schema with type definitions. This violates the critical rule and makes the tool unverifiable.
Tool description is 1200+ characters, exceeding the 1024-char baseline. It reads as a prompt template and agent instruction rather than a concise tool definition. LLMs waste tokens parsing verbose guidance that should be in system prompts, not tool descriptions.
No output schema documented. Callers do not know what the tool returns (success/failure, diff, error details). This breaks downstream tool chaining and forces LLMs to guess the response structure.
No error handling or recovery guidance. If the file does not exist, the API fails, or the merge produces invalid code, the tool provides no actionable error message. LLMs cannot self-correct.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 27 | 2026-07-28+ | v2 |
Tool name 'fast_apply_edit' is ambiguous. Does it edit a file, apply a patch, or merge code? A clearer name like 'apply_code_edit' or 'merge_code_section' would better signal intent. Current name conflates the API (Fast Apply) with the action.