Loading ToolBench
AI-native fork maintenance tool that exposes bingo-light CLI commands as MCP tools for managing customizations as a clean patch stack on top of upstream
bingo-light provides 14 well-named, domain-specific tools for fork maintenance with clear descriptions (avg 156 chars, within 10-1024 baseline). All tools have input schemas with required parameters and descriptions. However, output schemas are not documented in the source code, LLMs cannot predict return structures. Error handling is minimal; tools lack recovery guidance. Parameter descriptions are adequate but lack format constraints (e.g., patch name regex, cwd validation rules). No tool annotations (readOnlyHint, destructiveHint) despite clear risk classifications. Composition is strong: tools chain logically (status → init → patch_new → sync). Security: no secrets exposed as parameters.
Generate GitHub Actions workflow for automated daily upstream sync. Creates .github/workflows/bingo-light-sync.yml.
Analyze current rebase conflicts. Returns structured info about each conflicted file (ours/theirs, conflict count, hints, semantic_class: whitespace/import_reorder/signature_change/logic) plus: patch_intent (name, subject, full commit message, original_sha, original_diff, meta, stack_position), verify (test_command + per-file hints), and patch_dependencies (cascade risk).
Show combined diff of all patches vs upstream (total fork divergence).
Diagnose setup issues: checks git version, rerere, upstream remote, branch structure, and tests whether patches apply cleanly on latest upstream. Use report=true for extended checks.
Initialize bingo-light in a git repository. Sets up upstream tracking, creates patch branch, enables rerere. Run once per forked project.
Remove a patch from the stack.
Output schemas not documented. LLMs cannot predict return structures (e.g., what fields does bingo_status return? Is recommended_action always present?). This forces agents to guess and risks parsing failures.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications in metadata (READ_ONLY, WRITE, DESTRUCTIVE, REVERSIBLE). Agents cannot distinguish safe from dangerous operations without reading descriptions.
Parameter descriptions lack format constraints. 'name' in bingo_patch_new says 'alphanumeric, hyphens, underscores' but no regex pattern or length limits. 'cwd' accepts any string with no validation guidance. LLMs cannot self-validate inputs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Export all patches as numbered .patch files (git format-patch) plus quilt-compatible series file.
Import .patch file(s) into the stack.
List all patches in the stack with stats. Use verbose=true for per-file details.
Create a new patch from current changes. Each patch = one atomic customization on top of upstream. Stage changes first (git add) or let it auto-stage everything.
Show full diff and stats for a specific patch.
Check the health of your fork. Returns recommended_action telling you exactly what to do next: 'up_to_date', 'sync_safe', 'sync_risky', or 'resolve_conflict'. ALWAYS call this FIRST. Read the recommended_action field — don't guess.
Low-level sync: fetch upstream and rebase patches. Prefer bingo_smart_sync instead — it handles conflicts automatically. Only use bingo_sync when you need dry_run preview or fine-grained control over the rebase process.
Undo the last sync operation by restoring patches branch to previous state.
Error handling absent from tool definitions. No guidance on recovery (e.g., if bingo_sync fails with conflicts, should agent call bingo_conflict_analyze? bingo_undo?). Agents will stall on failures.
bingo_conflict_analyze returns 'semantic_class' enum (whitespace/import_reorder/signature_change/logic) but no guidance on which classes are auto-resolvable vs require human review. Agents cannot decide next steps.