modelcontextprotocol / modelcontextprotocol/php-sdk

Add server lifecycle events (ServerStarted / ServerStopped)

オープン
#286 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

enhancement needs confirmation
主要言語
PHP
スター
1.6k
フォーク
173
平均マージ
2日 49分
マージ済み PR(30日)
23

説明

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 + matching ResponseEvent/ErrorEvent and deal with per-request overhead, fiber suspension, and every error path.

Proposal

Add two events in Mcp\Event:

  • ServerStartedEvent — dispatched at the top of Server::run($transport), before the first request is read. Exposes the server and transport.
  • ServerStoppedEvent — dispatched just before Server::run() returns, in a finally so 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 RequestEvent as a pseudo-start hook — works but is per-request. Adds overhead to what is logically a one-shot, and requires pairing with ResponseEvent/ErrorEvent for 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 instantiate Server directly via the Builder.
  • 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.

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

Server::run($transport) から始め、次に Protocol::handleRequest と Builder によって作成された transport のエントリーポイントを確認します。既存の Events と、それらの dispatching のテストがあれば確認します。ServerStartedEvent が最初のリクエストの前に一度だけ発火し、ServerStoppedEvent が正常終了時、例外発生時、transport のクローズ時に finally から発火し、指定されたコンテキストを保持することが完了条件です。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
php
領域
api, backend
issue の種類
機能追加
難易度
4/5
見積もり時間
3〜5日
活発さ
静か
明瞭さ
おおむね明確
初心者へのやさしさ
52/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。