As an enterprise architect specializing in TypeScript systems for publicly-traded organizations in the past 10+ years and having worked on several high-profile platforms, I would like to propose strategic improvements for the MCP TypeScript SDK.

Is your feature request related to a problem? Please describe.

Given TypeScript/Javascript's dominance in the server-side ecosystem and its rapid evolution, the MCP TypeScript SDK is positioned to become the most widely adopted implementation of the protocol, at least on the server-side. However, there are opportunities to align the codebase with modern TypeScript enterprise standards to better support the growing community of contributors and enterprise adopters.

Currently, the SDK would benefit from enhanced type safety, standardized development practices, unified API exports, and improved tooling infrastructure. For example, the current export structure requires importing from multiple locations (@modelcontextprotocol/sdk/server/mcp.js for McpServer, @modelcontextprotocol/sdk/shared/uriTemplate.js for resource templates, @modelcontextprotocol/sdk/types.js for types (and runtime schemas!), etc.) rather than providing a clean API surface through the main package entry point. This fragments the developer experience and increases testing complexity through multiple mock requirements, while inconsistent error handling patterns throughout the codebase make it harder to build reliable applications.

The current state creates unnecessary friction for contributors and maintainers alike, as inconsistent patterns, scattered export structures, and lack of tooling make development more time-consuming, error-prone and inconsistent in the repository.

Describe the solution you'd like

I'd like to propose implementing modern TypeScript development practices that will make the MCP SDK more accessible and maintainable:

Core Improvements:

1. Enhanced Type Safety

   • Leverage TypeScript's Superior Type System: Unlike Python, TypeScript offers compile-time type checking and advanced generic constraints that should be the primary mechanism for ensuring correctness. The current implementation under-utilizes these capabilities, instead relying on patterns more suited to dynamically-typed languages.
   • Eliminate Over-Optionality: Replace the current pattern of making many parameters optional and then performing runtime validation with proper TypeScript type constraints and required parameters where appropriate
   • Replace Runtime Assertions with Compile-Time Safety: Move away from runtime type checking and assertions in favor of TypeScript's compile-time guarantees through proper generics, union types, and type guards
   • Implement Comprehensive Generic Type Systems: Create type-safe alternatives that leverage TypeScript's advanced type features like conditional types, mapped types, and template literal types
   • Establish Type-Safe Configuration Patterns: Use discriminated unions and proper type constraints for different transport types and configurations rather than optional properties with runtime validation

2. Unified API Surface

   • Consolidate exports through a single main entry point (@modelcontextprotocol/sdk/server)
   • Implement barrel exports with clear, predictable import patterns
   • Maintain backward compatibility through re-exports while establishing the preferred import path
   • Simplify testing by reducing the number of import locations that need mocking

3. Extensive Development Tooling

   • Enhance ESLint with TypeScript-specific rules for code quality. The current ESLint are very basic and do not provide enough value or strictness.
   • Add Prettier for consistent code formatting across all contributions
   • Integrate code quality monitoring via static analysis and security scanning. Tools for both on the market which are well-known and used by the community are free for open-source projects.
   • Implement automated code quality gates in CI/CD

4. Robust Testing Infrastructure

   • Separate unit tests from integration tests for faster, more reliable testing. Currently, there are no proper unit tests - the existing tests span across multiple files, classes and functions, which would classify as integration tests.
   • Create reusable test utilities and factories - the current test structure is very basic (tests alongside the implementation code), there is no proper structure/organisation of tests for reusability and mocking helpers.
   • No code coverage metrics are available. The repository does not have any code coverage metrics, which does not allow for easier community contribution and maintainability.
   • Inconsistent testing patterns. Using Node's built-in testing framework, but relying on Jest for mocking and assertions. Sometimes importing @jest/globals, sometimes not and other inconsistent patterns.

