Loading ToolBench
Interactive AI-powered MCP server that provides guided, agentic workflows for designing, reviewing, and implementing comprehensive test suites using the Foundry toolchain. Includes AST-based semantic analysis, AI failure detection, and context-aware testing workflows.
This server has critically incomplete tool definitions. Only 1 tool is registered (get_server_info), which has an extremely detailed description but NO input schema visible in the source code. The codebase references TestingTools class with methods like test_contract, run_tests, generate_tests, etc., but these are NOT registered as MCP tools, they exist only as Python methods. Tool registration is either inferred or completely missing from the provided source. The server conflates internal Python methods with MCP tool definitions, creating a fundamental gap between implementation and protocol compliance.
ℹ️ Enhanced server information and capabilities guide WHEN TO USE: - First time using this MCP server - User asks about available tools or capabilities - Need to understand tool workflow and relationships - Checking server status and enhanced features - Getting quick start instructions WHAT IT DOES: - Provides complete overview of enhanced MCP tools - Explains AST-based semantic analysis capabilities - Shows AI failure detection features - Lists all available resources and templates - Provides workflow guidance and troubleshooting OUTPUTS: - Enhanced tool catalog with AST capabilities - Recommended workflow sequences - Server status and feature information - Quick start guide for different scenarios
CRITICAL: No input schema visible for get_server_info. The tool definition shows Input: {} with no JSON Schema type definitions.
CRITICAL: Tool registration is either missing or not visible in the provided source code. TestingTools class contains methods (test_contract, run_tests, generate_tests, analyze_project) but they are NOT registered as MCP tools via fastmcp decorators. The server appears to define Python methods that are never exposed as callable MCP tools.
Per scoring rules, inferred tool existence caps that tool's score at 50. None of the TestingTools methods show explicit fastmcp @mcp.tool() registration.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 30 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Missing parameter descriptions for get_server_info. While Input is {}, if this tool were to accept any parameters (e.g., include_workflows, include_templates), they must have descriptions. Current {} suggests no parameters, which is acceptable, but the schema lacks type information.
No documented output schema for get_server_info. The description lists outputs (Enhanced tool catalog, workflow sequences, server status, quick start guide) but the actual JSON structure returned is not formally documented. LLMs cannot parse unstructured output reliably.
STDIO-only transport. The server uses STDIO exclusively, which is not remotely accessible and cannot integrate with hosted MCP clients. This is a hard cap on protocol readiness (50/100 max).
No error handling guidance. get_server_info is marked READ_ONLY, but there's no documented error response structure. What happens if the server encounters a fatal error? How should the LLM recover?
Testing workflow tools (test_contract, run_tests, generate_tests) lack schema visibility. If these are real tools, they require input parameters (contract file path, test framework, test type), but no schemas are shown in the source code.