Plugins, connectors, and tools

Your teammate says Claude Code is “fully set up.” What they mean is: three plugins from a marketplace, two MCP servers pointed at Jira and a shared drive, a personal skill nobody documented, and a settings file that will break the day someone rotates a token. You open a fresh clone. None of that is in the repo. You type a normal task. Claude can still read files, search, run shell commands, and talk to git. Suddenly the plugins look less like oxygen and more like optional spice.

This is Part 7 of Claude Code tutorial. Earlier parts covered install and first run, talking to a codebase, slash commands, skills, memory, and instruction files like CLAUDE.md. Here we map the outer layer: built-in tools, MCP connectors, and plugins that bundle skills, subagents, hooks, and MCP settings into one install. The goal is a clear ladder so you add complexity only when a plain task plus good instructions is not enough.

What you’ll learn

• What Claude Code can do with built-in tools before you install anything
• What MCP is in plain English and when external systems (Jira, Drive, custom servers) earn a seat
• What a plugin bundles: skills, subagents, hooks, MCP settings, and related config
• A complexity ladder: plain task → CLAUDE.md → skill → MCP → plugin
• How to review permissions and avoid turning every repo into a connector zoo
• A small practice plan you can finish without becoming the office plugin catalog

Product surfaces, marketplace names, and install flows move. Treat this as a durable mental model. Verify live details on Claude Code docs, the plugins docs, and Model Context Protocol materials before you write team policy or commit secrets into a shared config.

Three boxes on one map

People mash “tools,” “MCP,” and “plugins” into one foggy word. Separate them and the product gets quieter.

Built-in tools

Out of the box, Claude Code can work inside a project without a marketplace install. Typical built-in capabilities (exact names vary by surface and version) include reading and writing files, searching the tree, running shell commands with permission, and using git-related workflows. That is already a serious agent for software work: explore, edit, test, commit. If your job is “fix the failing test in this repo,” you may never need a plugin.

Think of built-ins as the kitchen tools that ship with the apartment. Knife, cutting board, stove. You can cook dinner. A pasta machine is optional until pasta is your job.

MCP (connectors to systems outside the chat)

MCP means Model Context Protocol. In plain English: a standard way for an AI client to talk to external tools and data sources. A server exposes actions and resources (list tickets, fetch a doc, query a database, call a custom internal API). Claude Code (or another MCP client) connects and can use those tools during a run, subject to your permissions and config.

Common mental examples: Jira or Linear for tickets, Google Drive or similar for docs, a company-built server for your warehouse or deploy system. MCP is not “magic memory of the internet.” It is a pipe you configure. If the pipe is wrong, Claude confidently works with wrong or empty data. If the pipe has broad write access, mistakes travel outside the repo.

Rule of thumb: Use built-in tools for the codebase on disk. Reach for MCP when the system of record lives outside the folder: tickets, docs, cloud APIs, custom ops tools.

Plugins (bundles you install)

A plugin is a packaging unit. Instead of hand-wiring five separate pieces, you install one bundle that can include skills, subagents, hooks, MCP settings, and related commands or configs. Official docs and Anthropic’s plugin ecosystem describe plugins as shareable packages for Claude Code workflows, not as a second IDE.

Plugins answer a team problem: “Everyone keeps reinventing the same skill + MCP + slash command stack.” They also create a new problem: invisible complexity. A plugin can add tools you did not ask for. Treat installs like dependency installs. Prefer known sources, read what lands, and keep a written list of what your team relies on.

What lives inside a plugin (the bundle view)

You do not need to author plugins on day one. You do need to know what you are accepting when someone says “just install this.”

Skills still matter without plugins. Part 4 of this series covered skills as reusable instructions. Plugins are how organizations and marketplaces ship sets of those pieces together. If you only need one skill, a local skill file is often enough. If you need the same five pieces on ten machines, a plugin starts to make sense.

Subagents show up more in multi-step work (Part 8). At map level: a subagent is not a second human. It is a bounded helper with a role. Plugins can ship those roles pre-shaped so you are not inventing them mid-incident.

Built-in tools: win here first

Before you add connectors, stress-test what the agent can already do in a normal project.

• Files: Read, create, edit, and reorganize under your review. Multi-file features live here.
• Search: Find symbols, strings, and patterns across the tree so you are not the lossy clipboard.
• Shell: Run tests, linters, build scripts, and one-off commands with permission dialogs. You still own “approve” or “deny.”
• Git: Inspect status, craft commits, open PR-oriented workflows depending on surface. Destructive git deserves extra caution.

A useful practice: pick a ticket that only needs the repo. No Jira writeback, no Drive upload. Force the session to stay on disk tools. You will learn permissions, diffs, and test loops without also debugging OAuth. Many “we need MCP” requests are really “we never wrote a good CLAUDE.md” or “we keep re-explaining our test command.”

