# MCP仕様更新（2025-03-26）への対応計画
## 概要
MCP仕様の更新（2025-03-26）に対応するための実装計画を整理しています。このドキュメントでは、既に完了したツールアノテーション機能の実装と、今後実装予定の機能、およびその優先順位を記載します。
ツールアノテーションの追加作業は完了しており、残りの未実装機能について計画を立てています。
## 未完了の作業
### MCP仕様更新（2025-03-26）への対応
以下の機能については、まだ実装が完了していません：
1. **JSON-RPCバッチング**
- 複数のリクエストや通知を一度に処理する機能
2. **ProgressNotificationの拡張**
- `message`フィールドの追加による進捗状況の詳細表示
3. **Streamable HTTPトランスポート**
- 新しいHTTPトランスポートの実装
- セッション管理機能
- 再開可能なストリーム
4. **completions機能の実装**
- 引数の自動補完機能を明示的にサポート
## 実装計画
以下の優先順位で実装を進めます：
### 1. JSON-RPCバッチング（優先度：高）
- **理由**: クライアントとの通信効率が大幅に向上し、パフォーマンスが改善される
- **実装範囲**:
- `src/server/MCPServer.js`の修正
- `src/server/handlers/BatchRequestHandler.js`の新規作成
- バッチ処理対象ツールの選定と実装
#### バッチ処理対象ツール
**第一フェーズ（優先実装）**:
- 読み取り系ツール
- `get_record`: 単一レコードの取得
- `get_apps_info`: アプリ情報の取得
- `get_form_layout`: フォームレイアウトの取得
- `get_preview_app_settings`: プレビュー環境のアプリ設定取得
- `get_preview_form_fields`: プレビュー環境のフォームフィールド情報取得
- `get_preview_form_layout`: プレビュー環境のフォームレイアウト情報取得
- デプロイ関連ツール（特別対応）
- `deploy_app` + `get_deploy_status`: デプロイ処理とステータス確認をセットで実行
**第二フェーズ（追加実装）**:
- 書き込み系ツール
- `create_record`: レコード作成
- `update_record`: レコード更新
- `add_record_comment`: レコードコメント追加
- 長時間実行ツール
- `search_records`: 複数レコードの検索
- ファイル関連ツール
- `upload_file`: ファイルアップロード
- `download_file`: ファイルダウンロード
#### 実装アプローチ
1. バッチリクエスト処理の基本フレームワーク実装
2. ツールタイプに基づくグループ化処理
3. デプロイ関連ツールの特別処理（ペアリング機能）
4. 並列処理の最適化とエラーハンドリング
#### 想定工数
- 基本実装: 1日目
- デプロイツール特別対応: 1日目
- テストと最適化: 1日目
- 合計: 3人日
### 2. ProgressNotificationの拡張（優先度：中〜低）
- **理由**:
- ユーザー体験の向上に寄与するが、実装の難易度が高い
- 現在のkintone-mcp-serverでは、ほとんどのツールがkintone REST APIと1対1で対応しており、進捗状況を把握できるツールが少ない
- 進捗通知が有効に機能するのは一部のツール（`search_records`や`deploy_app`など）に限られる
- **実装範囲**:
- `message`フィールドの追加
- 進捗状況の詳細表示機能の実装
- **実装の課題**:
- `search_records`ツールはNode.js標準のfetchで`GET /k/v1/records.json`を直接呼び出す実装に変更した。ページネーションしていないため501件以上のレコードを取得できない
- ProgressNotificationを実装するには、`getAllRecords`の使用をやめて、`getRecords`と`getRecordsCount`を使用した手動ページネーションに変更する必要がある
- この変更は既存コードの大幅な改修を伴うため、リスクが高い
- **適用可能なツール**:
- `search_records`: 手動ページネーションに変更することで実装可能
- `deploy_app`: デプロイ状態の確認と組み合わせて実装可能
- **想定工数**: 中（3-4人日）
- **実装例**:
```javascript
// 進捗通知の拡張
{
"jsonrpc": "2.0",
"method": "notifications/progress",
"params": {
"progressToken": "abc123",
"progress": 50,
"total": 100,
"message": "50件中25件のレコードを処理しました"
}
}
```
### 3. Streamable HTTPトランスポート（優先度：低）
- **理由**: 接続の安定性向上とセッション管理の改善
- **実装範囲**:
- 新しいHTTPトランスポートの実装
- セッション管理機能の追加
- 再開可能なストリームの実装
- **想定工数**: 大（5-7人日）
- **技術的検討事項**:
- Express.jsベースのHTTPサーバー実装
- セッション管理のためのUUID生成と有効期限管理
- SSEストリームの再開機能の実装
### 4. completions機能の実装（優先度：最低）
- **理由**:
- 現在のkintone-mcp-serverでは適用できる箇所が限られており、有効性が低い
- 主要なツールはすでにある程度の説明とバリデーションを備えており、補完機能の追加価値が小さい
- kintone REST API が completions機能を実装するために十分な機能セットを提供していない
- **実装範囲**:
- `completions`機能のサポート追加
- 引数の自動補完機能の実装
- **適用可能な箇所**:
- フィールド関連: フィールドコード、フィールドタイプの補完
- アプリ関連: アプリID、スペースIDの補完
- ユーザー関連: ユーザーコード、グループコードの補完
- 検索クエリ関連: フィールド名、演算子の補完
- **実装の課題**:
- 補完候補の取得にはkintone APIへの追加呼び出しが必要な場合が多く、パフォーマンスに影響する
- 多くの場合、ユーザーは既に必要な情報（アプリID、フィールドコードなど）を把握している
- 補完機能の実装に対するコストパフォーマンスが低い
- **想定工数**: 中（3人日）
- **実装例**:
```javascript
// src/server/MCPServer.js
this.server = new Server(
{
name: 'kintonemcp',
version: '5.0.0',
},
{
capabilities: {
tools: {},
completions: {} // 追加
},
}
);
// 自動補完ハンドラーの追加
this.server.setRequestHandler(CompletionRequestSchema, async (request) => {
// 引数の自動補完処理
return {
completion: {
values: ["候補1", "候補2", "候補3"],
total: 3,
hasMore: false
}
};
});
```
## 今回は対応を見送る（先送りする）機能
以下の機能については、現時点での優先度や必要性を考慮し、今回の実装では見送ります：
1. **認証フレームワーク（OAuth 2.1ベース）**
- 理由：
- 現在のkintone-mcp-serverは主に環境変数による認証を使用しており、OAuth認証の必要性が低い
- 実装の複雑さに対して、現時点での優先度が低い
- StdioトランスポートではOAuth認証は推奨されていない（仕様上も明記）
2. **オーディオデータのサポート**
- 理由：
- kintoneの現在のAPIではオーディオデータの直接的な扱いが限定的
- 現在のユースケースでは優先度が低い
- 将来的なニーズに応じて実装を検討
## 参考資料
- [MCP仕様 2025-03-26](./mcp-specification/2025-03-26.txt)
- [MCP仕様 2024-11-05](./mcp-specification/2024-11-05.txt)
- [ツールアノテーションドキュメント](./tool-annotations.md)
