How to Use MCP Servers With Claude Code

Why Claude Code Needs MCP — and Why Most Teams Hesitate

Every developer who has pasted a Linear issue link into Claude Code and watched it complete the ticket knows the pull: the agent suddenly works with your real tools, not just your real files. That's MCP in action — Claude Code is an MCP client, a CLI for agentic coding that connects to servers exposing tools, resources, and prompts over JSON-RPC. Teams use it to commit, push, and create merge requests in a single command, or to cross-reference observability data with recent code changes.

The workflows are compelling, and the ecosystem behind them is enormous. There are now more than 10,000 active public MCP servers and 97 million monthly SDK downloads, and first-party support spans Anthropic, OpenAI, Google, Microsoft, GitHub, and Cursor. Yet the median user isn't tapping that long tail — most teams connect to their own company's data warehouse, and only about ten public servers see heavy use.

So what's holding everyone else back? Security is the #1 adoption barrier, and the numbers back it up. In one survey, 38% of technical professionals said security and compliance concerns prevent increased MCP use, while 50% of server builders named security and access control complexity their biggest challenge. Authentication practices are uneven at best: 40% of servers rely on API keys, and 24% use no authentication at all.

The threat landscape isn't theoretical, either:

• CVE-2025-49596 (CVSS 9.4): unauthenticated MCP Inspector instances exploitable for arbitrary command execution
• CVE-2025-6514: OS command injection in mcp-remote, a package with 437,000+ downloads, enabling remote code execution and credential theft
• 492 publicly exposed MCP servers found running without basic authentication or encryption
• Tool poisoning and "rug pull" attacks, where a server's behavior changes after permissions are granted — something most clients don't detect

There's a parallel problem with agent skills — the SKILL.md instruction packages that shape how Claude Code behaves. Independent research found that roughly 26% of agent skills carry at least one vulnerability, yet there's no obvious way to tell which packages actually help and which introduce risk. It's the same trust gap MCP faces: enormous supply, near-zero verification.

That gap is what SkillzBench, AIQ Labs' independent testing lab for agent skills, is building against — continuously crawling skills, pinning every version to a commit SHA, security-scanning and benchmarking them in a sandbox, and publishing a trust score alongside a separately measured Lift figure. The goal is simple: let teams adopt powerful integrations without guessing.

Until that verification layer matures, the guidance converges on a cautious pattern. Start with read-only servers that deliver high value, gate destructive actions behind explicit human approval, scope credentials narrowly, and vet every third-party server before connecting it. The official MCP security best practices are blunt about this: there should always be a human in the loop, with the ability to deny any tool invocation.

Claude Code plus MCP can transform how your team ships software. The teams that succeed treat vetting as a prerequisite, not an afterthought.

How MCP Actually Works With Claude Code: Architecture and Transport Choices

Every MCP connection in Claude Code follows the same blueprint: a host/client/server model communicating over JSON-RPC 2.0, an architecture inspired by the Language Server Protocol. Claude Code acts as the client, while each server you connect exposes capabilities the model can use. Understanding this structure — and one key setup decision — makes everything else about MCP configuration click.

At the heart of the protocol are three primitives a server can expose. Tools are functions the AI invokes, like creating a ticket or querying a database. Resources are data the AI reads, and prompts are reusable templates. Clients, meanwhile, expose their own capabilities: sampling, roots, and elicitation. This clean separation is what makes MCP genuinely interoperable rather than just another wrapper API.

The protocol's real value is that it solves the N×M integration problem. Without a shared standard, 10 AI apps connecting to 100 tools would require 1,000 custom integrations. With MCP, each side implements the protocol once — which explains why the ecosystem has grown past 10,000 active public servers with 97M+ monthly SDK downloads, per ecosystem data.

Before you connect any server, you face the core transport decision:

• stdio for local servers — the client launches the server as a subprocess on your machine, the common choice for developer integrations like Git or filesystem access.
• Streamable HTTP for remote servers — the right approach for SaaS integrations, provided the server enforces origin checks, authentication, and explicit user approval.
• Avoid HTTP+SSE — the older remote transport is deprecated and should not be used in new setups.

The ecosystem has already voted: a survey of MCP builders found 59% now use Streamable HTTP, versus 34% on stdio. In practice, most Claude Code users run a mix — 70% of consumers have between two and seven servers configured, often blending local development tools with remote data sources.

One nuance worth knowing: most MCP servers aren't public at all. As FastMCP creator Jeremiah Lowin observed in Pragmatic Engineer research, only about 10 public servers see heavy use, while the median user connects Claude Code to their own company's data warehouse. The long tail of public servers has close to zero users — which makes vetting the ones you do connect even more important.

That vetting matters because transport security is only half the picture. A server you launch locally inherits your environment; a remote server you authenticate against holds credentials on your behalf. This is exactly why SkillzBench is building verification and security scanning into its skill and MCP-server discovery — so users can see what a server or skill actually does before granting it access.

Real Claude Code Workflows Worth Copying

The best way to understand what MCP servers actually do for Claude Code is to look at what real engineering teams run every day — not the theoretical use cases, but the workflows documented in production. The Pragmatic Engineer's deep dive, built on a survey of 46 engineers plus interviews, offers the clearest picture.

One standout example: teams connect Atlassian Rovo to Claude Code so a developer can "commit, push, and create a merge request in a single command," according to the Pragmatic Engineer's reporting. The friction of context-switching between terminal, Git, and the merge-request form disappears.