MCP: when the world outside the folder matters

MCP earns its keep when Claude must act on or read systems that are not files in the clone.

Good fits

• Pull ticket acceptance criteria from Jira (or similar) instead of pasting walls of text
• Fetch a design doc or runbook from Drive / wiki that is the real source of truth
• Call a custom internal MCP server your platform team maintains (status, feature flags, safe deploy helpers)
• Query a database through a carefully scoped read-only server (not “root credentials in settings”)

Weak fits (or high risk)

• Write-everything production credentials in a personal config file
• Ten half-configured servers so every prompt pays a context tax for tools you never use
• Using MCP to paper over secrets that should live in a vault and short-lived tokens
• Connecting a system your security policy already banned from AI clients

Anthropic and the MCP community have written about tool definition bloat: too many tools in context burn tokens before the real work starts. Even when tool search and smarter loading improve, the human habit still matters. Connect what you need for the job. Disconnect experiments. Document which servers are “team approved.”

Connectors vs “I pasted the PDF”

Paste is fine for one-off docs. Connectors matter when the content changes under you, when multiple people need the same pipe, or when actions (not only reads) are part of the workflow. If the design doc updates weekly and people keep pasting last Tuesday’s version, MCP or a deliberate fetch habit beats tribal clipboard archaeology.

The complexity ladder (add only when stuck)

Most teams climb too fast. They install a plugin bundle on day one, then spend a week debugging permissions for a task that needed a clearer prompt. Use this ladder in order.

1. Plain task. One goal, constraints, definition of done. Built-in tools only. Example: “Fix the null check in checkout.ts, add a unit test, do not refactor neighbors.”
2. Project instructions (CLAUDE.md and friends). Stable rules: how to run tests, package layout, coding conventions, “never touch /infra.” Part 6 covered this layer. Fix the file before you invent a skill for the same sentence.
3. Skill. A reusable playbook for a job you do often: “cut a release note,” “add a React form the AMS way,” “triage a failing CI job.” Skills beat pasting the same essay every Monday.
4. MCP. When the next bottleneck is external data or actions, not missing prose. Connect the system of record with least privilege.
5. Plugin. When you need to distribute a whole stack (skills + MCP + hooks + agents) across people or machines, or when a maintained marketplace package matches a workflow you actually run.

You can skip rungs when the need is obvious. A platform team shipping a blessed “incident toolkit” plugin is fine. A beginner installing five community plugins before their first green test is usually buying fog.

Worked example: same ticket, five rungs

Ticket: “Users on mobile lose the cart badge count after login. Fix and cover with a test. Link the Jira ticket in the PR.”

Rung 1: plain task

You paste the acceptance criteria once, point at the mobile cart component, and ask Claude Code to reproduce via tests if possible, fix, and open a PR description. Built-in file/search/shell/git tools are enough if you already have the criteria in the chat.

Rung 2: CLAUDE.md

The repo instructions already say: mobile app under apps/mobile, tests via npm test -- cart, PR template lives in .github/PULL_REQUEST_TEMPLATE.md, do not bump native deps without a flag. Claude stops inventing yarn in a npm monorepo. No plugin required.

Rung 3: skill

Your team keeps shipping cart bugs with the same review checklist. You add a skill: “Mobile cart regression.” It forces repro steps, platform notes (iOS/Android), and a short risk note. You invoke it when the ticket smells like cart state. Still no MCP.

Rung 4: MCP

Product insists the source of truth is Jira, and comments change during the day. An MCP server lets Claude read ticket ABC-123 for latest acceptance criteria and post a PR link back (if write is allowed). You scope read carefully, write even more carefully. The fix still happens with built-in tools; MCP handles the ticket system of record.

Rung 5: plugin

Three squads share mobile cart work. Platform packages a plugin: cart skill, Jira MCP settings template, a subagent brief for “UI-only vs state-layer” split, and a hook reminder to run the cart test target. New hires install one thing. The cost is ownership: someone must maintain the plugin when Jira auth or test commands change.

If you are a team of one learning Claude Code, stop at rung 2 or 3 for a while. Climbing to 5 because a blog post looked cool is how settings files become folklore.

Permissions, secrets, and least privilege

Every new tool multiplies blast radius. Built-in shell can already hurt a laptop. MCP can hurt a cloud account. Plugins can enable both at once.

• Prefer read-only MCP scopes until a write is proven necessary.
• Prefer short-lived tokens and org-managed secrets over personal long-lived keys in a dotfile.
• Prefer allowlists of commands and servers for shared machines.
• Prefer explicit approval for network, deploy, and production-adjacent actions.
• Never commit application passwords, API keys, or OAuth refresh tokens into the repo “so the plugin works for everyone.”

If security has a software allowlist, MCP servers and marketplaces count as software. Shadow-installing a community server that can write to production is not a cute hack. It is an incident waiting for a confident agent.

