Connector, MCP or CLI?

Four questions before you connect anything

Brands change their terms all the time, so ask these of any connector, MCP or CLI, whatever the logo.

• Can it read? What exactly: one calendar or all of them, one folder or the whole drive?
• Can it write? Reading your calendar and creating events on it are different powers. Grant the smaller one until the bigger one earns its place.
• Where does the raw data land? On the vendor's side, in your chat, in a file in your folder? Raw data never goes into git.
• Where is the off switch? Know the exact step that removes it before you add it. If you can't name the off switch, don't add it.

One more sits inside all four: what can the vendor see through it, and what does it keep? A small scope is the design, not caution for its own sake.

Is it really working?

"It's available" hides six different facts. Your agent checks each one and says which it confirmed, which it did not check, and which do not apply.

• Known. It exists, in the docs or in your app's list.
• Installed. It is actually on this computer, or added to this app.
• Reachable. This session can reach it right now.
• Signed in. There is a current sign-in or key for this exact account.
• Permitted. That account has the scope this job needs.
• Tested. One small, harmless call came back with a result you looked at.

The order to try things

Five branches from Tyler Fisk's CLI method, checked in this order. Stop at the first one that fits.

• 1. A native connector or an MCP covers it. Use it. Turn it on. Write skills on top later if you want.
• 2. Someone shipped a good CLI. Borrow it. The vault has four: n8n CLI Toolkit, Slack CLI Toolkit, Zoom Automation Hub and gws CLI Connect.
• 3. The MCP covers most of it. Build a thin CLI for the gap. Wrap only the one or two missing operations and keep the MCP for the rest. A patch, not a replacement.
• 4. Nothing exists, or you need several accounts. Build one. That is part 2, Build Your Own CLI.
• 5. It's rare or low value. Skip it. Once a month, docs locked away, or a person does it in 90 seconds. Leave it manual and look again in three months.

Four signals pick the branch:

• Capability gap. A real task you tried and the connector could not do. A limit you worry about doesn't count.
• Multiple accounts. A connector added once holds one account. Keeping two accounts means adding it twice under two names, which gets clumsy fast. Personal and work, two workspaces, a client's: that is structural, and better skills on top won't fix it. A CLI picks the account per command.
• Who owns the sign-in. If the vendor's connector handles a hard sign-in for you, the bar for replacing it goes up.
• How often you do it. Daily work repays a build. A once-a-month task does not.

And on anything that writes, ask whose name goes on it. A connector usually acts as whoever connected it, so every post looks like you wrote it. For work that runs while you are not watching, you want a named bot, not you.

Good reasons to build a CLI

If you do end up building, these are the reasons that hold:

• Control. Every operation the service's API has, not the subset the vendor chose.
• Several accounts. The account is picked per command.
• Scripting. A CLI runs in a script or on a schedule, and what it prints can feed straight into the next command.
• Repeatability. The same command gives the same result every time.
• Cost. A script or a schedule runs it with no model in the loop, so routine runs use no tokens.
• Owning the sign-in. Your key, kept in Infisical, that you can rotate or revoke. A run with nobody watching can't finish a connector's browser sign-in.

What happens in the half hour

Seven checkpoints. Here is what goes by.

• It copies the folder to work/decide-connector-mcp-cli/. Nothing runs inside lab/.
• You name one tool and three real tasks you do there, each marked read or write, plus how many accounts and how often.
• It checks what exists: a connector already in your app, one in the app's directory, the vendor's own MCP, a vault CLI, a published CLI. Read only.
• You answer the four questions and it checks the six states together with you.
• You walk the five branches with the four signals, and stop at the first that fits.
• It writes decision.md with the branch, the evidence, the exact gap and the next card, and shows it to you.
• It acts on the branch. Branch 1: it helps you add the connector and runs one read-only call. Branch 2: it links the vault CLI. Branch 3 or 4: it points you to Build Your Own CLI. Branch 5: it stops.

claude mcp list
# Claude Code: what is already connected
codex mcp list
# Codex: the same
claude mcp add --transport http <name> <url>
# Claude Code: adds the vendor's MCP, on your yes
codex mcp add <name> --url <url>
# Codex: the same
/mcp
# inside a Claude Code session: you finish the sign-in
codex mcp login <name>
# Codex: you finish the sign-in

What you can ask your agent

Five asks that work any time, for any tool.

Words you now own

• MCP server. A standard way for your agent to use another service's tools. Some run on your computer; most big ones run on the vendor's side at a web address.
• Connector. What Claude calls an MCP server you add in its settings. A native connector is one the app maker lists in its own directory.
• CLI. A tool you run by typing commands. Your agent runs it in the terminal and reads what it prints.
• Capability states. Known, installed, reachable, signed in, permitted, tested. Six facts that "available" hides.
• Capability gap. A specific task you tried that the connector could not do. Not a worry about one.
• Thin CLI. A small CLI that covers only what the MCP is missing, next to the MCP, not instead of it.
• Scope. What a sign-in is allowed to do: read only, or read and write, and on what.
• Named bot. A separate account for your automation, so what it posts or sends carries its name, not yours.
• Off switch. The exact step that removes a connection. Known before you add it.

Before you install anything

An MCP acts inside your account, with your sign-in. Choose which one with that in mind.

• Never install a random MCP. A list of "the best MCPs", a post, a search result: none of these is a reason. Check who publishes it.
• Prefer the vendor's own, or a native connector from your app's directory. For Claude, the Anthropic Directory at claude.ai/directory lists reviewed connectors.
• Watch anything that reads outside content. An MCP that pulls in web pages, an inbox or an issue tracker can carry text written to steer your agent. Keep its write scope small.
• Start read-only. The first call reads. Writing comes later, on purpose.
• It changes your app's settings, outside the folder. Your agent says so first and waits for your yes.

Fair questions