A second documented pattern uses the Linear MCP server. You paste a link to an issue into Claude Code and ask it to complete the ticket — the agent reads the ticket context, plans the change, and writes the code. Observability-driven debugging works the same way: Dash0 pulls telemetry into Claude Code so the agent can cross-reference errors with recent code changes instead of a human digging through dashboards.

A few more workflows worth copying from the same research:

• Browser testing via Playwright/Puppeteer MCP servers, letting Claude Code drive and verify real browser behavior.
• Gradient Labs chains Notion + Claude Code + Linear MCP to auto-generate tickets from test feedback.
• Internal data-warehouse access — the median MCP user connects to their own company's data, not public servers.

That last point matters more than most coverage suggests. FastMCP creator Jeremiah Lowin estimates only about 10 public servers see heavy use, with a "massive long tail of public servers with close to zero users." Most real MCP usage is internal — which means the servers worth trusting are the ones you or your organization can inspect and vet.

That reality shapes how SkillzBench is approaching the problem: since security remains the top adoption barrier for MCP deployments, the lab is building verification, version-pinning, and benchmarking for agent skills, delivered through a single MCP server so each agent sees only the tools and skills explicitly enabled for it.

The practical takeaway: start with a read-only, high-value integration like Linear or an observability server, prove the workflow, then expand. Gate write actions behind human approval — the official MCP security guidance is explicit that a human should always be in the loop with the ability to deny tool invocations. These workflows earn their keep precisely because a person still signs off on the destructive steps.

Securing Your MCP Setup: The Non-Negotiables

Every MCP server you connect to Claude Code is a piece of third-party code that your AI agent can invoke — sometimes with write access to your repositories, tickets, and infrastructure. Security isn't a footnote here: it's the top adoption barrier for MCP overall, and 50% of server builders cite security and access-control complexity as their biggest challenge.

Start read-only, then earn write access. The documented best-practice pattern is to begin with read-only, high-value integrations — data sources, documentation, observability — before granting anything that can mutate state. When you do enable write or destructive actions, apply tool-level RBAC and keep a human in the loop. The official MCP spec is explicit: there should always be a human able to deny tool invocations, and irreversible actions deserve explicit approval plus audit logging.

Scope credentials narrowly — and never pass tokens through. The MCP security documentation states it normatively: servers MUST NOT accept tokens that were not explicitly issued for them. Token passthrough is a forbidden anti-pattern, not a gray area. Issue each server its own narrowly scoped credentials, and remember the ecosystem reality: 24% of servers run with no authentication at all, and researchers have found 492 publicly exposed MCP servers lacking basic auth or encryption.

Watch for two attack classes in particular:

• Tool poisoning — malicious instructions hidden in tool descriptions or output that hijack the agent's behavior.
• Rug-pull attacks — a server's behavior changes after you've granted permissions, which most clients never detect.
• Repository pollution and typosquatting — convincing-looking servers that aren't what they claim to be.

These risks are exactly why version pinning and re-scanning matter. SkillzBench is being built around that principle: pinning every skill to a commit SHA, security-scanning it, and re-verifying when upstream changes — so a server or skill that was safe at install stays provably safe.

Finally, know when not to use MCP at all. Practitioner guidance is clear that static, well-defined workflows are better served by direct API connections, which are more reliable and sidestep MCP's attack surface entirely. Reserve MCP for dynamic, on-the-fly decisions and ad hoc lookups where current data actually justifies the risk.

Vetting Skills and Servers Before You Connect Them

Connecting a third-party server or skill to Claude Code is a trust decision, and the ecosystem gives you plenty of reasons to be careful. With more than 10,000 active public MCP servers and 97 million monthly SDK downloads, quality varies wildly — and security is the top adoption barrier for a reason. Published research found that roughly 26% of agent skills carry at least one vulnerability, which means roughly one in four packages you might install could expose your credentials, code, or data.

The attack patterns are well documented. Researchers have flagged tool poisoning, "rug pull" attacks where a server's behavior changes after you grant permissions, and typosquatting in public repositories. Real incidents back this up: CVE-2025-49596 scored 9.4 on the CVSS scale, and CVE-2025-6514 hit mcp-remote, a package with over 437,000 downloads, enabling remote code execution. Meanwhile, 492 publicly exposed MCP servers were found running without basic authentication or encryption.

Before you connect anything, run a consistent vetting pass:

• Pin the version. Install from a specific commit SHA or tagged release, not a floating "latest," so upstream changes can't silently alter what your agent executes.
• Scan for security issues — look for excessive permissions, network calls you can't explain, and credentials the tool shouldn't need.
• Check the license and maintenance cadence. An abandoned repo with no recent commits is a supply-chain risk waiting to happen.
• Start read-only. The official MCP security guidance is clear that there should always be a human in the loop, with the ability to deny tool invocations — gate anything destructive behind explicit approval.

Vetting for safety is only half the job, though. The other question is whether the skill actually helps. A skill that loads cleanly but degrades your agent's performance is worse than no skill at all, and most developers have no way to measure that beyond vibes.

That measurement gap is what SkillzBench, AIQ Labs' independent testing lab for agent skills, is being built to close. Its approach: pin every skill version to a commit SHA, run security scans and license checks, then benchmark each skill in a sandbox — same model, with and without the skill — and publish the Lift in percentage points so you can see exactly what a skill adds. It's also building per-agent MCP loadouts, so each agent only sees the skills and tools you've explicitly toggled on for it, rather than everything in your configuration.

Until systematic tools like these are live, the manual checklist above is your best defense. Given that 38% of builders say security concerns are holding back MCP adoption, a few minutes of vetting before every connection is a habit worth building now. If you want a structured way to evaluate skills as the ecosystem matures, you can join the SkillzBench waitlist while the platform is in active development.