Azure / Azure/data-api-builder

[Gap]: Still no MCP health checks despite MCP being enabled

オープン
#3,565 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る
2.x health-endpoint
主要言語
C#
スター
1.5k
フォーク
370
平均マージ
3日 22時間
マージ済み PR(30日)
9

説明

The health response includes `"mcp": true` in the `configuration` section, but there are no MCP-specific health checks. Only REST and GraphQL entity checks appear.

## Expected

If MCP is enabled and entities are exposed via MCP, MCP endpoint health checks should appear in the `checks` array with tags like `["mcp", "list_tools"]`, similar to how REST and GraphQL each get their own checks.

| Check | Tags | What it validates | Notes |
|-------|------|-------------------|-------|
| **list_tools** | `["mcp", "list_tools"]` | Server up, tools registered, expected count based on what is enabled in the config | Baseline. If this fails, skip the rest. |
| **describe_entities** | `["mcp", "describe_entities"]` | Schema/metadata generation, pagination based on what is enabled in the config | Catches schema generation bugs. Entity count in `data` field is a good signal. |
| **read_entity** (per entity) | `["mcp", "read_entity"]` | Full data retrieval path, top 1 | Mirrors REST/GraphQL per-entity checks. Validates JSON-RPC param binding + result serialization. |
| **aggregate_entity** (per entity) | `["mcp", "aggregate_entity"]` | Aggregation code path, COUNT(*) | Genuinely different query generation than read. Cheap query, high signal. |

** MCP checks would ideally reuse one SSE connection across all MCP checks within a single health evaluation. That keeps the overhead comparable to the REST/GraphQL checks combined rather than multiplied by connection setup cost.

## Actual

The `checks` array only contains:
- Data source checks (`tags: ["data-source"]`)
- REST entity checks (`tags: ["rest", "endpoint"]`)
- GraphQL entity checks (`tags: ["graphql", "endpoint"]`)

No MCP checks exist. Combined with the missing MCP metrics from the OTEL report, MCP remains the least observable API surface.

コントリビューションガイド

コントリビューションガイドを開く

調査の方向性

health レスポンスと既存の REST および GraphQL エンティティチェック生成を見つけ、次に有効化されたエンティティが設定からどのように読み込まれるかを追跡します。指定された tags と baseline 動作を含め、list_tools、describe_entities、read_entity、aggregate_entity 用の MCP チェックを追加し、1 つの SSE 接続を再利用することも検討します。MCP エンティティが有効な場合にのみチェックが表示され、列挙されたパスを検証すれば完了です。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
csharp
領域
api, backend, observability
issue の種類
機能追加
難易度
4/5
見積もり時間
3〜5日
活発さ
静か
明瞭さ
おおむね明確
初心者へのやさしさ
55/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。