[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
- 派生
- 371
- 平均合并
- 9 天 2 小时
- 30 天内合并 PR
- 10
环境准备
在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。
- 提供 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 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
-
bug
难度 2/5 1-3 小时 新手友好度 72/100
fluentassertions/fluentassertions#3353 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 65/100
-
难度 2/5 半天 新手友好度 78/100
unoplatform/uno#24769 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 75/100
AvaloniaUI/Avalonia#22323 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 88/100
microsoft/onnxruntime-genai#2633 ·
维护者通常 1 天内回复