fix: improve basePath resolution for npx execution support

[m2de]

Problem

Fixes #101 - MCP servers created with mcp-framework fail when executed via npx with the error "Server does not support tools (required for tools/list)".

The issue occurs because the current MCPServer.resolveBasePath() method uses dirname(process.argv[1]) which points to different locations when running via:

• npm run start (works) ✅
• npx package-name (fails) ❌

Solution

Updated MCPServer.resolveBasePath() to use the same intelligent resolution strategy as BaseLoader:

1. Check project dist directory first: process.cwd() + '/dist'
2. Smart fallback: Use process.argv[1] with intelligent dist/ detection
3. Consistent behavior: Works with both development and distribution scenarios

Changes Made

• Added existsSync import from 'fs'
• Enhanced resolveBasePath() method with multi-stage resolution logic
• Added debug logging for path resolution tracing
• Maintains full backward compatibility with explicit basePath configs

Testing

✅ Verified fix works with both execution methods:

• npm run start - continues to work
• npx package-name - now works correctly
• Tools are properly discovered and loaded
• Server starts successfully with capabilities detected

Benefits

• 🔧 Fixes the root cause - No more manual basePath workarounds needed
• 🔄 Backward compatible - Existing projects continue to work unchanged
• 🎯 Consistent behavior - Same resolution logic as BaseLoader
• 🚀 Better DX - MCP servers work seamlessly with npx distribution

[Copilot]

Pull Request Overview

This PR fixes a critical issue where MCP servers fail when executed via npx due to incorrect basePath resolution. The fix implements a multi-stage resolution strategy that first checks for a project's dist directory, then falls back to intelligent module path detection.

• Replaces simple dirname(process.argv[1]) with robust multi-stage basePath resolution
• Adds intelligent detection of dist directories to handle both npm and npx execution contexts
• Implements consistent resolution logic matching the existing BaseLoader approach

[PaulRBerg]

hey @QuantGeekDev could you please take a look at this PR?