Connecting Claude to your tools — connector vs CLI vs MCP vs skill

GitHub · GitLab · Bitbucket · Jira · Slack · Sentry · Datadog · Stripe · Xero · Figma · Cloudflare · MySQL

Colour key: Connector / remote MCP CLI Local MCP Skill Split

TL;DR

• Order of preference: official remote connector (OAuth) → CLI inside Claude Code → local MCP server for the leftovers (usually databases and desktop apps).
• That order is sorted by reach, not power: a connector works on web, mobile, desktop and CLI; a CLI only works where there's a shell; a local stdio MCP only works on the machine it's installed on.
• One exception: for engineering work inside Claude Code, a mature CLI beats the connector — gh, glab, wrangler and stripe reach the whole API, cost nothing in context, and survive unattended runs where OAuth doesn't.
• A skill is not a fourth option — it's the workflow wrapper around whichever transport you picked. A connector is just hosted MCP with the OAuth done for you.
• Verdict: connector-first as the portability default, CLI-first inside Claude Code, local MCP only for what neither covers — and a deliberately narrow tool surface for anything that moves money or mutates production.

---

1. The layer mistake

Asking "skill or CLI or MCP or connector?" reads like a four-way fork. It isn't:

  Workflow layer   SKILL                      "how we raise a ticket here"
                     |
  Transport layer  CONNECTOR | CLI | MCP      "how Claude reaches the service"
                     |
  Service          GitHub, Jira, Sentry, Stripe, Figma, ...

Two consequences:

• A skill is never an alternative to MCP. A skill is a markdown file of instructions that fires on a trigger phrase. It has no network access of its own — it tells Claude to run gh pr create, or to call the Jira MCP tool. The choice is what the skill calls.
• A connector is not an alternative to MCP either. A connector is a remote MCP server, hosted by the vendor or by Anthropic, with OAuth handled for you. The difference is who runs it and where it works, not the protocol.

---

2. Order of preference

#	Approach	Use it when	Code (local)	Code (cloud / sched.)	Desktop	Web	Mobile
1	Official remote connector (OAuth)	The vendor ships one and it covers the job	✅	⚠️	✅	✅	✅
2	Self-registered remote MCP (HTTP/SSE)	No official connector, but the vendor exposes an endpoint	✅	⚠️	✅	⚠️	⚠️
3	CLI inside Claude Code	A mature, already-authenticated binary exists — gh, glab, stripe, wrangler, mysql	✅	✅	❌	❌	❌
4	Local MCP server (stdio)	Nothing above covers it — databases, browser automation, desktop apps	✅	❌	✅	❌	❌

✅ works · ⚠️ conditional, see below · ❌ not available

The ranking is the ✅ count. That's the entire argument: the order is sorted by reach, because reach is a precondition rather than a factor you trade off. Tiers 1–2 are one tier in practice — both are remote MCP over OAuth, differing only in whether you clicked Connect or edited a config file.

Inside Claude Code doing depth work, tier 3 beats tier 1. A CLI has the highest capability ceiling and the lowest context cost; it just can't leave the shell.

What the ⚠️ cells mean:

Cell	Condition
Connector / remote MCP on cloud or scheduled runs	Works while the OAuth token is valid. When it lapses the run fails and wants a human — which is why unattended work should prefer a CLI with a long-lived token
Self-registered remote MCP on web / mobile	Depends on whether your org has configured that server for those surfaces; a one-click official connector has no such gap

The rule that falls out of the table: a CLI and a local stdio MCP are machine-bound. If the same job ever needs doing from your phone, or from a scheduled cloud run, only tiers 1–2 will be there.

Skill — deliberately not in the ranking

A skill is not a transport and doesn't belong in a preference order against them. It's the workflow layer above, and it inherits the reach of whatever it calls:

	Code (local)	Code (cloud / sched.)	Desktop	Web	Mobile
Skill	✅	✅	⚠️	✅	⚠️

⚠️ Desktop: skills run in an isolated sandbox VM, not on your Mac — no host shell, no keychain, allowlisted egress. A skill that shells out to gh with your local auth will not work there. ⚠️ Mobile: the skill loads, but anything it shells out to won't.

---

3. Remote MCP vs connector — same protocol, different paperwork

A connector is a remote MCP server. The difference is who registers it and where it shows up.

	Self-registered remote MCP	Connector
