Capability control over MCP

pulp-mcp projects Pulp's canonical capability-control registry as typed MCP tools. The projection does not invoke the pulp CLI and does not implement a second authorization or execution path. Discovery, exact-instance selection, protocol negotiation, grants, consent, receipts, cancellation, progress, and artifact ACL checks all remain owned by the installed broker and shared ControlClient.

Typed tools

Every broker-authorizable frozen dev.pulp.*@1 operation is exposed as a stable pulp_control_* tool generated from the canonical operation registry. For example, dev.pulp.state/read@1 becomes pulp_control_state_read, dev.pulp.gpu/health.read@1 becomes pulp_control_gpu_health_read, dev.pulp.state/parameter-gesture@1 becomes pulp_control_state_parameter_gesture, and dev.pulp.runtime/evaluate@1 becomes pulp_control_runtime_evaluate. Registry operations with neither a grant path nor broker-owned artifact ACL authorization are not advertised: no MCP annotation or caller-supplied value can create authority for them. Each operation takes:

• instance_id: the exact broker-owned live instance;
• optional request_id: a caller-visible correlation ID needed when another concurrent MCP request may cancel the operation;
• input: the operation's closed canonical input schema;
• optional grant_id, profile, expected_state_generation, and bounded timeout_ms adapter fields.

timeout_ms is one end-to-end operation deadline. Session connection and enrollment, exact-instance inventory, implicit grant issuance, negotiation, and the final request each receive only the time remaining from that single monotonic budget.

The tool's inputSchema and outputSchema are generated from the same frozen registry used by the CLI and service. Results contain typed structured content, the correlated request and receipt IDs, terminal state, artifacts, and bounded progress observations. pulp_control_cancel sends the canonical cancellation envelope. pulp_control_artifact_read returns broker-ACL-checked chunks rather than writing arbitrary local paths.

pulp_control_gpu_health_read takes the usual exact instance_id, grant or read-only profile, deadline, and an empty operation input object. Its typed output is the same installed pulp.gpu-health-read-result.v1 schema used by the C++ control executor. The result is useful only when that exact live host advertises a real product provider; tool listing alone is not proof that startup measurement, Perfetto correlation, or a final optimization disposition is available. Agents should preserve null evidence IDs and incomplete/event-loss states rather than searching for a newest trace or substituting another live instance.

MCP resources expose exact instance metadata and ACL-checked artifacts under pulp-control://. They are read resources, not lifecycle subscriptions; broker-backed live telemetry subscriptions use the generated pulp_control_telemetry_subscribe operation. A client that supplies an MCP progress token receives notifications/progress; the final structured result also carries the validated progress sequence so clients without notification UI support do not lose evidence.

Consent is not MCP metadata

Tool annotations and any client-side confirmation UI are advisory. They never create a grant. Grant requests go to the broker, which obtains consent from its trusted composition root and rejects absent or replayed decisions. Critical operations, including runtime evaluation, require an explicit broker-issued grant backed by a single-use broker-owned consent decision; the MCP adapter does not auto-grant them and has no argument that can claim approval. An interactive consent decision is single-use when the broker issues a grant, but capabilities on that grant retain their established reusable operation behavior except for GPU startup-health reads. An interactive dev.pulp.gpu/health.read@1 approval may admit one fresh idempotency identity, then permits only durable receipt replay of that exact operation. A different GPU-health operation requires new consent. Reusing the exact operation after reconnect does not execute it again and does not create a second receipt. An explicit existing-user policy may authorize reusable GPU-health reads. Revocation, expiry, publication changes, and instance teardown remain effective during a call because the adapter sends the canonical grant and instance lineage and reports the broker's terminal receipt rather than assuming success.

Existing-tool break and side-effect inventory

The legacy live Inspector MCP tools are intentionally replaced as follows:

Previous tool	Disposition	Canonical replacement
pulp_inspect_set_param	Removed; no read-only alias. The old live mutation is now an announced, grant-gated operation.	pulp_control_state_parameter_gesture
pulp_inspect_evaluate	Removed. Its former description was stale: evaluation could execute live code. Runtime evaluation is critical and requires an explicit broker grant backed by single-use consent.	pulp_control_runtime_evaluate
pulp_inspect_screenshot	Removed. It never performed live capture after legacy authority deletion.	pulp_control_ui_capture for an authorized live instance; pulp_screenshot remains only a demo/script fixture renderer.

Other agent-reachable side effects stay outside capability control for this phase:

• pulp_create scaffolds source files in a user-selected project directory. It is an authoring/workspace operation, not an operation against a live plugin instance, so it remains outside the instance capability model.
• pulp_screenshot, pulp_simulate_click, pulp_get_view_tree, and the Motion fixture/visual-analysis paths operate on built-in demos, scripts, or explicit fixture files. They remain outside live-instance authority. Live capture, input, and Motion control use the corresponding generated pulp_control_ui_*, pulp_control_trace_control, or other canonical tools.

This boundary is based on the authority target, not whether a tool happens to have a side effect: live plugin authority must pass through the broker; local workspace and fixture workflows retain their existing explicit filesystem or demo scope.