PaPoo
cover

たかが重複、ではなく「起動前に落とすべき設定ミス」という感覚

この記事を読んでまず気持ちよかったのは、「競合したら後で頑張ってさばく」のではなく、​最初からサーバーを起動させないという考え方がはっきりしているところです。
これ、地味だけれど運用ではかなり効く発想だと思いました。実行時にたまたま先に登録された方が勝つ、みたいな挙動はたしかに便利そうに見える。でもその便利さって、裏返すと「設定を少し並べ替えただけで別物になる」危うさでもあるんですよね。

特に引っかかったのは、extension の method 名をただの内部実装ではなく、​公開契約として扱っている点です。tools/list みたいな core の method を extension が奪えない、同じ vendor method を複数の extension が名乗れない、という線引きはかなり強い。ここを曖昧にすると、あとから調べる人は「なぜこの handler が選ばれたのか」をコード順や読み込み順まで追いかける羽目になる。そういう事故を、起動時の ValueError で止めるのは実務っぽくて好ましいです。

もう一つ面白かったのは、空の protocol_versions を弾く話です。最初は「そこまで厳しくなくても」と思いかけたのですが、考えてみると、到達不能な binding を登録するのは、存在しない API を置いておくのと同じで、後で混乱のもとになります。
こういう「動かない設定」を早く落とす設計は、テストのためだけでなく、設定を分業するチームにも効くはずです。誰かが壊したとき、壊れた場所で止まるからです。


参考: MCP Python SDK の拡張メソッド衝突: サーバー開始前に失敗させる

同じ著者の記事