Canary について
Canary は、実際のワークフロー向けではなく、リリース基盤の検証に使う Mindstone 内部の MCP サーバーです。唯一の `ping` ツールは、メッセージにバージョン付きの接頭辞を加えて返します。
主な機能
- 01単一の `ping` ツール
- 02`pong v3: ` を付けてメッセージを返却
- 03認証と外部依存なし
活用シーン
- 01MCP リリースパイプラインの一貫したテスト
- 02ホストによる stdio MCP サーバー起動の確認
MCP 対応
MCP クライアントに単一の `ping` ツールを公開し、入力メッセージに `pong v3: ` を付けて返します。
設定
ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。
ツール
1掲載時のツール一覧 · 2 週間前に更新
| パラメーター | 型 | 必須 | 説明 |
|---|---|---|---|
| message | string | はい | エコーする短いメッセージ。1～200 文字。 |
詳細
@mindstone/mcp-server-canary
Mindstone の内部リリースパイプラインをテストするコネクターです。使用しないでください。rebel-oss のリリースパイプラインをエンドツーエンドで検証することだけを目的としています。ping ツールが 1 つあるだけで、外部依存関係、認証、ブリッジはありません。
ワンクリックインストール
必須の環境変数はありません。プロンプトなしでインストールが完了します。
Claude Desktop / Claude Code / Goose / Continue.dev 用の手動設定（Canary）
{
"mcpServers": {
"Canary": {
"command": "npx",
"args": [
"-y",
"@mindstone/mcp-server-canary"
],
"env": {}
}
}
}
存在理由
新しいパイプライン（Trusted Publishing、GitHub Actions、mcp-publisher、レジストリ同期、ホストアプリのカタログ）を通じて実際のコネクターを初めてリリースすると、パイプラインの正確性とコネクターの正確性という 2 つの未知の要素が結び付いてしまいます。canary はこの 2 つを切り分けます。動作が ping → pong v3: <message> だけのツールを使って、パイプラインの各ステップをすべて実行します。
canary でパイプラインの安定性が確認できれば、実際のコネクターはインフラのデバッグに便乗することなく、同じ手順を採用できます。
設計の詳細については、docs/plans/260525_oss_release_automation.md（Mindstone 内部向け）を参照してください。
ツール
ping
メッセージを pong v3: <message> で包んで返します。
| フィールド | 型 | 必須 | 説明 |
|---|---|---|---|
message | string | はい | 返す短いメッセージです。1～200 文字。 |
例：
{
"tool": "ping",
"arguments": { "message": "hello" }
}
レスポンス：
pong v3: hello
ローカルでの使用
npx -y @mindstone/mcp-server-canary
これにより、stdio でサーバーが起動します。ほとんどの MCP ホストでは、@mindstone/mcp-server-canary を stdio MCP サーバーとして追加すると、自動的にサーバーが起動します。
ステータス
1.0 より前のバージョンです。これは canary です。バージョンは意図的に 0.0.x としています。実際のワークフローではこのコネクターに依存しないでください。リリースの仕組みをテストすることだけを目的としています。
コメント
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。