Connecting an MCP Server to Extend Claude Code's Toolset

Claude Code's built-in tools, read, edit, search, run commands, are enough for most work on a local repository.

An MCP (Model Context Protocol) server extends that toolset with external capabilities, like querying a database or filing a ticket in an issue tracker, without leaving the same session.

Summary

Core Idea: MCP is a protocol that lets Claude Code connect to external servers, each of which exposes its own set of tools Claude Code can call.
Why It Matters: Built-in tools only reach the local filesystem and shell; an MCP server lets a session reach a database, an issue tracker, or an internal API using the same read-edit-run-verify workflow.
Key Concepts: an MCP server (a process that exposes tools), a connection (registering that server with Claude Code), and the combined toolset (built-in tools plus connected servers' tools, available side by side for the rest of the session).
When to Use: Any task that needs information or actions outside the repo itself, checking a ticket's status, looking up a record, calling an internal service.
Limitations / Trade-offs: This page only previews the idea at a basic level; connecting, permissioning, and building MCP servers are each covered in depth elsewhere on this site.

Recipe

Quick-reference recipe card - copy-paste ready.

# Add an MCP server to Claude Code (illustrative form)
claude mcp add <name> <command-to-start-the-server>
 
# List servers currently connected
claude mcp list

When to reach for this:

The task needs data that lives outside the repo, a database row, a ticket, an internal API response.
You want Claude Code to file or update something in an external system as part of a task, like opening an issue after a bug fix.
A team already has an MCP server for a system they use daily and wants Claude Code to use it instead of manual copy-paste.
You are previewing what MCP can do before committing time to building or configuring a server.

Working Example

A common shape for this: a session that needs to check an issue tracker for context before touching code.

# 1. Connect a server once for the project (exact flags depend on the
#    server; check its own docs for the precise command it expects)
claude mcp add issue-tracker npx -y some-issue-tracker-mcp-server
 
# 2. Confirm it connected
claude mcp list
# issue-tracker  connected
 
# 3. Start a normal session; the server's tools are now part of the toolset
claude

Inside that session, a prompt like "look up ticket ENG-482 and fix the bug it describes" can now resolve the lookup through the connected server's tool, then fall straight into Claude Code's normal read-edit-run-verify loop for the code change itself.

What this demonstrates:

Connecting a server is a one-time setup step, separate from any individual session.
Once connected, the server's tools are simply available, no special syntax is needed to invoke them versus a built-in tool.
A single prompt can mix an external lookup with local file edits in one continuous turn.
The server command shown is illustrative; real invocation syntax varies by server and by Claude Code version.

Deep Dive

How It Works

Each MCP server is a separate process that speaks the Model Context Protocol and declares the tools it offers.
Connecting a server registers it with Claude Code so its tools become part of the toolset for that project or session.
From that point, Claude Code chooses between built-in tools and MCP tools the same way it chooses between any two built-in tools, based on what the task needs.
MCP tool calls pass through the same permission logic as built-in commands: depending on permission mode, some calls may be auto-approved and others may prompt for confirmation before they run.

What This Page Does Not Cover

MCP is a big enough topic that it has its own dedicated sections on this site. This page is intentionally a preview, not the full picture:

Topic	Where to go deeper
Core MCP concepts (servers, tools, resources, prompts)	mcp-core-concepts section
Building your own MCP server	building-mcp-servers section
Transport choices, authentication, tool schemas	Reference pages within those sections

Gotchas

Assuming every server uses the same connect command - MCP server startup commands vary by implementation. Fix: check the specific server's own setup instructions rather than reusing a command from a different server.
Expecting MCP tools to bypass permission prompts - a connected tool is not automatically trusted just because it is connected. Fix: review your permission mode; MCP tool calls follow the same approval rules as built-in commands.
Connecting a server and never verifying it's live - a misconfigured server can fail to start silently. Fix: run a list/status command after connecting to confirm the server is actually reachable.
Treating a preview mention as the full setup guide - this page shows the shape of the workflow, not every flag and edge case. Fix: use the dedicated mcp-core-concepts and building-mcp-servers sections before connecting a production server.
Forgetting a connected server is scoped - a server added for one project or session may not automatically apply everywhere. Fix: confirm where a given connection applies before assuming it's available in a different project.

Alternatives

Alternative	Use When	Don't Use When
Built-in tools only (read, edit, search, run)	The task is entirely local to the repo	The task needs data or actions from an outside system
Manual copy-paste from an external tool into the chat	A one-off lookup, no repeated need	The lookup or action happens often enough to be worth automating
A custom script invoked via the run step	The external interaction is simple enough for a one-off CLI call	The system needs structured, repeatable tool access across many sessions

FAQs

What does MCP stand for and what does it do here?

MCP stands for Model Context Protocol.

It is the protocol Claude Code uses to connect to external servers so their tools become part of a session's available toolset.

How is an MCP server different from Claude Code's built-in tools?

Built-in tools, read, edit, search, run commands, operate on the local repository and shell.

An MCP server's tools reach outside that, into whatever system the server was built to expose, like a database or an issue tracker.

Do I need to write special prompts to use an MCP tool?

No, once a server is connected, its tools are simply part of the toolset for that session.

Claude Code chooses between built-in and MCP tools based on what the task requires, the same way it chooses between any two built-in tools.

Does connecting a server change how permission prompts work?

The mechanism stays the same: depending on your permission mode, some tool calls are auto-approved and others prompt for confirmation.

MCP tool calls participate in that same logic rather than following separate rules.

Can an MCP server file a ticket or write to a database, not just read from it?

That depends entirely on what tools the server exposes.

Some servers offer read-only tools, others offer tools that create or modify records; check the specific server's documentation.

Is the `claude mcp add` command shown here exact?

It is illustrative of the general shape, connect a server by name with a command that starts it.

Exact flags can vary by Claude Code version and by the server itself, so check current docs before relying on precise syntax.

Where do I learn the full MCP model, servers, tools, resources, and prompts?

This page is a basic-level preview.

The mcp-core-concepts section covers the underlying protocol in depth, and the building-mcp-servers section covers building one yourself.

Can I connect more than one MCP server at a time?

Yes, multiple servers can be connected, and all of their tools become available alongside Claude Code's built-in tools for that session.

What happens if a connected MCP server isn't actually running?

A tool call to that server will fail or the server won't appear as connected.

Verifying the connection with a status or list command after adding a server catches this before it disrupts a task.

Is connecting an MCP server a one-time setup or something I do every session?

Connecting is typically a one-time setup step for a project, not something repeated every session.

Once connected, the server's tools are available in subsequent sessions without reconnecting.

Why would I use an MCP server instead of just asking Claude Code to run a script that calls the external API?

A one-off script works for a single call, but an MCP server gives Claude Code a structured, repeatable tool it can reuse across prompts and sessions without you writing a new script each time.

Does this page teach me how to build my own MCP server?

No, building a server is covered separately in the building-mcp-servers section.

This page only previews connecting to an existing one.

How Claude Code Executes the Read-Edit-Run-Test Loop - the workflow MCP tools plug into
How Claude Code Decides When to Run a Command vs Ask Permission - the approval logic that also governs MCP tool calls
MCP Core Concepts Basics - start here for the full MCP model
Understanding MCP Tools, Resources, and Prompts - what a server can expose beyond tools
MCP Server Basics - build your own server instead of just connecting to one

Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5. Model names, pricing, and product features move quickly - verify current specifics at platform.claude.com/docs before relying on them.