Module mcp 

Transport-free MCP server administration.

WHY THIS EXISTS SEPARATELY FROM uar::api::mcp_admin

The HTTP handlers own AppState and axum extractors, so an EMBEDDED container (mobile, macOS) could not reach any of this — it had no listener to call. That is why the embedded control plane reported “MCP server administration is not available on the embedded runtime”.

The storage and hydration logic never actually needed a transport: it needs a SettingsManager and an McpRegistry. Pulling it here lets the SDK Runtime call it in-process while the HTTP layer becomes a thin adapter over the SAME code, so embedded and remote cannot drift apart.

CONFIGURATION LIVES IN THE DATABASE, NOT IN FILES

Config files SEED the store on first boot (hydrate persists the file-derived registry when the store is empty) and the store is the source of truth from then on. That is what makes a runtime API change take effect without a restart, a file write, or a polling loop — the same contract on an embedded device and a remote server.

Structs

SaveResult

StoredMcpServer

Enums

ApplyOutcome

What happened to a live MCP connection as a result of a write.

Constants

SETTINGS_KEY

Settings key holding the MCP server map. Shared with api::mcp_admin so both surfaces read and write the same rows.

Functions

delete

Remove a server from the store and from the live registry.

hydrate

Seed the store from the file-derived registry on first boot, then make the registry match the store.

list

Read the stored server map. Falls back to whatever the registry was constructed with (i.e. the config file) so a store that has never been seeded still reports the real configuration rather than nothing.

save

Persist a server, then apply it to the live registry when that is safe.