Loading ToolBench
A local Model Context Protocol (MCP) connector that lets ChatGPT plan over an allowlisted local dev workspace and hand the approved plan to Codex.
PlanBridge demonstrates solid naming conventions (verb_noun pattern: projects_list, prepare_plan, execute_plan) and comprehensive descriptions (100-200 chars, well-structured). Tool annotations (readOnlyHint, destructiveHint) are present and correct. However, critical gaps exist: input schemas are not visible in the provided source code, parameter descriptions are absent from the schema definitions, and output schemas are undocumented. The tool-registry.ts excerpt shows tool registration but does not expose the actual Zod schema definitions (projectsListInputSchema, preparePlanInputSchema, etc.), making schema validation impossible. Error handling is mentioned in descriptions but implementation details are not visible. Security considerations (allowlisting, secret redaction) are documented in descriptions but not verifiable in code.
Advanced action: write an approved Codex handoff artifact and start the configured execution adapter. Prefer prepare_plan then execute_plan for normal use.
Advanced: return the persisted state for a codex-cli execution run. Prefer review_run for normal use.
Advanced: package selected files, prompt, and constraints into a reproducible planning bundle.
Execute a stored PlanBridge plan only after explicit user approval and an approved_plan_hash match. Refuses stale or already executed plans.
Advanced: return a bounded, redacted diff for one codex-cli run worktree. Prefer review_run for normal use.
Advanced: return the allowlisted project's branch and dirty-state summary.
Input schemas not visible in source code. Tool registration references schema objects (projectsListInputSchema, preparePlanInputSchema, etc.) but actual Zod definitions are not provided. Cannot verify parameter types, descriptions, constraints, or validation rules.
Output schemas undocumented. Tool descriptions do not specify what fields are returned, their types, or structure. LLMs cannot plan downstream tool calls or extract required data without knowing response format.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | 2025-06-18+ | v2 |
Use this first for implementation requests. It packages allowlisted context, optionally consults GPT-5.5 Pro when enabled, stores a hashed plan, and never executes Codex.
Advanced opt-in: package selected allowlisted files into a redacted context bundle, consult GPT-5.5 Pro through ChatGPT browser subscription mode, and return the answer.
Advanced: return repo type, key docs, test commands, and recent status for one allowlisted project.
List allowlisted projects and basic metadata. Use this before preparing a plan when the project name is unclear.
Advanced: read specific allowed files with size limits, gitignore checks, and secret filtering.
Advanced: search allowed files with bounded ripgrep-style results and secret-redacted previews.
Review a Codex run from a plan_id or runHandle. It combines codex_status with a bounded, redacted git_diff when the run is complete and never merges.
Parameter descriptions missing from visible schema definitions. While tool descriptions are good (85-100 chars), individual parameter meanings, constraints, and formats are not documented in the schema layer where LLMs and clients parse them.
Error handling implementation not visible. Descriptions mention 'refuses stale plans' and 'redacted previews' but actual error responses, recovery guidance, and categorization (retryable vs fatal) are not shown in provided code.
Pagination not documented. Tools like repo_search and projects_list likely return multiple results but no limit, offset, or cursor parameters are visible in descriptions. Large result sets risk context window exhaustion.