What it is	A remote MCP server you point your client at	The same thing, surfaced in the Claude UI with managed OAuth
Who sets it up	You, per client and per scope	You click Connect — or an admin enables it org-wide
Where the config lives	.mcp.json, claude mcp add, Desktop settings	Nothing on disk — it's attached to your account
Auth	You supply a header/token, or run the OAuth flow yourself	Managed OAuth, refresh handled for you
Reach	Only the clients you registered it in	Every surface you sign into, including mobile
Vetting	None — you're trusting a URL	Listed in the connectors directory
Revoking	Remove it from each client	One place, dies everywhere at once
Examples	A GitHub MCP endpoint you added yourself; a vendor /mcp URL not yet in the directory; your company's internal server	Google Drive, Slack, Xero, Stripe, Sentry, Linear, Atlassian

The tell that they're the same thing: Claude Desktop's Connectors settings has an Add custom connector box that takes a URL. That is self-registering a remote MCP server, through the connector UI.

When the distinction actually matters: reach and maintenance, nothing else. If the vendor is in the directory, connecting is strictly less work and gets you mobile. If it isn't, self-register — identical tools, fewer places.

Configuring a connector

No file, no command:

1. claude.ai → Settings → Connectors (or Claude Desktop → Settings → Connectors)
2. Browse the directory → Connect → OAuth consent → done
3. Org-wide: an admin enables it in the admin console so nobody connects individually
4. Custom/undirectoried server: Add custom connector → paste the remote MCP URL

Configuring a self-registered remote MCP

# OAuth server — register it, then run /mcp in-session to authenticate
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp
claude mcp add --transport http slack  https://mcp.slack.com/mcp

# Static-token server — pass the header at registration time
claude mcp add --transport http datadog https://<datadog-mcp-endpoint> \
  --header "Authorization: Bearer $DD_API_TOKEN"

# Who gets to see it
claude mcp add --transport http --scope user    linear https://mcp.linear.app/mcp
claude mcp add --transport http --scope project jira   https://<atlassian-endpoint>

--scope is the whole reason "MCP is registered per project" bites:

Scope	Stored in	Who sees it
local (default)	your user settings, keyed to this project	just you, just here
project	.mcp.json in the repo	anyone who checks out the repo
user	your user settings	you, in every project

Equivalent .mcp.json:

{
  "mcpServers": {
    "sentry": { "type": "http", "url": "https://mcp.sentry.dev/mcp" }
  }
}

Take the current URL from the vendor's docs rather than from this table.

---

4. Local MCP vs remote MCP — the config difference

	Local (stdio)	Remote (HTTP / SSE)
How Claude talks to it	Spawns a subprocess, stdin/stdout	HTTPS to a URL
Config keys	command, args, env	type, url, optional headers
Auth	Env vars in the config file	OAuth flow, or an Authorization header
Where secrets sit	Plain text on your disk	At the vendor, or in one header
Prerequisites	Node / Python / Docker installed	None
Who updates it	You — bump the package	The vendor deploys
Typical failure	Process crash, wrong runtime, PATH	Token expiry, network, rate limit
Works from web / mobile	❌	✅
Can reach localhost / your LAN	✅	❌

That last row is why local MCP still exists at all: a dev MySQL on 127.0.0.1, or the Figma desktop app on localhost:3845, is not reachable from a vendor's cloud. No amount of preferring remote will fix that — it's a network fact, not a taste.

Local (stdio) — a deliberately read-only MySQL:

{
  "mcpServers": {
    "mysql": {
      "command": "npx",
      "args": ["-y", "@benborla29/mcp-server-mysql"],
      "env": {
        "MYSQL_HOST": "127.0.0.1",
        "MYSQL_PORT": "3306",
        "MYSQL_USER": "readonly",
        "MYSQL_PASS": "...",
        "MYSQL_DB": "app",
        "ALLOW_INSERT_OPERATION": "false",
        "ALLOW_UPDATE_OPERATION": "false",
        "ALLOW_DELETE_OPERATION": "false"
      }
    }
  }
}

Same server from the CLI — note the -- separating Claude's flags from the command:

claude mcp add mysql \
  --env MYSQL_HOST=127.0.0.1 --env MYSQL_USER=readonly --env MYSQL_DB=app \
  -- npx -y @benborla29/mcp-server-mysql

Remote (HTTP) — same file, different keys:

{
  "mcpServers": {
    "sentry": { "type": "http", "url": "https://mcp.sentry.dev/mcp" }
  }
}

Side by side the entire difference is command + env versus url + headers. How tools are listed, called and permissioned is identical — that is the point of having a protocol.

Checking what you've actually got:

claude mcp list          # every registered server, with its scope
claude mcp get sentry    # one server's resolved config

