Loading ToolBench
A collection of skill plugins and hooks for Claude code interactions, including design comparison, SDLC verification, Xcode build notifications, and project validation utilities
This server exhibits critical definitional gaps across all four tools. While tool names follow action-verb conventions (export-, guard-, check-, xcodebuild-notify), descriptions lack the depth needed for reliable LLM selection, parameter schemas are incomplete or missing type information, and output schemas are entirely undocumented. The server appears to be a collection of skill hooks rather than a cohesive MCP tool suite. Names are reasonably clear (export-figma-node, guard-tests), but the lack of comprehensive schema definitions, missing output documentation, and shallow parameter descriptions place this firmly in the F-D range. No tool includes a documented return type or example output structure.
Validate an Xcode JSON project (project.xcproj). Runs xcprojformatter for malformed JSON validation, compares keys before/after formatting to detect typos or dropped values, and optionally runs xcodebuild -list to verify Xcode can load the project
Export a Figma node as a PNG image using the Figma REST API
Blocks edits to test files while sdlc/.lock-tests exists. Enforces a bug-fix loop where failing tests are the specification and must not be changed
Sends macOS notifications for xcodebuild command results, displaying build success or failure status
No output schemas documented for any tool. LLMs cannot plan downstream operations or extract critical data when return types are unknown.
export-figma-node description (106 chars) lacks information about prerequisites (FIGMA_ACCESS_TOKEN env var must be set), failure modes, or what fields are returned. Describes WHAT but not WHEN to call or failure recovery.
guard-tests has vague description (197 chars) that assumes LLM understands the 'bug-fix loop' pattern without explaining the guard mechanism, test file detection criteria, or what happens on success vs failure.
xcodebuild-notify description (126 chars) is severely underspecified. Does not explain: what happens when command is non-xcodebuild, how notification is delivered, whether this is a hook vs tool, or what data is required.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 40 | 2026-07-28+ | v2 |
xcodebuild-notify input schema is problematic: 'tool_input' and 'tool_response' are typed as generic 'object' with only descriptions, no property schemas. LLM cannot determine what fields to pass.
guard-tests input parameter 'tool_input' is a generic object with no nested schema definition. LLM must guess whether to pass {file_path: '...'} or {notebook_path: '...'} or both.
No error handling guidance in any tool description. Tools that fail (invalid Figma token, malformed project.xcodeproj, xcodebuild error) offer no recovery hints to the LLM.
export-figma-node description does not document what the tool returns (PNG file path, URL, bytes, success message?). Without return type info, LLM cannot chain this tool to other operations.
check tool description mentions 'xcprojformatter' and 'xcodebuild -list' as side effects but does not document what success looks like or what fields are returned (key comparison results, validation status, errors found).
All parameter descriptions are minimal. E.g., 'Figma file key (alphanumeric, hyphens, underscores only)' is adequate but lacks context about where to find it or examples of valid keys.