Evaluate replacing `mcp-framework` with the official MCP TypeScript SDK

[esgn]

Context

This project currently relies on mcp-framework for:

• MCPServer bootstrap and transport wiring in src/index.ts
• MCPTool as the base abstraction for tools
• auto-discovery/loading of tools from the project structure
• HTTP transport conveniences such as CORS/session handling

In practice, our actual usage is fairly limited. We mostly depend on:

• server bootstrap
• tool abstraction
• stdio / http-stream transports
• tool auto-discovery

We are not heavily using the broader framework features such as apps, prompts/resources-specific abstractions, or the framework logger.

Problem

mcp-framework is a third-party framework layer on top of MCP. It provides convenience, but it is not the official SDK maintained by the modelcontextprotocol project.

This creates a few concerns:

• extra abstraction layer between our code and the MCP spec
• potential lock-in around framework-specific APIs (MCPTool, auto-discovery, build flow)
• duplicated or divergent behavior compared to the official SDK
• more complexity when reasoning about transport, logging, and protocol evolution

Proposal

Investigate replacing mcp-framework with the official MCP TypeScript SDK.

The likely target would be the official SDK/server stack from the modelcontextprotocol ecosystem, with explicit tool registration instead of framework auto-discovery.

Expected benefits

• closer alignment with the official MCP implementation
• lower dependency on framework-specific abstractions
• clearer ownership of server bootstrap and tool registration
• easier long-term maintenance as the MCP spec evolves
• less “magic” in startup/loading behavior

Expected trade-offs

• more boilerplate in index.ts
• loss of directory-based auto-discovery unless we rebuild a lightweight local mechanism
• migration effort across all tools currently extending MCPTool
• possible refactor of transport setup and HTTP server wiring

Investigation scope

• identify exactly which mcp-framework features we currently use
• compare them with official SDK equivalents
• estimate migration cost
• identify any missing features we would need to reimplement locally
• decide whether the migration should be full or incremental

Suggested implementation approach

1. Audit current mcp-framework usage in the codebase.
2. Build a small spike using the official SDK with one or two existing tools.
3. Compare:
   • transport setup
   • tool registration
   • structured error handling
   • HTTP stream support
   • CORS/origin validation behavior
4. Produce a migration plan if the spike is conclusive.

Acceptance criteria

• documented inventory of current mcp-framework usage
• proof of concept using the official SDK
• migration cost/risk assessment
• recommendation: keep mcp-framework, partially replace it, or fully migrate

[QuantGeekDev]

i vote against this lol :p