/mcp inside a session shows live connection status and runs the OAuth flow for servers that need it — which is where an expired connector token surfaces.

---

5. Service directory — what exists, and what to pick

Service	Vendor remote MCP	In connector directory	CLI	Best default	Why
GitHub	✅	✅	✅ gh	CLI	gh api reaches all of REST + GraphQL; connector for non-shell clients
GitLab	✅	⚠️	✅ glab	CLI	Same shape as GitHub — glab is the first-party equivalent
Bitbucket	✅	✅	⚠️ weak	Remote MCP	No gh equivalent; plain git plus REST v2 via curl is the fallback
Jira / Confluence	✅	✅	⚠️ acli	Remote MCP	REST wants ADF JSON for rich text — miserable to hand-build
Slack	✅	✅	⚠️ slack	Connector	Search and threads are per-user OAuth; the official slack CLI builds and deploys Slack apps, it doesn't read or post messages
Sentry	✅	✅	✅ sentry-cli	Split	MCP for triage; sentry-cli for releases and sourcemaps in CI
Datadog	✅	⚠️	⚠️ datadog-ci	Remote MCP	Metric/log queries are a tagged DSL; CLI is CI-scoped only
Stripe	✅	✅	✅ stripe	Split	CLI for listen/trigger/fixtures; MCP for read-only questions
Xero	⚠️ local only	✅	❌	Connector	The official server is a local stdio package; the connector is the portable route
Figma	⚠️ local only	❌	❌	Local MCP	Dev Mode MCP talks to the desktop app on localhost — machine-bound despite being official
Cloudflare	✅	⚠️	✅ wrangler	Split	wrangler deploys and tails; MCP for docs and observability
MySQL / Postgres	❌	❌	✅ mysql, psql	Local MCP (prod), CLI (local)	Nobody hosts a remote MCP to your database
Google Drive / Sheets	✅	✅	❌	Connector	Per-user OAuth, no credible CLI
Browser automation	❌	❌	❌	Local MCP	Playwright holds a stateful session across calls

Vendor remote MCP is a durable fact — does the vendor host an endpoint you can point a client at. In connector directory is a snapshot as of 2026-09: the directory changes, and an admin can gate what your org sees. Verify the second column before relying on it; the first rarely moves.

The two ⚠️ local only rows are the ones worth noticing — Xero and Figma both ship official MCP servers that run on your machine. "Official" says nothing about transport.

Three patterns worth internalising:

• The three git forges split two ways. GitHub and GitLab ship real CLIs, so they're CLI-first. Bitbucket doesn't, so it falls back to Atlassian's remote MCP — same tier as Jira, often the same server.
• "Split" is a legitimate answer. Sentry, Stripe and Cloudflare each have a good CLI and a good remote MCP doing different jobs: the CLI writes and deploys, the MCP reads and explains. Use both deliberately, not interchangeably.
• Money and production get a narrower surface than everything else. Stripe and Xero move real value; a prod database can lose it. Prefer the transport you can scope down — restricted keys, test mode, a read-only tool set — over the one with the highest ceiling.

---

6. What to collect, and how — by client

Pick the row for what you need, then the column for where you're asking from.