How this fits skills, memory, and instruction files

Parts 4 and 6 taught skills and instruction files. Part 5 covered memory and context. Plugins sit on top of those ideas. They do not replace a good CLAUDE.md. They package habits so more people share them.

When something goes wrong, debug from the bottom. Is the prompt clear? Are project instructions wrong? Is a skill outdated? Is MCP returning stale data? Did a plugin update change hooks? Jumping straight to “plugins are broken” skips the cheaper checks.

Marketplaces and “official” bundles

As of writing, Anthropic maintains documentation for Claude Code plugins and an official-style plugins directory on GitHub for high-quality packages. Community marketplaces also exist. Quality and security vary. For work:

• Prefer org-approved sources
• Read the plugin’s listed skills, MCP servers, and permissions
• Pin or note versions when your process allows it
• Test in a throwaway repo or branch before standardizing a team install

A plugin that “does DevOps” is not automatically safe for your production cloud. Marketing copy is not a threat model.

Common mistakes

Installing the zoo on day one

Five MCP servers, three plugins, two experimental skills. Every prompt is slower, noisier, and harder to debug. Start with zero extras. Add one when a real task blocks without it.

Confusing MCP with “Claude knows our company”

Without a connected source of truth, Claude only has training knowledge plus what you put in context. MCP does not invent a private data warehouse. You wire the warehouse (carefully).

Treating plugins as unreviewed code

Plugins can introduce hooks and tools that run in your environment. Review them the way you would review a new CLI. If you cannot explain what a plugin adds, do not install it on a machine with production credentials.

Encoding secrets in shareable config

Teams love “it just works” onboarding. Attackers love committed tokens. Use environment variables, secret managers, and per-user auth flows. Document setup steps without pasting real keys into the wiki screenshot.

Skipping the ladder because a plugin is fashionable

If the failure mode is “Claude keeps using the wrong package manager,” fix CLAUDE.md. A plugin will not heal a missing one-liner if you never write the one-liner.

Practice for this week

1. Complete one real task using only built-in tools. Write down which tools Claude actually used (files, tests, git).
2. Open your project instruction file. Add one missing operational fact (test command, package manager, “do not touch” paths).
3. If you repeat a multi-step playbook weekly, draft a skill (or improve an existing one). Do not plugin-ize it yet.
4. List external systems you wish Claude could read. Pick at most one. Check policy. If allowed, connect a narrow MCP server and try a read-only task.
5. Only after that: evaluate one plugin or internal bundle. Write three bullets: what it adds, what credentials it needs, who owns updates.

Quick recap

• Built-in tools (files, shell, git, search) already cover most coding work.
• MCP connects external data and tools such as Jira, Drive, or custom servers.
• Plugins bundle skills, subagents, hooks, MCP settings, and related config for distribution.
• Climb the ladder: plain task → CLAUDE.md → skill → MCP → plugin. Stop when the job is unblocked.
• Least privilege and secret hygiene matter more as you leave the repo boundary.

Next in this series: Part 8, loops and agentic runs. Multi-step work is where tools and plugins meet the goal-plan-act-observe loop, usage burn, subagents, and how much autonomy you should grant on a Tuesday afternoon.

Sources

Research and further reading used for this article:

• Claude Code documentation: Overview (product surfaces and baseline capabilities)
• Claude Code documentation: Plugins (plugin packaging model and install concepts)
• GitHub: anthropics/claude-plugins-official (Anthropic-managed plugin directory reference)
• Model Context Protocol (open standard for connecting models to tools and data)
• Anthropic: Introducing the Model Context Protocol (MCP announcement context)
• Anthropic engineering: Code execution with MCP (tool definition and result token costs)
• Anthropic engineering: Advanced tool use (tool search, large tool libraries, agent patterns)
• Anthropic: Building effective agents (agent design principles behind multi-step tool use)
• Claude Code product page (positioning and access paths; verify plans live)
• Analytics Made Simple: Claude product map (where Code sits next to chat and Cowork)

Merch on Etsy

Open store →

You're On Mute White Ceramic Coffee Mug, Data Science Mug, Data Mug, Analytics Mug, Statistics Mug, Programming Mug, Gift Mug, Coffee Mug View on Etsy → You're On Mute White Ceramic Coffee Mug, Data Science Mug, Data Mug, Analytics Mug, Statistics Mug, Programming Mug, Gift Mug, Coffee Mug View on Etsy → You're On Mute White Ceramic Coffee Mug, Data Science Mug, Data Mug, Analytics Mug, Statistics Mug, Programming Mug, Gift Mug, Coffee Mug View on Etsy → Imbalanced Classes Mouse Pad, Data Science Mouse Pad, Analytics Mouse Pad, Imbalanced Mouse Pad View on Etsy →