5. Observability & Monitoring

   • Implement proper logging. console.log is used extensively, and there is no proper logging. Implement a logger interface to allow for consumer plugging in via popular libraries like Winston, Pino or Bunyan.
   • Tracing, Logging and Metrics can be observability abstractions via the OpenTelemetry standard without binding to a specific library or implementation, allowing the consumer to plug their existing libraries (compatible with OpenTelemetry)
   • Implement proper metrics and monitoring. No metrics are available, and there is no proper monitoring. Implement a metrics interface to allow for consumer plugging in via popular libraries like Prometheus, Datadog or New Relic.
   • Implement proper tracing. No tracing is available, and there is no proper tracing. Implement a tracing interface to allow for consumer plugging in via popular libraries.

6. Clear Focus

   • The MCP TypeScript SDK currently is attempting to be a "Swiss Army Knife" for MCP, including mocking OAuth servers on the server-side, etc. However, one would argue that this implementing express middlewares to simulate OAuth servers and especially having that code all in the same repository structure is not the best approach. Most enterprise-grade projects have a 3rd party OAuth server, and while the MCP SDK can expose a separate API for OAuth sitting in front of the MCP server itself, just for example purposes, it should be cleanly separated from the MCP server codebase.

Describe alternatives you've considered

1. Gradual Enhancement - Implement improvements incrementally over multiple releases to reduce disruption, starting with the most critical type safety and API surface issues
2. Community-Driven Approach - Establish contribution guidelines and let the community drive improvements organically, though this risks inconsistent implementation across different areas
3. External Tooling Focus - Address quality through enhanced linting, formatting, and CI/CD without fundamental architectural changes, but this wouldn't resolve the core type safety and testing structure issues
4. Targeted Improvements - Focus only on specific areas like API consolidation and basic tooling, leaving observability and architectural focus for later phases
5. Maintain Status Quo - Continue with the current "Swiss Army Knife" approach and gradual organic improvements, accepting the trade-offs in enterprise adoption and contributor experience
6. Repository Strategy - Split concerns like OAuth simulation and observability into separate folder structures or even packages

Additional context

This represents a strategic investment in the MCP ecosystem's growth. By establishing enterprise-grade standards now, we can:

• Accelerate enterprise adoption through familiar development patterns, unified APIs, and production-ready observability standards that enterprises expect
• Reduce contributor friction with clear, consistent codebase standards, proper testing infrastructure, and simplified import structures that make onboarding developers faster
• Enable faster feature development through improved maintainability, comprehensive testing coverage, and proper separation of concerns that prevents feature creep
• Build ecosystem trust through professional monitoring capabilities, standardized logging interfaces, and reliable error handling that enterprises can integrate with their existing infrastructure
• Establish production readiness through proper observability abstractions (OpenTelemetry), metrics interfaces, and tracing capabilities that allow seamless integration with enterprise monitoring stacks
• Create architectural clarity by focusing the SDK on its core MCP responsibilities while providing clean extension points for additional functionality

Given TypeScript's central role in modern server development and its likelihood to be the most widely used MCP implementation, these improvements will position the SDK as the reference implementation that enterprises and the open-source community can confidently build upon. The current architectural approach of including ancillary features like OAuth simulation directly in the SDK may hinder adoption by enterprises who need clean, focused, and extensible solutions and take away from the repository focus (as can be seen in the raised GitHub issues and a portion of them being related largely to the OAuth protocol lately).

The Model Context Protocol represents a significant advancement in AI application development, and this TypeScript SDK plays a crucial role in the protocol's adoption and success. By addressing these foundational concerns now, we can ensure the SDK scales effectively as the protocol gains broader adoption and prevent technical debt that could slow future innovation.

This should be treated as a strategic feature request that will significantly enhance the SDK's value proposition for enterprise adoption and community contribution, while establishing the architectural discipline needed for long-term ecosystem success.

I'm grateful to the maintainers for their excellent work on the MCP ecosystem and this innovative technology. I would welcome the opportunity to contribute to implementing these strategic improvements and am ready to take on any of these initiatives.