What you need	Claude Code (local)	Claude Code (cloud / scheduled)	Claude Desktop	claude.ai web	Mobile
GitHub — PRs, issues, reviews, CI logs	gh CLI	gh CLI + PAT	Connector	Connector	Connector
GitHub — bulk / unusual API work	gh api	gh api	❌	❌	❌
GitLab — MRs, pipelines, issues	glab CLI	glab + token	Remote MCP	Remote MCP	⚠️
Bitbucket — PRs, pipelines	Atlassian MCP	⚠️ REST + app password	Atlassian MCP	Connector	Connector
Jira — read, comment, transition	Atlassian MCP	Atlassian MCP (token permitting)	Atlassian MCP	Connector	Connector
Jira — bulk create / scripted fields	acli or REST via curl	acli	❌	❌	❌
Slack — search, read threads, summarise a channel	Slack MCP	⚠️ token permitting	Connector	Connector	Connector
Slack — post a notification from a job	Incoming webhook via curl	Incoming webhook via curl	Connector (posts as you)	Connector (posts as you)	Connector (posts as you)
Sentry — triage an issue, stack trace	Sentry MCP	Sentry MCP	Sentry MCP	Connector	Connector
Sentry — releases, sourcemaps	sentry-cli	sentry-cli	❌	❌	❌
Datadog — metrics, logs, monitors	Datadog MCP	MCP or REST + API/APP keys	Datadog MCP	Connector	Connector
Datadog — CI reporting	datadog-ci	datadog-ci	❌	❌	❌
Stripe — read payments, customers	Stripe MCP (restricted key)	MCP or REST	Stripe MCP	Connector	Connector
Stripe — webhooks, fixtures, log tail	stripe CLI	stripe CLI	❌	❌	❌
Xero — invoices, contacts, reports	Connector	❌ re-auth needs a human	Connector	Connector	Connector
Figma — read a frame, extract tokens	Dev Mode MCP (app running)	❌	Dev Mode MCP	⚠️	❌
Cloudflare — deploy, KV/R2/D1, tail	wrangler	wrangler + API token	❌	❌	❌
Cloudflare — docs, analytics, observability	Cloudflare MCP	Cloudflare MCP	Cloudflare MCP	Connector	Connector
MySQL — query prod	Local MCP, read-only user	⚠️ needs reachable MCP or tunnel	Local MCP	❌	❌
MySQL — local dev database	mysql -e	n/a	Local MCP	❌	❌
Google Drive / Sheets	Connector	⚠️ token permitting	Connector	Connector	Connector
Browser automation	Playwright MCP	⚠️ headless in a sandbox	Playwright MCP	❌	❌
Your own repeatable workflow	Skill → CLI	Skill → CLI	Skill → connector only	Skill → connector	⚠️

Two patterns to notice:

• The left two columns are CLI country; the right three are connector country. Anything you want to work in all five needs a connector, full stop.
• Depth lives on the left. Every deploy, bulk, fixture and sourcemap row is ❌ outside a shell. If a job needs the full API or writes to infrastructure, it's a Claude Code job by definition.

---

7. Scorecard

Scores 1–5, higher is better. Skill is scored separately because it sits on a different layer.

Factor	Connector / remote MCP	CLI	Local MCP (stdio)
Setup cost	5 — click to authorise	4 — usually already installed	2 — config, token, restart
Client reach	5 — every surface	2 — shell only	1 — one machine
Context / token cost	3 — tool schemas, mitigated by deferred loading	5 — nothing until called	3
Capability ceiling	2 — vendor decides	5 — escape hatches reach the whole API	3 — what the server exposes
Determinism / reproducibility	2	5 — the command is the record	3
Auth durability	2 — OAuth re-auth is a recurring chore	4 — tokens expire quietly	4
Guardrails / least privilege	5 — vendor-scoped	2 — a shell is a shell	5 — read-only tool surfaces
Works headless (cron, claude -p)	2	5	3
Discoverability for the model	5 — typed, self-describing	2 — Claude must know the flags	5
Total (of 45)	31	34	29

The CLI wins on points and still ranks third in the preference order — because reach is a precondition, not a factor. A 34/45 you can't call from your phone scores zero there.

---

8. How to choose, in order

1. Is there an official remote connector that covers the job? → use it. It works in every client and someone else maintains the auth.
2. Will this ever need to run from web, mobile, or an unattended cloud job? → stay in tier 1–2. A CLI or local MCP simply won't be there.
3. Are you in Claude Code, doing depth work — deploys, bulk edits, unusual API calls, anything piped into jq? → CLI. This is the exception that outranks the connector.
4. Does it need to run unattended on a schedule? → CLI with a long-lived token. OAuth wants a human when it lapses.
5. Does it move money or mutate production? → whichever transport you can scope down hardest: restricted keys, test mode, a read-only tool set. Ceiling is not the goal here.
6. Is there no connector and no CLI? → local MCP. Databases, browser automation, Figma.
7. Is the workflow repeatable and opinionated? → write a skill over whichever of the above you landed on.

---

9. Pros and cons

Connector / remote MCP

Pros	Cons
Authorise once, works on every surface	Re-auth is a recurring interruption
No local process, no token file	Lowest capability ceiling — vendor decides
Typed, self-describing tools	Poor fit for unattended runs
Vendor-scoped permissions	You're waiting on the vendor for new capability

CLI

Pros	Cons
Nothing loaded until used	Claude has to know or discover the flags
Full API reach via escape hatches (gh api)	No guardrails — a shell can do anything
Composable: pipes, jq, redirect to a file	Credentials can land in shell history
Same command works in cron, CI, claude -p	Output parsing is brittle unless you ask for JSON
The command is a reproducible record	Only exists where there's a shell

Local MCP (stdio)

