Loading ToolBench
DevContext: MCP Extension with Roocode and Cursor integration for development context management, tools advisory, and safety-enhanced interactions
DevContext MCP exhibits severe definition quality issues across nearly all dimensions. The server presents 13 tools with inconsistent naming patterns, incomplete parameter schemas, and vague descriptions that fail to guide LLM tool selection. Most critically: (1) Parameter schemas lack proper type definitions and descriptions, many show incomplete object types without field-level documentation; (2) Tool names use non-standard patterns (e.g., 'enhanceMessage', 'processCommand', 'markConceptExplained') rather than verb_noun convention; (3) Descriptions are generic and fail to answer WHEN and WHY to use each tool; (4) Output schemas are completely undocumented, no tool specifies what it returns or what fields the LLM should expect; (5) Error handling is invisible, no recovery guidance, error categorization, or validation rules visible in the code. The codebase shows skeleton implementations (MCPToolsAdvisor, ChangeOrchestrator, etc.) with mock tool catalogs but no working tool definitions. Transport is UNKNOWN, blocking remote access entirely.
Analyze the impact of a file change including affected files, risk level, and suggested checklist
Analyze project tooling needs based on project context, user skill level, recent issues, and current activity
Create a detailed change plan with dependency analysis, risk assessment, and checklists
Enhance message with development context metadata including user skill level, project context, and environment info
Evaluate code changes for impact assessment, risk identification, dependency analysis, and action planning
Get MCP tool recommendations based on current development activity, project context, and recent issues
Implement planned changes with safety validation, rollback capability, and verification
Output schemas completely undocumented across all 13 tools. No tool specifies its return type, structure, or fields. LLMs cannot plan downstream calls or extract required data for chaining.
Parameter schemas incomplete and improperly typed. Many parameters show 'type': 'object' with 'properties' but lack descriptions for nested fields. Example: 'metadata' in enhanceMessage and 'projectContext' in analyzeToolingNeeds have no field-level documentation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 23 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 25 | - | v1 |
Mark a concept as explained to the user for tracking explained concepts
Plan code changes with impact analysis, dependency tracking, and risk assessment
Validate and normalize a shell command with project context awareness, including safety checks for risky operations
Determine whether a concept should be explained based on user profile
Validate and normalize shell commands with project context awareness, checking for risky operations and providing normalization for platform differences
Validate command with safety checks and AI interaction validation before processing
Tool names violate verb_noun naming convention. Use camelCase without action verbs: 'enhanceMessage' (should be 'update_message_metadata' or 'add_context_to_message'), 'markConceptExplained' (should be 'mark_concept_explained'), 'shouldExplainConcept' (should be 'check_if_explain_concept'). LLMs struggle to infer intent from non-standard names.
Descriptions lack actionable context. Most are 25-45 characters and do not answer WHEN/WHY to use the tool. Example: 'Determine whether a concept should be explained based on user profile', does not say what 'explained' means, how to use output, or what user profile data is required.
No error handling visible. No recovery guidance, error categorization (retryable/user-fixable/fatal), or validation rules documented. Tools that modify state (markConceptExplained, implementChanges, validateAndProcessCommand) show WRITE/IRREVERSIBLE risk but provide no confirmation or dry-run mechanism.
Parameter descriptions missing or minimal across all tools. Example: 'command' in processCommand described as 'Shell command to validate and normalize', does not specify format, allowed commands, forbidden patterns, OS assumptions, or shell type (bash, zsh, PowerShell, etc.).
Destructive operations lack confirmation/dry-run pattern. 'implementChanges' (IRREVERSIBLE risk) and 'validateAndProcessCommand' (WRITE risk) provide no dry-run or multi-round-trip confirmation mechanism to prevent agent-initiated catastrophic errors.
No input validation rules visible. Parameters lack enum constraints, min/max bounds, regex patterns, or format specifications. Example: 'changeType' in analyzeChange has enum ['modify', 'add', 'delete'] but no description explaining which is valid when or side effects.
Composition issues. Multiple tools perform overlapping functions without clear differentiation: 'planChanges' vs 'createPlan', 'processCommand' vs 'validateAndProcessCommand' vs 'validateAndNormalize'. LLMs will waste reasoning cycles deciding which to call.