[Bug]: MCP orderby takes incompatible shapes in read_records and aggregate_records, and the mismatch returns an opaque UnexpectedError
メンテナーはふだん 1 日以内に返信
@aaronburtle がすでに取り組んでいます。
2026年9月14日 から。
評価
この issue はまだ評価されていません。
説明
What happened?
The two MCP DML tools accept orderby in mutually incompatible shapes. Passing one tool's shape to the other returns UnexpectedError with no indication of what was wrong, so the caller has no way to discover the correct form from the error.
aggregate_records expects a bare direction string. It sorts by the aggregated value.
| argument | result |
|---|---|
orderby: "desc" |
OK, groups sorted by aggregated value descending |
orderby: "asc" |
OK |
orderby: "COLUMN_NAME" |
InvalidArguments: Argument 'orderby' must be either 'asc' or 'desc' when provided. Got: 'COLUMN_NAME'. — clear and actionable |
orderby: ["desc"] |
UnexpectedError: Unexpected error occurred in AggregateRecordsTool. — opaque |
read_records expects an array of column specifications.
| argument | result |
|---|---|
orderby: ["COLUMN_NAME desc"] |
OK |
orderby: "COLUMN_NAME desc" |
UnexpectedError: Unexpected error occurred in ReadRecordsTool. — opaque |
orderby: "COLUMN_NAME" |
same |
So the shape that is correct in one tool is an opaque failure in the other, in both directions.
Why this matters more for MCP than for REST
The consumer is a language model reading describe_entities output and the tool input schemas. Having learned ["COLUMN desc"] from read_records, it will use that in aggregate_records and get a failure that names neither the parameter nor the expected form. There is no discovery path from the error back to the working call.
Asks
- Return an actionable message for the shape mismatch in both tools, as
aggregate_recordsalready does for the column-name case. Naming the expected shape would be enough. - Consider accepting both shapes, or aligning them.
Two related observations
aggregate_records silently ignores orderby when groupby is absent, rather than rejecting it. A caller asking for sorted output gets unsorted output and a success response.
Grouped results are returned ordered by the aggregated value, and there is no way to order by the group key, because orderby accepts only a direction. For a groupby on a date or period column this means the caller cannot ask for chronological order and has to sort client-side. Given that filtering on a date-typed column is currently broken (#3760), groupby on the date is the only way to reach a single period, which makes the inability to order by that key more limiting than it would otherwise be.
Version
2.1.3-rc
What database are you using?
Azure SQL
What hosting model are you using?
Azure Container Apps
Which API approach are you accessing DAB through?
MCP
- 主要言語
- C#
- スター
- 1.5k
- フォーク
- 372
- 平均マージ
- 9日 2時間
- マージ済み PR（30日）
- 10
環境構築
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
Azure/data-api-builder のほかの issue
-
pgsql
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
Azure/data-api-builder#3598 ·
メンテナーはふだん 1 日以内に返信
-
2.x cli mcp-server
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
Azure/data-api-builder#3576 ·
メンテナーはふだん 1 日以内に返信
-
2.x health-endpoint
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
Azure/data-api-builder#3570 ·
メンテナーはふだん 1 日以内に返信
-
2.x telemetry
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
Azure/data-api-builder#3564 ·
メンテナーはふだん 1 日以内に返信
-
2.x telemetry
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
Azure/data-api-builder#3562 ·
メンテナーはふだん 1 日以内に返信
Azure/data-api-builder の issue をすべて見る
似ている issue
-
area-System.Numerics.Tensors untriaged
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
dotnet/runtime#134691 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
-
ci-failure-cause test-failure
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
AvaloniaUI/Avalonia#22312 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 68/100