Loading ToolBench

Reading the current corpus…

codeforge MCP server · F · ToolBench

codeforge

An MCP server that provides code analysis, editing, and execution tools integrated with AI providers (Claude, OpenAI, Cursor) and version control systems (GitHub, GitLab)

2026-07-28+STREAMABLE_HTTP5 tools

39/100

Definition Quality31

Protocol Readiness42

Supportability50

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

Static source inference · medium confidence · evidence: Streamable HTTP

Current-spec patterns detected

Summary

Codeforge exposes 5 tools with MINIMAL structure. Tool definitions appear only in a React UI file (web/src/components/session/ToolBlocks.tsx), not in backend Go code. This is a critical red flag: tool schemas are inferred from UI hardcoding, not formally defined in the server. Descriptions are trivial (6 - 28 chars), parameter types are minimal/absent, and no error handling guidance is visible. The server is HTTP-based, but tool definition quality is well below production standards.

Tools (5)

bashwrite32/100

Execute bash/shell commands

editwritesource verified40/100

Edit document content

folder_openread only37/100

List directory contents

readread only43/100

Read file contents

searchread only45/100

Search for content in files

Issues (8)

CRITICALtool ↗

Tool definitions are not in backend code. Schemas and descriptions are hardcoded in React UI (ToolBlocks.tsx), not in the Go server. This means tool definitions are not formally registered via MCP, they are UI artifacts only. Cannot verify formal schema compliance or parameter validation.

editbashreadsearchfolder_open

CRITICALtool-description ↗

All descriptions are below 20 characters and generic. Examples: 'Edit document content' (20 chars), 'Execute bash/shell commands' (28 chars), 'Read file contents' (18 chars). Too short for LLM tool selection reasoning.

editbashreadsearchfolder_open

CRITICALconstrained-input ↗

Parameter schemas visible in UI show only 'type' and 'description' fields; no enum constraints, ranges, or regex patterns. The 'bash' tool accepts 'command' as a bare string with no validation constraints, LLM could pass malicious shell commands unchecked.

bash

Recommendations

Move tool definitions from React UI into the Go backend. Create a formal tool registry in internal/tools/ with full schemas, descriptions, input/output types, and error handling specs. Register tools via a proper MCP server handler.
Expand all descriptions to 100 - 200 characters. Example: 'read' → 'Read the complete contents of a file at the specified path. Returns the raw file content as a string. Use this to view code, configs, or text. Returns error with available paths if file not found.'
Add formal JSON Schema constraints: bash.command should reject shell metacharacters or require explicit escaping; edit.path should validate file extensions (no .sh, .conf without review); search.path should deny ../ traversals.
Implement safe-edit patterns: edit tool should return a preview/diff before committing. bash tool should support --dry-run and require explicit --execute flag. Both should log all invocations for audit.
Document output schemas for each tool. Example: read returns {content: string, size_bytes: int, encoding: string, last_modified: ISO8601}. search returns {matches: [{path, line_num, snippet}], total_count, limited: bool}.
Add error handling: Catch file-not-found, permission-denied, path-traversal, and shell syntax errors. Return structured error with error_code, human_message, and recovery_hint. Example: {error_code: 'FILE_NOT_FOUND', message: 'File /data/main.go does not exist.', hint: 'Available files in /data: main.go.bak, main_old.go'}.
Rename tools for clarity: 'bash' → 'execute_shell_command', 'folder_open' → 'list_directory_contents', 'edit' → 'edit_file_content'.

Score history

Overall score trend

First recorded score · v2 rubric

39/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	F	39	2026-07-28+	v2