Pros	Cons
Can be deliberately narrow (read-only DB)	Machine-bound — absent everywhere else
Stateful where it matters (browser sessions)	Registration and token config per server
Structured results, not text to parse	Scope confusion: registered per project, missing elsewhere
Works with no vendor cooperation at all	Another process to keep running and updated

Skill

Pros	Cons
Encodes your conventions, not the tool's defaults	Only as good as the transport underneath
Loads on trigger, so it costs nothing idle	Drifts silently when the underlying CLI/API changes
Bundles scripts, so complex work is one call	Over-abstracts a job that was one command
Portable — a markdown file, versioned in git	A skill that shells out won't work in sandboxed clients

Write a skill when the workflow has conventions a fresh session wouldn't guess: which branch to base on, which sprint to file into, which checks to run before pushing. Don't write one for "run this one command".

---

10. Gotchas worth knowing before you commit

Gotcha	Detail
MCP scope is per-project	A server registered for one repo simply isn't there in another. Check first; don't let the model guess at ticket text or schema because the tool is missing.
Blank credentials read as working	An empty API key often still passes reads and fails only on write. A successful GET is not proof auth is configured.
Tool schemas cost context	Clients now defer MCP tool schemas and load them on demand, which takes most of the sting out — but a dozen always-on servers is still a tax that a CLI never charges.
OAuth expiry breaks automation	Connectors are the wrong transport for anything on a cron. Give scheduled work a CLI and a long-lived token. Xero is the usual offender.
Sandboxed clients have no host shell	A skill running in Claude Desktop gets a fresh Linux VM: no keychain, no gh auth, allowlisted egress. Anything credential-dependent needs a key file and an egress allowance.
"Official" doesn't mean "remote"	Figma's Dev Mode MCP is first-party and still machine-bound — it talks to the desktop app on localhost. Check the transport, not the badge.
Payment tools need test mode by default	Point Stripe at test keys and restricted API keys unless the task is explicitly live. The model cannot tell a live charge from a test one by looking at the tool.
Permissions differ in kind	CLI access is allowlisted by command pattern; MCP by tool name. Command patterns are easy to under-specify — gh * is not a narrow grant.
Slack needs an admin, and posts as you	The Slack MCP only works once a workspace admin has approved the integration. Messages it sends go out under your name — for bot-style alerts from CI or cron, use an incoming webhook instead.
Claude in Slack is the other direction	Mentioning @Claude inside Slack is Slack calling Claude, not Claude reaching Slack. It doesn't give your Claude Code or claude.ai sessions any Slack access.
Two paths to the same service drift	If both gh and a GitHub connector are available, pick one per workflow so behaviour doesn't change session to session.

---

11. A sane default stack

Service	Choice	Tier
GitHub	gh CLI in Claude Code; connector elsewhere	3, with 1 as fallback
GitLab	glab CLI in Claude Code; remote MCP elsewhere	3, with 1–2 as fallback
Bitbucket	Atlassian remote MCP	1–2
Jira / Confluence	Atlassian remote MCP, scoped to the repos that need it	1–2
Slack	Connector for search and replies; incoming webhook for automated alerts	1 + 3
Sentry	MCP for triage, sentry-cli in CI	1–2 + 3
Datadog	Datadog MCP	1–2
Stripe	stripe CLI in dev (test keys), MCP for read-only questions	3 + 1–2
Xero	Connector — never on a schedule	1
Cloudflare	wrangler for deploy and ops, MCP for docs and observability	3 + 1–2
Google Drive / Sheets	Connector	1
MySQL	Local MCP, read-only against prod; mysql CLI locally	4
Figma	Dev Mode MCP, desktop app running	4
Browser automation	Playwright MCP, headless first	4
Repeatable workflows	Skills calling the above — one per workflow, not one per service	—

Ask where else this needs to work. If the answer includes a phone or a scheduled cloud run, and you built it on a CLI or a local MCP, it isn't built yet.

---

Sources

• Model Context Protocol
• Claude Code — MCP
• Claude Code — Skills
• Claude connectors directory
• GitHub CLI manual
• GitHub MCP Server
• GitLab CLI (glab)
• Atlassian Remote MCP Server
• Atlassian Document Format
• Slack MCP Server — Connect to Claude
• Guide to MCP in Slack
• Slack incoming webhooks
• Sentry MCP
• sentry-cli
• Datadog MCP Server
• Stripe MCP / Agent Toolkit
• Stripe CLI
• Xero MCP Server
• Figma Dev Mode MCP Server
• Cloudflare MCP Servers
• Cloudflare Wrangler