Loading ToolBench
Codex/ChatGPT plugin app and OAuth-enabled MCP connector for approved local workspaces. Provides local file access, shell execution, project management, and Codex task runner integration for ChatGPT desktop and hosted connectors.
ChatGPT2LocalBridge presents a complex, feature-rich toolkit with 27 tools covering file operations, workspace management, git integration, task execution, and auditing. The server demonstrates good foundational quality: all tools have descriptions (10-200 chars, mostly well-written), input schemas with types, and parameter descriptions. However, it suffers from inconsistent depth across the tool catalog. High-risk tools (run_shell_command, delete_file, run_npm_script) lack security annotations and error handling guidance. Resource management tools (list_resources, read_resource) have minimal descriptions. Many tools lack output schema documentation, making it unclear what downstream operations can chain from their results. Error classification and recovery guidance are absent, tools return errors but don't tell the agent whether to retry, ask the user, or escalate. The server spans multiple responsibility domains (file ops, git, tasks, audit) which strains coherence; some tools feel under-specified relative to their destructive potential.
Create a task handoff package with constraints and skill context
Create a new Codex runner task
Create a new workspace
Delete a file or directory
Detect package manager scripts (npm, yarn, etc.) in a project
Detect test commands and framework in a project
Get bridge service status and configuration
Get list of changed files with insertion/deletion counts
Critical: run_shell_command lacks error classification and recovery guidance. Description does not clarify error conditions (command not found, timeout, non-zero exit) or advise agent on retry eligibility. Per pattern:error-classification, errors must categorize as retryable vs. fatal.
Critical: delete_file and run_shell_command do not include confirmation or dry-run capability. Per pattern:confirmation-request, irreversible operations must support confirmation to prevent agent accidents. No mention of dry-run mode in schema.
High: Tool output schemas are undocumented. The source code defines input schemas clearly but does not document the structure of responses (e.g., list_files returns what fields? get_diff returns how many lines?). This breaks tool chaining because the agent cannot know what IDs or fields to extract for downstream calls.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | <=2025-11-25 | v2 |
Get unified diff between working tree and HEAD
Get detailed file statistics including size, permissions, and SHA256 hash
Get Git repository status and changed files
Get bridge health check status
Get current request context (session, client info, request ID, etc.)
Get task details by ID
List audit events from bridge activity log
List files in a directory with metadata (size, modification time, type)
List available MCP resources (workspaces, projects, snapshots)
List recent tool call activity with filtering and pagination
List all configured workspaces
Read file contents with automatic truncation if file exceeds size limits
Read an MCP resource by URI
Run an npm script with output streaming
Execute a shell command with policy-based restrictions
Search for files by name or glob pattern
Set logging level for the bridge
Create a snapshot of project structure and metadata
Write or overwrite a file with contents
High: list_resources and read_resource have minimal descriptions ('List available MCP resources', 'Read an MCP resource by URI'). These do not explain what resources are, what URI format is expected, or when to call them vs. list_workspaces. Per pattern:tool-description, descriptions must WHAT, WHEN, and WHAT it returns.
High: create_handoff and create_task do not document expected behavior if the workspace or project path does not exist. Do these auto-create? Fail? The agent cannot plan the next step without knowing error conditions and recovery paths.
Medium: No tool provides pagination hints. list_tool_calls and list_audit_events include limit and offset, but descriptions don't clarify: are results ordered by date? Is there a total count? Can offset exceed result size? Agents cannot implement correct pagination without this clarity.
Medium: delete_file, run_shell_command, and run_npm_script are destructive but lack toolAnnotations (readOnlyHint, destructiveHint). Per current spec, these must be marked to help clients (Claude, etc.) restrict execution or add confirmation.
Medium: 'projectPath' appears in almost every tool but descriptions never explain: is this required to exist first? Can it be a relative path? Absolute? What happens if it's invalid? Undocumented parameter relationships force agents to guess and fail.
Medium: Error handling is generic. No tools document specific error messages, recovery steps, or when to ask the user vs. retry. Per pattern:recovery-guide, error responses must guide the agent: 'File not found, try search_files() first' vs. bare 'Error'.
Low: Namespace sprawl. 27 tools span file ops, git, workspace mgmt, task scheduling, auditing, and health checks. No grouping or hierarchy. An agent deciding between get_health, get_bridge_status, and get_request_context wastes reasoning. Consider top-level categories or consolidating read-only status tools.