【要約】公式MCPのfetchサーバーでGitHubを読もうとしたら、「robots.txtが禁止している」と出たが本当の理由は別だった [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者がMCPサーバーを用いて外部Webサイトの取得を試みた際、エラーメッセージが真の原因を隠蔽してしまう問題に直面した。本件では、実行環境の制約がサイト側の規約と混同される事態が発生している。
- ・GitHubへのアクセス時に「robots.txtが禁止している」という誤ったエラーが出る。
- ・実際はサイトの規約ではなく、実行環境のネットワーク制限による403エラーである。
- ・サーバーの実装が、403エラーをrobots.txtの拒否と同一視している。
// Approach
筆者はエラーの発生レイヤーを特定するため、検証環境を用いて段階的な検証を行った。実在する規約の挙動確認から、設定変更による回避実験までを実施している。
- ・PyPIのrobots.txtを用い、規約による拒否が正しく機能するかを確認した。
- ・GitHubへのアクセスにおける403エラーの発生状況を観測した。
- ・「--ignore-robots-txt」オプションで、判定をスキップできるか試行した。
- ・到達不能ドメインへのアクセスを行い、エラーメッセージの差異を比較した。
// Result
検証の結果、エラーメッセージの誤認原因と、サーバーの挙動特性が明らかになった。エラーの発生箇所によって、情報の詳細度が異なることが判明している。
- ・robots.txt判定時は定型文、実取得失敗時は具体的な例外内容が返る。
- ・「--ignore-robots-txt」は、環境の通信制限までは回避できない。
- ・ページ分割取得（max_length/start_index）は正確に動作する。
- ・Markdown変換は、raw指定の有無ではなくcontent-typeで自動判定される。
Senior Engineer Insight
> エラーハンドリングの抽象化が、トラブルシューティングの難易度を上げている。本実装では、403エラーをrobots.txtの拒否と同一視しており、環境由来の制限をサイト側の規約と誤認させる。大規模運用では、ネットワーク層の制限とアプリケーション層の挙動を明確に分離すべきだ。エラーの粒度も、失敗箇所によって異なるため、監視設計には注意を要する。