Setup MCP

Connect Claude to your tools without being a developer. This skill maps your stack to concrete MCP servers, then hands you the config block to paste in and the steps to check it works.

Hold one distinction throughout: a Skill is the method, an MCP server is the connection. setup-claude-md gives Claude the context; this one gives it hands. A server without a method is an access with no procedure; a method without a server is a procedure with no data. You want both.

When to use

• You prompt Claude well but keep copy-pasting between it and your tools (PostHog, Notion, Gmail, Slack, GitHub).
• You want Claude to read your data or act in your tools, and don't know which servers to install or how.
• You installed one server, it half-worked, and you want a clean, safe setup instead.

For the concepts behind MCP, point the user to Les serveurs MCP : connecter Claude à tes outils (foundations) and, for a PM angle, MCP pour PM.

Input

An optional argument naming the priority tool or use case (e.g. notion, reporting hebdo). If none is given, ask in Phase 1.

Workflow

Phase 1 — Diagnose

Ask 3 to 4 short questions. Batch them into one message. Propose a likely answer so the user reacts instead of staring at a blank page.

1. Where do your data live? Notion, Gmail, Google Drive/Sheets, Slack, GitHub, Jira/Confluence, HubSpot, a SQL database, a website to scrape?
2. What is the one task you'd automate first? The weekly report, prepping a PRD from the backlog, drafting emails, a competitive audit, research for the newsletter.
3. Read or act? Should Claude only read (safe), or also write (post, create, modify)? This decides the access risk you accept.
4. Solo or team? A shared repo config (.mcp.json, committed) or a personal setup (Claude Desktop, uncommitted)?

Stop here and wait for the answers. Do not recommend before you know the stack.

Phase 2 — Recommend (max 3 to start)

Map needs to servers. Recommend at most 3: one to read, one to act, one extra only if the priority task needs it. More than that and nothing gets used. Reuse the server logic from the MCP article.

For each recommended server, give three things: what it's for, the install effort (1-3), and the access risk.

Server	For	Effort	Access risk
PostHog	Analytics: pageviews, funnels, flags	2	Read-only, low
Notion	Search your workspace, notes, wikis	2	Read (write optional), low/medium
Gmail	Read mail, draft replies, search inbox	2	Drafts by default; writes if you allow
Google Sheets/Drive	Read/write spreadsheets and docs	2	Read/write, medium
Google Calendar	See events, find slots, create meetings	2	Write can book on your behalf
Slack	Read channels, post messages, summarize	2	Write can post as you, medium
GitHub	Issues, PRs, reviews	2	Write can change your repo, medium
Atlassian (Jira/Confluence)	Backlog and docs	2	Read (write optional), medium
HubSpot	Deals, contacts, tickets	3	CRM data, sensitive
Firecrawl	Scrape any web page in full	1	Read of public web, low
Brave Search	Real-time web search	1	Read of public web, low
Figma	Dev Mode: read a design, generate code	2	Read, low

Prefer official servers (Anthropic or the tool's own vendor) over community ones. Recommend the user start read-only, then open writes once they trust what Claude reads.

Phase 3 — Security checklist

This is where non-tech users get burned. Run this before connecting anything, and keep it short:

• Minimal scopes. Grant the least the task needs. Reporting only reads? Read-only token. Don't hand write access "just in case".
• Official over found. A connector from the vendor's own directory is a different level of trust than an address off a forum. What's in the directory gets a continuing review; treat the rest as untrusted.
• Local vs remote. Most servers run locally, so your data stays on your machine. A remote server can change behavior after you approved it: your trust decision from day one no longer holds.
• Sensitive data. CRM, email, HR: assume Claude can read everything the token can. If a scope is too broad, narrow it or skip that server.
• Keep confirmation on. Claude shows what it's about to do and waits for your go before it posts, creates, or modifies. Don't disable that.
• Know how to revoke. Before connecting, find where you kill the token (the tool's settings or API keys page). If anything feels off, you revoke, not debug.

Phase 4 — Config and verification

Produce two things.

1. The config block, ready to paste. Pick the format from Phase 1's "solo or team":

• Claude Code, shared with the repo → .mcp.json at the project root (committed).
• Claude Code, personal → claude mcp add on the command line, or the user file.
• Claude Desktop → claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/).

All three use the same shape. Example for two servers (read + act), with secrets left as placeholders:

{
  "mcpServers": {
    "notion": {
      "command": "npx",
      "args": ["-y", "@notionhq/notion-mcp-server"],
      "env": { "NOTION_TOKEN": "<ton-token>" }
    },
    "slack": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-slack"],
      "env": { "SLACK_BOT_TOKEN": "<ton-token>" }
    }
  }
}

Never paste a real key into a committed file: use an environment variable or the placeholder, and tell the user where the real token goes. The exact package name and the token page live in each server's official doc, linked from the catalogue MCP — send the user there rather than guessing a package name.

2. Verification steps ("ça marche").

1. Save the file, then fully restart Claude Code (or quit and reopen Claude Desktop). Servers load at startup.
2. Run /mcp (Claude Code) or check the tools menu (Desktop): the server should be listed and connected, not errored.
3. Ask one real read question, e.g. "Notion : trouve la dernière décision sur le pricing." A right answer means the connection works.
4. Only then test a write, and check Claude asks for confirmation before it acts.
5. If it errors: 90% of the time it's a wrong token, a missing scope, or Claude wasn't restarted. Check those three first.

The last step: pair it with a Skill

A connected server is an access, not a workflow. Once the servers work, tell the user the real unlock is combining them with a method: a reporting-hebdo Skill that reads PostHog, formats the numbers, and posts to Slack in one command. Point them to skill-create. Skill = the method, MCP = the connection.

Rules

• Write the recommendations and config comments in the user's language; keep this skill's own instructions in English.
• Recommend 3 servers max to start. A list of 12 is a catalog, not a setup.
• Never invent a package name or a token. Send the user to the official doc via the catalogue MCP.
• Never write a real API key into a committed file. Placeholder or env var only.
• Default the user to read-only first. Writes come after trust, not before.
• Stop and ask when the call is the user's (which tools, read vs write, solo vs team). Do not guess.