[Bug]: MCP read_records tool's "select" parameter fails on comma-separated field lists with a space after the comma (missing .Trim())

[GMGassner]

Describe the bug

read_records's select parameter is documented only as "Comma-separated field names." (the entire schema description — no formatting restriction, no example). But ReadRecordsTool.cs splits it without trimming whitespace:

IEnumerable<string> fieldsReturnedForFind = select.Split(",").ToList();

(src/Azure.DataApiBuilder.Mcp/BuiltInTools/ReadRecordsTool.cs:204)

So select: "wiegungdt,istmenge_t" (no space) works, but select: "wiegungdt, istmenge_t" (space after comma — an extremely natural way to write a list, and what LLM tool-callers reliably produce) fails, because the untrimmed leading space becomes part of the field name being validated:

{
  "toolName": "read_records",
  "status": "error",
  "error": { "type": "BadRequest", "message": "Invalid field to be returned requested:  istmenge_t" }
}

(note the double space before istmenge_t in the message — the leading space from the unsplit input is preserved literally)

Confirmed the field genuinely exists (both in the underlying view and in the entity's own configured fields list) — this is purely a parsing issue, not a real invalid-field case.

Why I don't think this is "using it wrong"

• The tool's own select parameter description doesn't warn against whitespace or specify a strict format.
• DAB's REST $select (OData) already tolerates whitespace around the comma delimiter as part of standard OData grammar — this MCP tool doesn't reuse that parser, it's separate, newer, hand-rolled string splitting that doesn't match the tolerance the rest of the product already has.

To Reproduce

Against any entity/view with at least two columns, call read_records with:

• select: "col_a,col_b" → succeeds
• select: "col_a, col_b" → fails with Invalid field to be returned requested: col_b

Expected behavior

select should trim whitespace around each comma-separated field name, e.g.:

IEnumerable<string> fieldsReturnedForFind = select.Split(',').Select(s => s.Trim()).ToList();

Versions

Confirmed present in v2.0.9 and still present on main HEAD / v2.1.0-rc (2026-08-11) as of this report (2026-08-13) — not yet fixed anywhere upstream.