Proposal: Schema Generation Separation from Core SDK

Hey team!

The core protocol implementation is solid and provides exactly what developers need for building MCP servers.

Architectural Question I've Been Thinking About

I've been working with the SDK on some complex projects, and it got me thinking about the overall architecture. Currently, schema generation is built into the core SDK through the Discovery capability, but I'm wondering if we might want to consider a more modular approach.

Current State

Right now, the SDK handles both:

• ✅ Core MCP Protocol - JSON-RPC transport, message handling, server lifecycle
• ✅ Schema Generation - Converting PHP types to JSON Schema for tool discovery

This works great for getting started, but I'm noticing it creates some coupling between the protocol layer and schema generation logic.

What I'm Proposing

What if we moved toward a philosophy where the SDK focuses purely on being an excellent MCP protocol implementation, and schema generation becomes a separate concern handled by dedicated packages?

Core SDK Responsibilities

// Pure protocol focus
$server = new McpServer($transport);
$server->addTool('my_tool', $callable, $schema); // Schema provided externally
$server->run();

Schema Generation as Separate Packages

// Developer chooses their preferred schema generator
use McpSchemaGenerators\Spiral\SchemaGenerator;
use McpSchemaGenerators\JsonMapper\SchemaGenerator; 
use McpSchemaGenerators\Custom\MySchemaGenerator;

$generator = new SpiralSchemaGenerator();
$schema = $generator->generateFromCallable($myToolMethod);
$server->addTool('my_tool', $myToolMethod, $schema);

Benefits I See

🎯 Single Responsibility: Core SDK just handles MCP protocol brilliantly
🔧 Flexibility: Developers pick schema generators that fit their needs
📦 Smaller Core: SDK stays lightweight and focused
🚀 Innovation: Schema generation can evolve independently
🧪 Experimentation: Easy to try different approaches without SDK changes

Questions for Discussion

1. Does this architectural direction make sense for the project's goals?
2. Would this approach make the SDK more or less approachable for newcomers?
3. Are there any protocol-level reasons why schema generation needs to be tightly coupled?
4. Should we consider this for a future major version, or could it work as an evolution?

I think this could make the SDK both more powerful for complex use cases and simpler for developers who just want the protocol handling. The current implementation could become the "batteries included" reference implementation in a separate package.

What are your thoughts on this direction? I'd be happy to explore a proof of concept if it seems like something worth investigating.

Context

I've been building task management and workflow tools where I need rich schema generation for complex nested objects, but I also want the flexibility to integrate with existing validation systems in my applications. Having the choice of schema generators would solve both problems cleanly.

Es werden keine Dateien oder Tests genannt. Beginne damit, die im Proposal beschriebene Discovery-Fähigkeit und die Verwendung von McpServer::addTool zu prüfen, und bestimme anschließend, ob die Schema-Generierung getrennt werden kann, ohne das Protokollverhalten zu ändern; als abgeschlossen gilt die Aufgabe erst, wenn eine abgestimmte Architektur und ein Implementierungsplan vorliegen.