---
id: review-002-mcp-batch-cap
name: Cap MCP batch tool at MAX_BATCH_OPERATIONS (PRJ-22)
status: completed
depends_on: []
scope: single
risk: low
impact: component
level: implementation
tags: [adapters, review-002, mcp]
---

## Description

Review 002 PRJ-22 [minor]. The MCP `batch` tool has no cap on the
`calls` array (`to_mcp.rs:215-247` executes serially) while HTTP
`/batch` rejects at 101 (`routes.rs:173-184`,
`MAX_BATCH_OPERATIONS`). A 10,000-entry MCP batch occupies the
dispatch spine serially (each invoke up to the 30 s deadline) — the
doc (PRJ-09's fix) advertises no limit either.

## Acceptance Criteria

- [ ] The `batch` tool enforces the same `MAX_BATCH_OPERATIONS` cap
      (share the constant; do not duplicate the literal) — over-cap →
      structured `INVALID_INPUT`-family error consistent with the
      tool's other argument errors (including `retryable`, per PRJ-13)
- [ ] Tool description states the limit (mirroring how `/batch` docs
      it) — ADR-041 shape unchanged (4 fixed tools)
- [ ] Test: over-cap `calls` array → structured error, no dispatch
      happened (spy/gateway-count assert via the existing invoke_tool
      harness)
- [ ] `cargo test --features mcp`, `cargo clippy --all-features
      --all-targets -- -D warnings`, `cargo fmt --check` pass

## References

- docs/reviews/002-post-remediation-review.md (Part F', PRJ-22)
- src/adapters/to_mcp.rs:215-247 (the loop), src/gateway/routes.rs:42,173-184 (the cap to share)
- tasks/adapters/review-001-mcp-tool-fidelity.md (the PRJ-07..10/13 work whose conventions to follow)

## Notes

One of the smallest tasks in the batch — a good first warm-up slice or
fold-in candidate if a session runs short (but keep the commit
separate; it is its own unit of work).

## Summary

MAX_BATCH_OPERATIONS hoisted to gateway/mod.rs (shared by routes/to_mcp/to_openapi); MCP batch rejects >100 calls pre-dispatch with INVALID_INPUT; schema maxItems + tool description updated. GatewayDispatch::invoke_count() test-spy accessor added.