Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

[Bug]: MCP orderby takes incompatible shapes in read_records and aggregate_records, and the mismatch returns an opaque UnexpectedError

Đang mở
#3,810 1 bình luận 0 reaction 1 người được giao Xem trên GitHub

@aaronburtle đang làm issue này rồi.

Từ ngày 14/9/2026.

Đánh giá

Issue này chưa được đánh giá.

Mô tả

mcp-server
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
  1. Return an actionable message for the shape mismatch in both tools, as aggregate_records already does for the column-name case. Naming the expected shape would be enough.
  2. 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

Ngôn ngữ chính
C#
Star
1.5k
Fork
372
Merge trung bình
7 ngày 19 giờ
Pull request đã merge (30 ngày)
10

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của Azure/data-api-builder

Tất cả issue của Azure/data-api-builder

Issue tương tự

Thêm issue về C#

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.