Critical failure: The server advertises a single tool named 'dynamic' with no visible schema, no input parameters documented, and no concrete tool definitions in the codebase. Tools are fetched at runtime from the M00N Report API via apiClient.fetchTools(), making the tool definitions opaque to static analysis. The description states 'Tools are fetched dynamically from the M00N Report API at runtime via apiClient.fetchTools()' which is a technical implementation note, not a user-facing tool description explaining what the tool does, when to use it, or what it returns. No input schema is visible in the provided source code. The server lacks any evidence of parameter descriptions, type information, or return value documentation. This violates fundamental MCP tool definition practices: tools must have statically-declared schemas so clients and LLMs can understand how to invoke them before runtime.

• Declare all M00N Report tools statically in the MCP server with full input schemas (name, description, inputSchema with type, required, and properties). Generate this as a snapshot from the API during build/deploy and commit it to the repository so clients can discover tools before runtime.
• Replace the generic 'dynamic' tool name with specific action verbs reflecting actual M00N Report operations. Examples: 'create_test_case', 'list_test_cases', 'search_test_runs', 'update_test_status', 'plan_execution', 'cut_release', 'get_project_health'.
• For each tool, write a description (50 - 200 chars) that answers: What does it do? When should an agent call it? What does it return? Example: 'create_test_case: Author a new test case in M00N Report. Accepts title, description, and acceptance criteria. Returns the created case ID and URL for linking.'
• Document the input schema for each tool with JSON Schema. Every parameter must have a type (string, number, boolean, object, array), description, and constraints (enum, min/max, pattern). Example: { 'title': { 'type': 'string', 'description': 'Test case title (1 - 256 chars)', 'minLength': 1, 'maxLength': 256 }, 'priority': { 'enum': ['low', 'medium', 'high', 'critical'] } }.
• Document the output/return schema. Example: { 'type': 'object', 'properties': { 'case_id': { 'type': 'string', 'description': 'Unique test case ID' }, 'url': { 'type': 'string', 'description': 'Web URL to the test case' } } }.
• Generate a snapshot of API tool definitions at build time (as done for preview-snapshot.json) and check it into the repository. Update the server to load tools from this snapshot first, falling back to the API only for configuration or permission validation.