Lesson 1

Overview

What a power user understands

  • MCPUP is central-config first
  • `sync` is the real side-effect boundary
  • Different clients have different native formats
  • Secrets belong in env or headers, not in random notes
  • Dry-run is your safety brake

What a power user does not assume

  • Not every arbitrary `--client` name is really supported
  • Not every planned feature is implemented yet
  • Adding or enabling does not push immediately
  • Client configs should not be treated casually

Lesson 2

Golden Rules

The three rules worth memorizing

Rule 1:
Treat ~/.mcpup/config.json as the source of truth.

Rule 2:
Use mp sync --dry-run before real syncs when the change matters.

Rule 3:
Target only the client you mean when you are not sure.

Most common beginner mistake

People think `enable` already changed the client. It did not. It only changed MCPUP's central state. `sync` is separate on purpose.

Lesson 3

Core Workflow

Normal operating path

1. mp add ...
2. mp enable ... --client ...
3. mp list
4. mp sync --dry-run --client ...
5. mp sync --client ...

This is the healthy v0.1 workflow. It is staged, visible, and reversible before the final write step.

Workflow explainer


								

Lesson 4

Command Recipes

Recipe builder


							

Lesson 5

Safety + Secrets

Secret placement

Use `--env KEY=VALUE` for command servers and `--header` for remote HTTP servers. Those values become part of config state, so treat the file as sensitive.

Client safety

Only `sync` touches client files. Use targeted client syncs when you are not fully confident.

Experiment safety

The code supports overriding the central config path through `MCPUP_CONFIG`, which is excellent for isolated experiments.

What not to do

  • Do not assume `add` or `enable` already updated the client
  • Do not sync unknown client names and expect success
  • Do not treat tokens in config files as harmless

Lesson 6

Troubleshooting

Message decoder


							

Lesson 7

Limits + Smart Habits

Current v0.1 limits

  • No update or modify command yet
  • No import-from-existing-config flow
  • No auto-sync
  • No separate codex-desktop registry key
  • Some edge behavior is lightly tested at full system level

Smart habits anyway

  • Use stable, descriptive server names
  • Prefer targeted client syncs while learning
  • Use `mp list` as a cheap sanity check
  • Use dry-run before meaningful syncs
  • Keep secrets handling intentional
Power user mindset:

slow is smooth
smooth is safe
safe syncs are better than fast bad writes

Lesson 8

Practice + Quiz

Operator scenarios

1. You want to test changes without touching your real config. What mechanism helps most?

2. You enabled a server for Cursor but do not want to risk editing anything yet. What next?

3. You typed a client name that is not in the adapter registry. What do you expect on sync?

Quick quiz

Answer the quiz and check your score.

Sources

What This Course Used

  • uv run mp --help
  • uv run mp add --help
  • uv run mp enable --help
  • uv run mp disable --help
  • uv run mp sync --help
  • src/mcpup/cli/*.py
  • src/mcpup/config/*.py
  • src/mcpup/clients/*.py
  • tests/cli/*.py
  • tests/clients/*.py