Repository navigation
MCP: Check command validation against the HTTP API #2632
Description
Check whether MCP rejects the same invalid commands as the HTTP API before database execution. MCP constructs command records differently, so some declared validation may be skipped. A behavior difference has not yet been established.
Compare empty and oversized insert batches and a representative invalid nested argument through both interfaces. If a gap is reproduced, reuse existing command validation at the shared MCP boundary.
This independent follow-up under #2408 is done when the comparison is recorded and any confirmed gap has regression coverage. If existing checks already provide the same behavior, close with that evidence. Coordinate error handling with #2628.
Status on October 23, 2026
PR #2655 fixes this. MCP now runs the existing command validation before schema lookup or execution. Empty or oversized insert batches and invalid find options return the same error code and reason as HTTP. The PR also adds an MCP guide. It sits in the MCP stack, so it has no CI run yet.
Implementation requirements and source references
Tracking issue: #2408.
Tracking correspondence: Related changelog IDs are listed below. This is an independent follow-up, outside the launch milestone unless promoted for a demonstrated release blocker. Shared requirement IDs remain stable across the delivery plan and #2408.
Why
HTTP requests validate command records with @Valid. MCP tools construct those records directly. For example, the insertMany record declares non-empty and maximum-batch-size constraints that are not on the MCP tool argument.
This suggests a possible validation gap, but it does not prove that an invalid command reaches the database. Downstream checks may already reject it. This ticket is an investigation with a conditional fix, not a known Quarkiverse 2.0.3 incompatibility.
Work
- Send empty and oversized insert batches, plus a representative invalid nested argument, through both HTTP and MCP.
- Compare accepted inputs, validation failures, and whether database execution begins.
- If a gap is reproduced, reuse existing command validation at the shared MCP boundary. Avoid duplicating checks that already run downstream.
Done when
Record the comparison and add regression coverage for any confirmed difference. Invalid commands are rejected before execution, while valid and optional inputs continue to work. If existing checks already provide parity, close this ticket with that evidence and no redundant implementation.
Coordinate error mapping with #2628. This investigation does not automatically block the SDK smoke or package upgrade.
Modern protocol and OAuth acceptance details
Keep this investigation separate from protocol schema evolution. Test the actual accepted command domain even when a schema uses composition or references. Bound schema processing where the implementation handles it, but do not introduce arbitrary remote $ref fetching. Invalid OAuth credentials and permission failures remain at the authorization boundary, not bean-validation errors.
Changelog traceability
- m10 Support the current schema model, lines 49–52 — Required audit.
Normative detail: Streamable HTTP, authorization, caching.
Required base protocol/schema behavior remains owned by #2625 and verified by #2626. This follow-up owns only its stated enhancement or proven gap.
Activity
[-]Align MCP command validation with the HTTP API[/-][+]MCP: Align command validation with the HTTP API[/+][-]MCP: Align command validation with the HTTP API[/-][+]MCP: Check command validation against the HTTP API[/+]