Ensure newly advertised server capabilities are re-validated before invocation

How it is checked

Audit method: Manual review

This recommendation cannot be checked automatically. A scan lists it with these instructions when you pass --include-manual.

Confirm that a capability newly advertised beyond the approved baseline is denied until explicitly re-approved, and that each change is logged with a capability diff and an approval state. Identify two capabilities to use as probes: one advertised beyond the baseline and not yet re-approved (the staged probe), and one already in the baseline and known to be invocable (the control probe). A denial of the staged probe is then attributable to the staging gate rather than to the probe itself, because the control probe confirms invocation otherwise works. Supply schema-valid arguments in APPROVED_ARGS and PENDING_ARGS since a tool invoked with invalid arguments returns an error indistinguishable from a gate denial. Extend DENY_PATTERN to match the wording the local gate emits. Run the following script to attempt both invocations and compare the outcomes: MCP_URL="https://<SERVER_URL>/mcp" APPROVED_TOOL="<BASELINED_TOOL>" PENDING_TOOL="<TOOL_ADVERTISED_SINCE_LAST_APPROVAL>" APPROVED_ARGS='<JSON_ARGUMENTS_VALID_FOR_APPROVED_TOOL>' PENDING_ARGS='<JSON_ARGUMENTS_VALID_FOR_PENDING_TOOL>' DENY_PATTERN='pending|not approved|unapproved|unauthorized|awaiting approval|forbidden|denied' envelop...

How it is fixed

Fix method: Guidance or infrastructure patch

Implement a capability staging gate at the application or host layer, or at a centralized gateway. A plain reverse proxy cannot host the gate since the decision depends on protocol-level capability state. Open and maintain the subscriptions/listen streams covering every notification type in scope, and re-establish any stream that closes, because a server sends no type the client has not requested. A capability set can also refresh when its freshness expires, so run the diff on every refresh, not only on receipt of a notification. On each refresh, diff the newly advertised set against the last approved set, place additions in a pending state, deny their invocation, and record the event. Where the gate is inside the server's own tool handling, the denial reaches the client as a successful result carrying isError: true, so make the denial text name the pending or unauthorized state. Record each change in the audit log with the capabilities added as a non-empty list of names, the approval state (pending, approved, or denied), the approver, and the timestamp. The approver and timestamp may be null only while the state is pending. Use the same field names the Audit reads. Tie the appr...