MCP surface cannot reach button press, AF-area positioning, touch or tracking — NOT_EXPOSED hides the gap from the coverage gate

[takusaito-ctrl]

Environment: ILCE-7M5 · USB · Camera Remote SDK V2.02.00 · linux-arm64 · server 3.0.0 · mcp/

Summary

Six spec operations that are documented, implemented, and verified working over REST on hardware are unreachable from the MCP server:

operationId	REST endpoint	MCP tool
pressCameraButton	POST /actions/button	none
remoteTouch	POST /actions/touch	none
cancelRemoteTouch	DELETE /actions/touch	none
getAFAreaPosition	GET /af-area-position	none
setAFAreaPosition	PUT /af-area-position	none
getTrackingFrame	GET /tracking-frame	none

This is not accidental drift — scripts/gen-tools.mjs:176-181 classifies them deliberately:

// Endpoints that exist in the spec but are deliberately NOT surfaced as tools.
const NOT_EXPOSED = new Set([
  "getPriorityKey",
  "getAFAreaPosition", "setAFAreaPosition", "getTrackingFrame",
  "getFingerprint",
  "pressCameraButton", "remoteTouch", "cancelRemoteTouch",
]);

The concern is that NOT_EXPOSED is the mechanism that makes the gap invisible. The coverage gate (lines 212-223) only asserts that every operation lands in exactly one of generated / hand-written / not-exposed / x-fern-ignore. Adding a name to NOT_EXPOSED satisfies the gate permanently, with no rationale required and no re-review. The gate reports success while the capability silently does not exist.

The gap is three layers deep

1. api/openapi.yaml — operations fully specified.
2. mcp/src/api/schema.d.ts — types generated from the spec, carrying extensive hardware-verified prose (coordinate spaces, clamping, focus-area preconditions, Touch Tracking vs Touch Focus behaviour, per-body button support).
3. mcp/src/api/client.ts — no methods at all. The actions group has shutter, afShutter, halfPress, focusNearFar, zoom, movieRec and stops there; there is no AF-area or tracking group.

So even a hand-written composite could not call these today without first adding client methods. The documentation effort in layer 2 is currently unreachable from every consumer.

Why these specifically are worth exposing

The excluded set is close to the heart of what an agent driving a camera needs:

• focus_step's own tool description sells a "look → step → look loop" — but the agent can only nudge focus distance. It cannot move where the camera focuses. setAFAreaPosition is exactly that missing half.
• remoteTouch seeds subject tracking, and getTrackingFrame reads the result back. Together they are the only way to say "focus on that subject" — the single most natural instruction a user gives a camera operator.
• pressCameraButton covers menu, D-pad, C1-C7, playback: the fallback for anything the property API does not model.
• All three have well-defined read-backs (getAFAreaPosition / getTrackingFrame return normalized coords for overlays), so they fit the observe-act-observe pattern the rest of the toolset is built on.

Verified working on hardware

From the full 47-endpoint sweep:

• PUT /af-area-position clamping matches the documented model exactly; on this body 0,0 → 80,72, usable x ≈ 80-559.
• GET /af-area-position returns a frame for focus areas with a movable box (Flexible Spot etc.), not Wide/face-priority.
• GET /tracking-frame requires live view to be streaming.
• POST /actions/button returns 200 "pressed" (though it lacks operable-key validation — Spec/behaviour mismatches found in full 47-endpoint hardware sweep #47).

These are not speculative or broken endpoints being held back.

Suggested

1. Require a documented reason per entry in NOT_EXPOSED — e.g. make it a Map<opId, rationale> so the gate forces an explicit justification rather than a bare name. getFingerprint and getPriorityKey plausibly should stay internal; the other six look like they were parked and never revisited.
2. Add the missing client.ts methods so the typed layer matches the spec regardless of tool exposure.
3. Expose at minimum set_af_area (with read-back) and touch_to_track / get_tracking_frame. press_button is a reasonable escape hatch but should gate on the runtime data.supported_buttons list once Spec/behaviour mismatches found in full 47-endpoint hardware sweep #47 is fixed.

Aside

client.ts:74 sends lines and level to /api/server/logs, which the server silently ignores — see #46. Same class of problem: the typed layer promises something the other side does not honour.