この記事を読んでまず思ったのは、こういう切り分けを最初から言語化しておくのはかなり大事だ、ということだった。MCP server まわりって、つい「テスト通ったし大丈夫」で済ませたくなるけれど、著者はそこをはっきり否定している。protocol と、agent が実際に使ったときの挙動は別物だ、という指摘は地味だけど効く。
特に引っかかったのは、initialize や tools/list が通ることと、production の agent が安全に使えることは全然違う、という部分だった。これは言われれば当たり前なのに、現場だとかなり混同されやすい。人間が curl して成功したログを見て安心してしまう、あの感じに近い。けれど agent は気まぐれだし、似た tool を取り違えるし、失敗すると retry もする。その結果、最後の応答だけ見ていると見逃す副作用が残る。ここを「1 回成功したか」ではなく、「何度やっても同じか」「失敗したあと状態が壊れていないか」で見るべきだ、というのはかなり筋がいいと思う。
もう一つよかったのは、これは checklist ではなく rubric だと最初から言い切っている点だ。ありがちな「ログを足そう、auth を入れよう、テストを書こう」みたいな wish list ではなく、go / no-go の判断材料にする、という態度がはっきりしている。しかも Tier 1 と Tier 2 を分けているので、protocol の出来と agent から見た実用性を混ぜない。ここが曖昧だと、どこが悪いのか分からないまま「なんとなく不安」で止まるので、レビューの場ではかなり使いやすそうだと思う。
ただ、これをそのまま現場に持ち込むと、運用が少し重くなる気はする。毎回の release で repeatable に回せる形にしないと、結局「前回どうだったっけ」で終わってしまうからだ。コメント欄でも tool 数が増えた話が出ていたが、まさにそこが現実的な悩みなんだろう。rubric 自体はきれいでも、version をどう固定するか、どの時点で再評価するかは別の設計が要る。そこまで含めて初めて、ただの理想論ではなくなるのだと思う。
参考: A Go/No-Go Rubric for Evaluating MCP Servers Before They Touch Production Traffic
