Choose an MCP client workflow
Choose the workflow by the result you need, not by the file format the client happens to use. For supported daily AI-client work, start with LightNow Proxy. Use the other modes only for a specific compatibility or rollout requirement.
Decision table
| Need | Workflow | Command shape |
|---|---|---|
| One managed LightNow entry | Local Proxy | lightnow sync --client <client> --local-proxy |
| Organization chooses profile and policy | Policy-driven sync | lightnow sync --client <client> --from-settings |
| Client requires native per-server config | Direct sync | lightnow sync --client <client> |
| Client needs one runtime wrapper per server | Runner mode | lightnow sync --client <client> --runner |
| Existing config should seed a profile | Import, then sync | lightnow import-config --client <client> --dry-run |
| Bridge client needs JSON, YAML or a helper | Profile-backed export | lightnow sync --client <bridge-target> |
Do not combine --local-proxy, --from-settings and --runner in one sync
command.
Choose in four steps
If the client already works with MCP servers, preview an import before a managed sync can replace or remove entries.
Keep one LightNow entry in the client and resolve the Runtime Profile when the Proxy starts.
Apply --from-settings after the profile and one representative client have
passed local verification.
Choose direct, runner or bridge output only when the target workflow needs that native shape.
Recommended managed path
lightnow login lightnow import-config --client codex --profile default --dry-run lightnow import-config --client codex --profile default lightnow sync --client codex --profile default --local-proxy lightnow config-status --client codex --json lightnow-proxy --config ~/.lightnow/lightnow-proxy/codex.yaml --health --json
Skip import when the client contains nothing useful to preserve. Restart the AI client after sync so it starts the new LightNow entry.
When to use policy-driven sync
--from-settings asks LightNow Config to choose the default profile, whether
the client is managed and whether unmanaged MCP entries may remain. It is the
right rollout mechanism when the organization, rather than each workstation,
owns those decisions.
lightnow context --tenant acme
lightnow sync --client codex --from-settings
lightnow config-status --client codex --json
If policy blocks unmanaged entries, sync removes them from a managed client's MCP config. Import anything valuable before applying that policy.
Compatibility paths
Direct sync writes client-native server definitions and can materialize
runtime values according to the selected secret mode. Runner mode writes a
lightnow run wrapper per registry-linked profile server. Bridge exports
render the native JSON, YAML or shell helper expected by Windsurf, Continue,
LibreChat or MCP Inspector.
These paths can still use a Runtime Profile as their source, but they do not provide the same one-entry managed-client posture as LightNow Proxy.