Add server lifecycle events (ServerStarted / ServerStopped)
まだ誰も着手していません。
評価
調査の方向性
Server::run($transport) から始め、次に Protocol::handleRequest と Builder によって作成された transport のエントリーポイントを確認します。既存の Events と、それらの dispatching のテストがあれば確認します。ServerStartedEvent が最初のリクエストの前に一度だけ発火し、ServerStoppedEvent が正常終了時、例外発生時、transport のクローズ時に finally から発火し、指定されたコンテキストを保持することが完了条件です。
索引モデルが issue の本文から書いたものです。
説明
Problem
The SDK currently dispatches only request-scoped events (RequestEvent, ResponseEvent, ErrorEvent, list-changed events). There is no hook that fires once per Server::run() invocation.
Consumers that need one-time setup/teardown per server boot must either:
- Duplicate the logic in every transport's entry point (HTTP controller, CLI command, custom transports), or
- Subscribe to
RequestEvent+ matchingResponseEvent/ErrorEventand deal with per-request overhead, fiber suspension, and every error path.
Proposal
Add two events in Mcp\Event:
ServerStartedEvent— dispatched at the top ofServer::run($transport), before the first request is read. Exposes the server and transport.ServerStoppedEvent— dispatched just beforeServer::run()returns, in afinallyso it fires on clean exit, thrown exceptions, and transport close. Exposes the exit code and any captured throwable.
Use cases
- Identity / impersonation: switch the current user of a host framework (Drupal, Symfony Security) once when the server boots. This is our concrete motivation — without a lifecycle hook we either patch every transport or pay the cost of switching on every
RequestEvent. - Metrics / observability: increment
mcp_server_started_total, start a run-duration timer, emit a "server up" log line including registered tool/prompt/resource counts. - Resource management: warm caches, acquire leases, open long-lived connections at start; release them at stop.
Alternatives considered
- Use
RequestEventas a pseudo-start hook — works but is per-request. Adds overhead to what is logically a one-shot, and requires pairing withResponseEvent/ErrorEventfor cleanup. Fiber suspension (Protocol::handleRequest, early return on$fiber->isSuspended()) means the terminal event can be delayed or skipped from the subscriber's perspective. - Subclassing
Server— not portable; transports and framework integrations instantiateServerdirectly via theBuilder. - Transport-level hooks — would require a change in every transport implementation (Stdio, StreamableHttp, any custom transport) rather than in one place in
Server::run().
Backward compatibility
Purely additive. Subscribers that don't care about the new events are unaffected. No public API changes to existing events or handlers.
- 主要言語
- PHP
- スター
- 1.6k
- フォーク
- 173
- 平均マージ
- 2日 49分
- マージ済み PR(30日)
- 23
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
modelcontextprotocol/php-sdk のほかの issue
-
[Server] Handler type uses bare Closure, hard to decorate RegistryInterface under strict PHPStan オープンServer
難易度 1/5 1時間未満 初心者へのやさしさ 78/100
modelcontextprotocol/php-sdk#468 · コメント 2 件 ·
-
needs confirmation needs maintainer action Server
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
modelcontextprotocol/php-sdk#398 · リアクション 1 件 ·
-
enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
modelcontextprotocol/php-sdk#370 ·
-
enhancement
難易度 4/5 3〜5日 初心者へのやさしさ 55/100
modelcontextprotocol/php-sdk#510 · コメント 1 件 ·
-
bug
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
modelcontextprotocol/php-sdk#504 ·
modelcontextprotocol/php-sdk の issue をすべて見る
似ている issue
-
sync-en
難易度 1/5 1〜3時間 初心者へのやさしさ 85/100
-
sync-en
難易度 1/5 1〜3時間 初心者へのやさしさ 85/100
-
Перевод устарел
難易度 1/5 1〜3時間 初心者へのやさしさ 78/100
-
[6.x]: "Cannot use object of type stdClass as array" loading Users index (regression of #19182) オープン
難易度 1/5 1時間未満 初心者へのやさしさ 90/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100