Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Proposal: Schema Generation Separation from Core SDK

未关闭
  • 哪里不对？
#45 3 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
25/100
Issue 类型
重构
描述清晰度
需要澄清
活跃度
停滞
技术栈
php
领域
backend-api-design

调研方向

没有指定文件或测试。首先审查提案中描述的 Discovery 能力和 McpServer::addTool 的使用方式，然后确定是否可以在不改变协议行为的情况下分离 schema 生成；只有在达成一致的架构和实现计划后，才算完成。

由索引模型根据 Issue 内容生成。

描述

needs confirmation

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.

主要语言
PHP
星标
1.6k
派生
173
平均合并
19 小时 19 分钟
30 天内合并 PR
8

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

modelcontextprotocol/php-sdk 的其他 Issue

查看 modelcontextprotocol/php-sdk 的全部 Issue

相似的 Issue

更多 PHP Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。