Loading ToolBench
Unified skill and MCP hub with layered project-scoped configuration
GearCore exposes 2 tools with minimal schema definitions and incomplete descriptions. Both tools have valid JSON schemas with required fields specified, but lack the depth and clarity expected of production-grade MCP servers. The tool names follow verb-noun convention (list_skills, request_skill), but descriptions are terse and fail to explain WHEN to use each tool, what prerequisites exist, or how they interact. Neither tool's input schema includes parameter descriptions, only type declarations. Output schemas are not documented. The server is STDIO-only, which hard-caps protocol readiness. Overall, this is a D-grade server suitable for prototyping but not production deployment.
List available GearCore skill bundles in the current context.
Unlock a skill bundle to inject its instructions and expose its tools.
Tool descriptions are below 20 characters, violating the 10 - 1024 character guideline. 'List available GearCore skill bundles in the current context.' (68 chars) and 'Unlock a skill bundle to inject its instructions and expose its tools.' (72 chars) are minimal, they lack actionable guidance on WHEN to call each tool, what prerequisites exist, error cases, or how they compose.
Input parameters lack descriptions. The 'name' parameter in request_skill has type 'string' with description 'Skill name to unlock.' (28 chars), which does not explain the valid format, constraints, enumeration, or how to discover valid skill names. The LLM cannot determine whether to pass a display name, internal ID, or partial match.
No output schema is documented for either tool. LLMs cannot plan downstream composition or extract structured data without knowing what list_skills returns (is it an array of skill objects? What fields does each contain?) or what request_skill returns (success/failure? Injected instructions as text? Tool list?).
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | 2026-07-28+ | v2 |
No error handling guidance. If request_skill fails (skill not found, name ambiguous, injection refused), the tool provides no recovery hint. LLMs cannot self-correct, they need error messages like 'Skill not found. Call list_skills() to see available skills.'
Tool composition is unclear. list_skills and request_skill interact (list → request), but the descriptions do not state this dependency. There is no guidance on the expected workflow or whether request_skill consumes the exact output of list_skills.
Ambiguous parameter naming. The 'name' parameter in request_skill does not clarify whether it accepts the display name, a unique ID, a partial substring match, or all three. Best practice would use 'skill_name' and document the matching strategy (exact, case-insensitive, fuzzy).