You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(api): expose & persist auto_approve_tool_changes in server REST API (MCP-2940)
MCP-2930 (#724) added the per-server auto_approve_tool_changes flag to
config.ServerConfig but did not extend the REST layer, so the Web UI toggle
(MCP-2932, PR #725) could neither read nor persist it.
REST request side:
- Add AutoApproveToolChanges *bool to httpapi.AddServerRequest.
- Wire it into handleAddServer (create) and handlePatchServer with *bool
nil-preserve semantics: omitting it on PATCH preserves the existing pointer
(which may be nil = "never set"); an explicit value (including false) is
applied. server.UpdateServer applies the pointer only when non-nil so callers
that don't touch it (e.g. config-to-secret) never reset it.
REST read side:
- Add AutoApproveToolChanges *bool to contracts.Server (omitempty → tri-state
nil stays out of the payload so the UI can tell unset from explicit false).
- Emit auto_approve_tool_changes from runtime.GetAllServers (StateView path)
and getAllServersLegacy, in parity with quarantined.
- Project it in management.ListServers and ConvertGenericServersToTyped /
ConvertServerConfig.
Persistence:
- SaveConfiguration rebuilds the JSON config's server list from BBolt records,
so a field absent from storage.UpstreamRecord is wiped on the next mutation.
Add AutoApproveToolChanges to UpstreamRecord and all four selective
conversions (Save/Get/List in manager.go, saveServerSync in async_ops.go);
update TestSaveServerSyncFieldCoverage to require it in BBolt. Verified the
flag now survives PATCH→GET and a full restart.
Tests: handler PATCH (set/preserve-nil/preserve-true/explicit-false) + GET
exposure; management + contracts projection; storage Save/Get/List round-trip
incl. tri-state nil. OpenAPI regenerated. Docs updated (tool-quarantine.md,
rest-api.md).
Related #725. Runtime enforcement remains MCP-2931.
Copy file name to clipboardExpand all lines: docs/features/tool-quarantine.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -82,6 +82,8 @@ Trust specific servers by skipping per-server tool-change review:
82
82
83
83
> **Note — rollout:**`auto_approve_tool_changes` is config-plumbed but its **enforcement is not yet wired** — runtime auto-approval is still governed by `skip_quarantine`. The new flag becomes the active control (and gains the richer rug-pull / trust-baseline behavior) in an upcoming release. Existing `skip_quarantine` configs are unaffected and are migrated onto the new key automatically. To auto-approve a server today, set `skip_quarantine: true`.
84
84
85
+
> **REST API:**`auto_approve_tool_changes` round-trips through the server REST API. `GET /api/v1/servers` includes it on each server object (omitted when unset — the tri-state nil is preserved so the Web UI can tell "never set" from an explicit `false`), and `POST`/`PATCH /api/v1/servers/{id}` accept it. As a tri-state `*bool`, omitting it on `PATCH` leaves the stored value unchanged; sending an explicit `false` clears a prior `true`. The value is persisted to BBolt so it survives a save/restart.
86
+
85
87
When the active control is enabled for a server, new tools from it are automatically approved.
0 commit comments