⚒️
Web開発者のための便利ツールを集めたMCPサーバーを作って公開した

2025/04/20に公開
 はじめにWeb開発やスマホアプリ開発をしていると、様々な"変換作業"や"ちょっとした処理"が必要となりますよね？

Base64エンコード/デコード、カラーコードの変換、日時フォーマットの変更、QRコード生成など、これらの作業をスッとできると、開発効率がちょっと良くなると思います。
それが、VS CodeのGitHub Copilotで「やりたいこと」を投げるだけで、ツールが自動選択され、結果が返ってくると便利かなーと思いました。

ただ、こういった "計算" や "変換" をAIにしてもらうのはまだ不安があるので、流行りのMCPを作ることにしました。
そんな思いからできたのが web-development-toolbox-mcp です。

このMCPサーバーの紹介と、MCPサーバー作るときのTipsなどを書き残しておきます。

 提供機能このツールボックスには以下の機能が実装されています：
encode_base64 / decode_base64
文字列のBase64エンコード/デコード
hex_to_rgb / rgb_to_hex
HEXカラーコード（#FFFFFFなど）とRGBカラー値の相互変換
rgb_to_hsv / hsv_to_rgb
RGBカラー値とHSVカラー値の相互変換
unix_to_iso / iso_to_unix
UnixタイムスタンプとISO 8601形式の日時の相互変換
generate_qr_code
テキストからQRコードを生成
decode_jwt
JWT（JSON Web Token）のデコード
generate_uuid
UUID v4とv7の生成
generate_placeholder_image
指定したサイズのプレースホルダー画像の生成

 セットアップ方法READMEのSetupを見ていただけばわかると思います。
https://github.com/noboru-i/web-development-toolbox?tab=readme-ov-file#usage-with-vs-code
ただ、commandが npx だけだと、うまく動かない場合がありました。

（たしか、 Error spawn npx ENOENT というエラーが出てたはず。）

自分の環境では、 which npx の結果に置き換えると、正常に動作するようになりました。
settings.json
{
  "mcp": {
    "servers": {
      "web-development-toolbox": {
        "command": "/Users/noboru/.asdf/shims/npx", // ここを、 `which npx` の結果にした
        "args": ["-y", "noboru-i/web-development-toolbox"],
        "env": {}
      }
    }
  }
}
VS Code / VS Code Insider / Claude Desktop で動作しています。

（たぶん、他でも動作するはず。他環境でうまく使えたら、コメントいただけると嬉しいです）

 使用例
 Base64エンコード

 カラーコード変換

 unixtime変換

 QRコード生成
※ 現状、VS Code / VS Code Insider 1.100.0 では、生成結果をうまく表示してくれません。

※ Claude Desktopでも、 "View result from ..." を展開しないと表示されません。

（対応方法をご存じの方がいれば、教えて下さい。。。）

 JWTデコードhttps://jwt.io/ と同様な結果が出力されます。

 UUID生成MCP toolではv4とv7の両方が生成されますが、AIが取捨選択してくれます。

 プレースホルダー画像生成
※ QRコード生成と同様、Claude Desktopでしか動作していません。。。

 組み合わせて利用「どんなツールを利用したらよいだろうか？」を考える必要がなく、欲しい情報・実行してほしい処理を直接依頼できます。

 まとめ「web-development-toolbox-mcp-server」が、日常業務の効率化のお役に立てれば幸いです。

 関連リンクGitHub: https://github.com/noboru-i/web-development-toolbox
npm: https://www.npmjs.com/package/web-development-toolbox-mcp-server

 付録：MCPサーバー作成時のTips
 デバッグ方法「どのMCPサーバーが使われるのか？」は生成AIのさじ加減なので、E2Eでの自動テストなどの手法は確立されていない認識です。
その中でも、ちょっとでもラクしてデバッグしたいと思い、いくつかの方法を行いました。
前提として、TypeScriptの @modelcontextprotocol/sdk@1.9.0 を利用しています。

（気がついたら、すでにマイナーバージョンアップしたものが公開されてますね。。。）

 1. MCP inspectornpm run build & npx @modelcontextprotocol/inspector node dist/index.js と実行すると、

🔍 MCP Inspector is up and running at http://127.0.0.1:6274 🚀 と出力されるので、そのURLにアクセスすると、以下の表示となります。
そこから、

"Connect" > "List tools" > テスト対象のtool > データを入力して "Run Tool"

とすると、実装したMCPツールが確実に呼び出されます。
実装中に console.error があると、左下にログ出力されるので、デバッグも容易です。

 example-projectMCP inspector によって、「呼び出されたあと、確実に動作するのか」はテストできますが、

そもそも、MCP toolの description や inputSchema の意図がうまくAIに伝わらず、選択してもらえなかったら意味がありません。
VS Codeで開発して、そのプロジェクト内で mcp.json を定義しても、うまく動いてくれないケースがありました。

そのため、以下のような .vscode/mcp.json を持つディレクトリをプロジェクト内に作成し、それを別ウィンドウとして開くことで、テスト環境としました。

（相対パスで指定できたので、repositoryがどこにcloneされても動作するはず、、、です。）
 .vscode/mcp.json
{
    "servers": {
        "web-development-toolbox": {
            "command": "node",
            "args": [
                "${workspaceFolder}/../dist/index.js"
            ]
        }
    }
}
コード修正後は、本体側で npm run build を行い、

テスト環境側で、 mcp.json の servers の下にある Restart を押すことで再読み込みされ、

Copilot chat viewで自然言語による指示を出し、実際に「AIに選択してもらえるのか？」などを確認しました。

 Claude Desktop使用例のところでも書いた通り、現時点のVS Codeでは、MCP toolから画像データを返却しても、うまく解釈してくれませんでした。
そのため、「MCPの本家」であるClaude Desktopでも動作確認を行いました。
 claude_desktop_config.json
{
  "mcpServers": {
    "web-development-toolbox": {
      "command": "node",
      "args": [
        "/full_path_to_project/web-development-toolbox/dist/index.js"
      ]
    }
  }
}
こちらはnpm packageとして配布する前に動作確認をしたいので、 node コマンドで実行しています。

また、相対パスで指定できないので、フルパスで指定しました。
コード変更後は npm run build を実行し、一度Claude Desktopを終了（Command + q）し、再起動して確認しました。
Claude DesktopでのMCPログの確認
Claude Desktopは、macでは ~/Library/Logs/Claude に出力されるようです。
また、 console.log を使うと、stdioのメッセージとバッティングして、ログとして出力されない。（おそらく、変なエラーになる）

そのため、console.error を使う必要があります。
https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#stdio
The server MAY write UTF-8 strings to its standard error (stderr) for logging purposes.

 付録のまとめこのあたりのデバッグ環境、もうちょっと楽になると嬉しいですね。。。
（この記事は、AIに作ってもらったあとに調整しました）