Loading ToolBench
RTK-powered agent skills for Tech Leads. Provides MCP tools for accessing architecture skills, workflows, knowledge items, and operational guidance.
The Tech-Lead Stack MCP server exposes 13 tools with highly domain-specific functionality around skill management, knowledge items, and validation. However, the implementation shows significant gaps in LLM-critical areas: most parameter descriptions are generic or missing, output schemas are not documented, error handling lacks recovery guidance, and parameter naming is inconsistent with verb_noun conventions. Many tools conflate multiple responsibilities (e.g., get_skill merges reading, mode selection, budget tracking, and role/autonomy metadata into one call). While the skill management domain is clear, the tool definitions do not meet production-grade standards for agent usage. Tools 2-4 and 10-13 expose complex parameters with minimal documentation of valid values, ranges, or relationships. Only tools 1, 5, and 6 have concise, actionable descriptions; the rest exceed the 200-char guidance and bury key constraints in parameter names rather than formal schemas.
Sets the approval state of a Knowledge Item.
Validates the frontmatter against the SKILL_TEMPLATE.md structure. If no content argument is provided, it uses the current editor content.
Creates or updates a Knowledge Item from the current context.
CORE EXECUTION: Reads a specific skill (e.g. 'planning-expert').
Reads the content of one or more skill markdown files.
Fetches 2-3 random files from .ai/skills/ to use as reference for tone and formatting.
Runs prettier and markdownlint to automatically format the skill content and fix lint issues. If no content argument is provided, it uses the current editor content.
Output schemas not documented. Tools list_skills, get_skills, get_skill, list_knowledge_items, read_knowledge_item, and others do not declare what fields or data structures they return. LLMs cannot plan downstream tool calls or extract specific data without documented return types.
Parameter descriptions are missing or generic for high-complexity tools. Tools get_skills (11 params) and get_skill (11 params) lack descriptions for budget, loopRunId, teamRole, actorType, autonomy, loopPhase, story, slice parameters. Without descriptions, LLMs cannot determine when to pass these optional fields or what valid values are.
Parameter type mismatch for 'budget' in get_skills and get_skill: budget is declared as an object with properties (maxCostUsd: number, maxTotalTokens: number) but no description or nested parameter documentation. LLMs may pass invalid budget structures or omit required nested fields.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | 2026-07-28+ | v2 |
Lists all available Antigravity Knowledge Items.
MANDATORY START: Lists ALL available Tech-Lead Stack architecture skills and workflows.
Reads a specific Knowledge Item and its artifacts.
Proposes a full refinement of the SPECIFIC skill currently under analysis. Use this to inject Phase 0, Phase 1, and Verification Gates into the existing logic. NEVER use "new-skill" or generic placeholders if the current draft already has content.
Validates the skill content against the Tech-Lead Stack ethos (G-stack, MinimumCD) by running validation scripts. If no content argument is provided, it uses the current editor content.
MANDATORY PRE-FLIGHT: Validates that the agent is aligned with the operational boundaries and has initialized the required mission skills.
No enum constraints on 'mode', 'autonomy', 'loopPhase', or 'actorType' parameters despite hints in descriptions. Descriptions mention 'auto' | 'interview' and 'AGENT or USER', but JSON Schema does not enforce these as enums. LLMs will hallucinate invalid values.
Error handling lacks recovery guidance. No tools provide actionable error messages (e.g., 'skillName not found. Available skills: planning-expert, mission-architect, ...') or error classification (retryable vs. user-fixable). Agents cannot self-correct on failure.
Tool composition issues: get_skills and get_skill appear to be overlapping (get_skills reads 'one or more' skill files, get_skill reads a 'specific skill'). The distinction is unclear from descriptions, and both accept identical parameter sets. LLMs will struggle to pick the right one.
Parameter naming inconsistency: skillName uses camelCase; other tools use underscores (projectName, loopRunId mixed with snake_case in other contexts). This inconsistency forces LLMs to remember parameter casing per-tool.
Tools lint_and_format, validate_ethos, check_schema, and update_skill_template accept optional 'content' parameter that 'defaults to the current editor content if omitted.' This assumes stateful editor context, but MCP is stateless. If content is absent, behavior is undefined and unpredictable for non-editor clients.
No pagination or result limits documented. Tools list_skills, list_knowledge_items, and get_stylistic_examples do not specify max result count or pagination tokens. LLMs may receive thousands of items, exhausting context and diluting signal.
Destructive/stateful tool annotations missing. Tools create_knowledge_item, approve_knowledge_item, lint_and_format, and update_skill_template modify state but lack destructiveHint or idempotentHint in the tool definition. This prevents MCP clients from warning users or implementing safeguards.