Loading ToolBench
Configuration manager for AI coding tools - Claude Code, Gemini CLI, Codex CLI, Antigravity. Manage MCPs, rules, permissions, memory, and workstreams.
This MCP server exposes 2 tools for syncing configuration rules between AI coding tools (Claude, Gemini, Antigravity). Both tools have basic descriptions and input schemas with type definitions, but critical gaps in parameter descriptions, output documentation, and error handling significantly reduce quality. The tools lack the specificity and LLM-guidance expected of production-grade MCP servers. Parameter descriptions are minimal (1-2 words), output schemas are not documented, and error messages are unstructured. This server would require substantial refinement before recommendation to a production team.
Get preview of files that would be synced between tools
Sync rules between tools
Parameter descriptions are critically sparse. 'projectDir' is described as 'Project directory path' (3 words), 'source' as 'Source tool (claude, gemini, antigravity)', these do not explain format, constraints, or when to use which tool. Per the rubric, descriptions must state WHAT the parameter controls and its constraints. LLMs cannot infer whether projectDir accepts relative paths, symlinks, or absolute only.
Output schemas are not documented. The code shows getSyncPreview returns an object with 'source', 'target', 'files', 'sourceExists', 'targetExists', and conditional 'error' field, but no schema is provided in the tool definition. syncRules returns 'success', 'synced', 'skipped', 'errors', again, undocumented. LLMs need explicit return type documentation to plan downstream operations and extract the correct fields.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Tool descriptions lack clarity on WHEN to use each tool and what happens. getSyncPreview says 'Get preview of files that would be synced' (7 words), does it show diffs? File counts? Sizes? syncRules says 'Sync rules between tools' (5 words), does it overwrite? Merge? Backup the target first? These are critical questions an LLM must answer before making destructive choices.
syncRules is a destructive tool (writes files) but lacks confirmation or dry-run support. Agents make mistakes, if an LLM accidentally passes the wrong source/target, it will silently overwrite rules in the target folder with no recovery option. No idempotency or undo mechanism documented.
Error messages in the code are unstructured strings (e.g., 'Source rules folder not found: <path>'). The MCP schema does not define an error field or error classification. When syncRules fails, does the LLM know if it's retryable, user-fixable, or fatal? Per the rubric, error responses must tell the LLM what to do next, not just report the problem.
Parameter 'files' in syncRules is documented as 'Specific files to sync (optional)' but lacks type definition in the visible schema. The code shows it expects an array of filenames, but the schema shows type 'array' with no itemType or items constraint. An LLM cannot validate what goes inside the array.
Enum values for 'source' and 'target' are documented in the description ('claude, gemini, antigravity') but not declared as formal enum constraints in the schema. LLMs rely on enum fields to pick valid options without hallucinating. Free-form strings invite the LLM to invent tool names like 'openai' or 'mistral'.
No audit logging or permission gating visible. The tools directly read/write files in projectDir without checking user authority. If an agent calls this server, there is no trace of who triggered the sync or what was changed, a compliance and incident-response risk.