Loading ToolBench
An MCP server that indexes and injects context-aware agentic rules scoped to repository structure and active files
This server has a single tool 'execute_skill_action' with critical deficiencies across all dimensions. The tool has a non-empty description (48 chars), but it is vague and lacks actionable context. The input schema is visible with two parameters, both typed as strings with descriptions. However, the schema lacks critical metadata: no output schema is documented, no enums/constraints are present, no error handling guidance is provided, and the tool name 'execute_skill_action' violates naming conventions (contains 'and', uses generic verb 'execute'). The server provides no evidence of pagination, batch operations, idempotent semantics, or recovery guidance. The input parameters lack validation rules, ranges, or format constraints. The client.py shows example output structure, but this is never registered or formally documented in the tool definition. Per HARD SCORING RULES: the tool lacks a documented output schema (schema cannot exceed 30 points); descriptions under 100 chars with no guidance on WHEN to use the tool or what happens receive low scores. This is a minimal proof-of-concept with no production-ready patterns implemented.
Executes agentic rule indexing and context injection for repository-scoped rules
Tool name 'execute_skill_action' uses generic verb 'execute' and contains 'and', violating single-responsibility principle. Should be split into 'index_rules' and 'inject_context' or use a specific action verb like 'scan_rules_and_inject' → 'apply_repository_rules'.
No output schema documented. The tool description does not specify what fields are returned. Based on client.py, responses include 'rule_index_id', 'matched_rule_definitions', 'context_token_overhead', 'architecture_compliance_enforced', 'rule_hierarchy_manifest_url', but these are inferred, not formally declared in the MCP server definition.
Input parameters lack validation rules, ranges, and format constraints. 'repo_structure_path' and 'current_active_file' are bare strings with no guidance on expected formats (absolute vs relative paths?), special characters, length limits, or what constitutes a valid path. Per pattern:constrained-input, enums and format constraints should be declared.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 24 | 2026-07-28+ | v2 |
No error handling guidance. The tool description does not specify what errors can occur (invalid path, no rules found, access denied) or how the LLM should recover. Per pattern:recovery-guide, error responses must tell the agent what to do next.
Tool description (48 chars) is too short and lacks critical context. It does not explain WHEN to use the tool, what prerequisites exist (must provide valid repo path?), what the output fields mean, or how the rule index integrates with the LLM context. Per pattern:tool-description, descriptions should be 10-1024 chars and answer WHAT, WHEN, and RETURN structure.
Parameter descriptions lack dependency hints and format guidance. 'Path to the repository root for rule scanning and indexing' does not clarify: is this an absolute path or relative to the workspace? What characters are forbidden? Can it be a symlink? What happens if the path does not exist?
Tool modifies state (injects rules into context, enforces compliance) but the description does not declare this. Per pattern:command-tool, tools that modify state must say so explicitly so agents know which calls are safe to retry.
No pagination or result limiting logic. If a repository has hundreds of matching rules, the matched_rule_definitions array could be unbounded, wasting context tokens. Per pattern:paginated-result, tools returning lists should support limit/offset and return total counts.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The server declares risk='READ_ONLY', but this is not formally encoded in MCP 2026-07-28 spec as tool annotations. The actual MCP server does not emit any such metadata.