Every major AI chatbot hits the same wall the moment you ask it to do something outside its training data: read a local file, check today’s GitHub issues, or query a live database. Model Context Protocol (MCP) is the fix Anthropic shipped in November 2024, and by mid-2026 it has become the default way Claude and a growing list of other AI tools connect to the outside world.
This tutorial walks through setting up MCP servers from zero: installing the prerequisites, wiring up your first two servers, connecting a remote server over the newer Streamable HTTP transport, and — the part most guides skip — writing your own MCP server from scratch in Python so you finish with a real, working tool your AI assistant can call. Budget around 100 minutes if you work through every step, less if you only need the basics up and running.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Is Model Context Protocol (MCP)?
Model Context Protocol is an open standard, introduced by Anthropic on November 25, 2024, that defines a single, uniform way for AI applications to connect to external tools, files, and data sources. Before MCP, every AI app that wanted to talk to GitHub, Slack, or a local filesystem had to ship a custom, one-off integration for each combination of model and tool. Google Cloud’s own explainer describes this as the “N times M” integration problem: N different AI applications, each needing custom code for M different tools, producing N×M separate integrations that all had to be maintained separately.
MCP collapses that into an N+M problem. A tool builder writes one MCP server once. Any MCP-compatible AI client — Claude Desktop, Claude Code, or another compatible app — can then talk to that server without any custom glue code. Wikipedia’s summary puts it plainly: MCP standardizes how large language models integrate and share data with external tools, systems, and data sources, similar in spirit to how a USB-C port lets one cable work across many devices.
The protocol is open source and free to implement. Anthropic published the initial specification (version-dated 2024-11-05) alongside reference servers for tools like Google Drive, Slack, GitHub, Git, Postgres, and Puppeteer, giving developers working examples to copy instead of starting from a blank page.
Why MCP Matters for AI Models in 2026
MCP didn’t stay a Claude-only experiment. Anthropic’s own engineering team says that since the November 2024 launch, “adoption has been rapid: the community has built thousands of MCP servers,” and that SDKs now cover most major programming languages, according to Anthropic’s engineering blog. Independent estimates of the total server count vary — some 2026 trackers put the figure north of 10,000, others closer to 5,800 — so treat any single number as a rough snapshot of a fast-moving ecosystem rather than a fixed count.
The protocol has also outgrown its original owner. In December 2025, Anthropic transferred stewardship of MCP to a newly established, vendor-neutral Agentic AI Foundation, a move meant to signal that MCP is shared infrastructure for the AI industry rather than a single company’s product. That governance shift matters if you’re deciding whether to build on MCP long-term: it’s no longer a proprietary Anthropic format, it’s closer to an industry-wide interoperability layer that other model providers can and do build against.
The spec itself keeps moving. Since the initial November 2024 release, the working group has shipped five major spec revisions, most recently the 2026-07-28 release, which Anthropic’s own team calls a “stateless core” update and describes as live in Claude as of late July 2026.
| Spec Version | Release Date | What It Introduced |
|---|---|---|
| 2024-11-05 | November 2024 | Initial public specification, shipped alongside Claude Desktop and reference servers |
| 2025-03-26 | March 2025 | Early transport and authorization refinements |
| 2025-06-18 | June 2025 | Continued protocol hardening ahead of the one-year mark |
| 2025-11-25 | November 2025 | One-year anniversary spec release |
| 2026-07-28 | July 2026 | Fifth major release; “stateless core” rework described as the largest revision in the standard’s history |
For everyday users, the practical takeaway is simpler than the version history: MCP servers are the mechanism behind most of the “connected” features you now see in AI chat apps — reading your calendar, searching your codebase, pulling live data into a chat. Learning to configure them yourself unlocks far more than the handful of built-in integrations any single vendor ships out of the box, and it means you’re not stuck waiting for a vendor to build the one integration you actually need.
This also explains why MCP shows up so often in coverage of AI coding tools. Assistants like GitHub Copilot and terminal-based agents increasingly treat MCP servers as their primary extension mechanism, since a single server (say, one that queries your company’s internal ticketing system) can be wired into several different coding assistants without rewriting it for each one. That reuse is the entire economic argument for MCP: build the integration once, and every compliant client — present and future — inherits it for free.
MCP Architecture Explained: Hosts, Clients, Servers, and Transports
Before touching a config file, it helps to know the three pieces MCP documentation constantly refers to:
- Host — the AI application itself, such as Claude Desktop or Claude Code. This is what you interact with.
- Client — a connector inside the host that manages a single one-to-one connection to a server.
- Server — a lightweight program that exposes tools, data, or prompts through the standard MCP interface. A server might wrap a filesystem, a GitHub account, or a proprietary internal database.
Servers talk to clients over one of two transport types. stdio (standard input/output) is used for local servers: the host launches the server as a child process on your own machine and pipes messages back and forth. It’s simple, fast, and requires no network configuration, which is why almost every getting-started guide — this one included — starts there. Streamable HTTP is used for remote servers hosted elsewhere, replacing the older combination of HTTP and Server-Sent Events from MCP’s earliest revisions. You’ll use it later in this tutorial to connect to a server that isn’t running on your own laptop.
| Transport | Where the Server Runs | Typical Use Case | Setup Complexity |
|---|---|---|---|
| stdio | Local machine, as a child process | Filesystem access, local scripts, personal tools | Low — no network config needed |
| Streamable HTTP | Remote server, accessed over the internet | Shared team tools, SaaS integrations, hosted APIs | Moderate — needs a URL and often an auth token |
Everything a server exposes falls into three categories: tools (functions the model can call, like “create a GitHub issue”), resources (data the model can read, like a file’s contents), and prompts (reusable prompt templates the server provides). Most of what you’ll configure in this guide are tools, since they’re what let an AI model actually take action rather than just read data.
This three-way split matters when you’re deciding what to build later in this tutorial. A resource is the right choice when you just want the model to be able to read something — a config file, a status page — without any risk of it changing state. A tool is the right choice the moment you want the model to take an action with a side effect, like writing a file or opening a ticket. Conflating the two is a common design mistake: exposing a database update as a “resource” the model can silently trigger just by reading it defeats the purpose of having the distinction at all.
Prerequisites: What You Need Before You Start
MCP servers are typically small Node.js or Python programs, so you need working runtimes for both even if you only plan to use one language today — many official reference servers are Node-based, while the custom server you’ll build later in this guide uses Python. None of this requires a paid account beyond the AI client itself.
| Requirement | Minimum Version | Why You Need It |
|---|---|---|
| Node.js + npm | Node.js 18 or later (20+ recommended) | Runs most official reference MCP servers via npx |
| Python | 3.10 or later | Runs the custom MCP server you’ll build in this tutorial |
| uv (Python package manager) | Latest release | Anthropic’s documented tool for running and packaging Python MCP servers |
| MCP-compatible client | Claude Desktop or Claude Code, latest release | The “host” application that connects to your servers |
| GitHub account + personal access token | N/A | Needed only for the GitHub server example in Step 5 |
| Text editor | Any | Editing JSON config files and the Python server code |
A command-line terminal is non-negotiable here — every MCP server, whether local or remote, is configured through a JSON file and installed or launched from a shell. If you’ve never opened Terminal (macOS/Linux) or PowerShell (Windows) before, budget extra time for this tutorial and go slowly through Step 1.
Setting Up Your MCP Client (Steps 1-3)
Step 1: Verify Node.js, Python, and uv Are Installed
Open a terminal and check what’s already on your machine before installing anything new:
node -v
npm -v
python3 --version
uv --version
If node -v fails or reports a version older than 18, install the current LTS release from the official Node.js site. If python3 --version fails, install Python 3.10 or newer from python.org (or via your system’s package manager). If uv --version fails, install uv with the official installer script for your platform — it’s a fast, single-binary package manager that Anthropic’s own documentation uses for Python MCP servers, and it will handle virtual environments for you automatically in later steps.
Step 2: Install Claude Desktop or Claude Code
Download Claude Desktop for macOS or Windows, or install Claude Code if you prefer working entirely from the terminal. Both are MCP hosts, meaning both can launch and connect to MCP servers, but they read their server configuration from slightly different locations, which matters in the next step. Sign in with your Anthropic account and confirm the app opens normally before continuing — it’s much easier to debug a plain login issue now than to mistake it for an MCP connection problem later.
Step 3: Locate Your MCP Configuration File
Claude Desktop reads its server list from a file named claude_desktop_config.json. The file doesn’t exist until you create it, and its location depends on your operating system:
- macOS:
~/Library/Application Support/Claude/claude_desktop_config.json - Windows:
%APPDATA%\Claude\claude_desktop_config.json
Create the folder if it doesn’t exist yet, then create an empty JSON object in that file as a starting point:
{
"mcpServers": {}
}
Everything you add from here on goes inside that mcpServers object, one named entry per server.
Claude Code works a little differently. Alongside the same global config, it also supports a project-scoped .mcp.json file that lives inside a specific project’s root directory, so servers relevant to one codebase don’t clutter every other project you open. If you’re following this tutorial with Claude Code instead of Claude Desktop, decide up front whether a given server belongs globally (available everywhere) or locally (scoped to one project), since mixing the two up is one of the most common configuration mistakes covered later in this guide’s pitfalls section.
Installing Your First MCP Servers (Steps 4-6)
Step 4: Add the Filesystem MCP Server
The filesystem server is the standard first stop for anyone learning MCP: it gives your AI client read and write access to a folder you specify, with no external account required. Edit claude_desktop_config.json to add it:
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/yourname/Documents/projects"
]
}
}
}
Replace the path with an absolute path to a real folder on your machine — a project directory works well for testing. The npx -y command downloads and runs the server automatically the first time it’s needed, so you don’t have to install it globally first.
Step 5: Add the GitHub MCP Server
Next, connect a second server so you can see how multiple entries coexist in the same config file. Generate a GitHub personal access token with minimal scopes (read access to the repositories you want the assistant to see is enough for testing), then add:
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/yourname/Documents/projects"
]
},
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "your_token_here"
}
}
}
}
Never commit this file to a git repository or share it in a screenshot with the token visible — it grants whatever access scope you assigned to the token. Treat it exactly like a password.
Step 6: Restart Your Client and Verify the Connection
Save the config file, then fully quit Claude Desktop — not just close the window, actually quit the application — and reopen it. Editing the config while the app is running has no effect until it’s relaunched. Once it reopens, look for a small tools or connector icon near the message box. Clicking it should list both filesystem and github as connected servers, each with the individual tools they expose (for example, read_file and list_directory for the filesystem server). If a server shows as errored instead of connected, jump ahead to the troubleshooting section before continuing.
Testing and Extending Your Setup (Steps 7-8)
Step 7: Run Your First Real Tool Calls
Configuration only proves the connection works — the real test is asking the model to use it. In a new chat, ask something concrete and scoped to the folder you configured, such as “list the files in my projects folder” or “read the contents of README.md and summarize it.” Claude should visibly invoke the filesystem tool (most clients show a small expandable card indicating a tool was called) rather than guessing at an answer. Try the same pattern with GitHub: “show me the open issues on [your repo].” If the model answers instantly without any visible tool-call indicator, it’s likely answering from general knowledge rather than actually querying your server — a subtle failure mode worth watching for.
Step 8: Connect a Remote MCP Server via Streamable HTTP
Local servers cover personal use, but a lot of production MCP servers — especially ones offered by SaaS products — run remotely and are reached over Streamable HTTP instead of stdio. The config shape is different: instead of a command and args that launch a local process, you provide a URL:
{
"mcpServers": {
"hosted-example": {
"url": "https://mcp.example-service.com/sse",
"transport": "streamable-http",
"headers": {
"Authorization": "Bearer your_api_key_here"
}
}
}
}
Substitute the URL and header with whatever a given SaaS product’s own MCP documentation provides — the exact field names can vary slightly by client version, since Streamable HTTP itself is one of the areas the 2026-07-28 spec revision touched. If you don’t have a specific remote server to test against yet, it’s fine to skip this step and come back to it once you do; nothing in the rest of the tutorial depends on it.
Building Your Own MCP Server: A Complete Working Project (Steps 9-11)
Installing other people’s servers gets you connected fast, but writing your own is what makes MCP genuinely useful — it’s how you expose your own scripts, internal tools, or business logic to an AI model. The rest of this section builds a small, complete “dev toolkit” server with three tools: a word counter, a text slugifier, and a secure password generator. It uses only the Python standard library plus the official MCP SDK, so it runs immediately with no external API keys.
Step 9: Scaffold the Project
From your terminal, create a new project directory and initialize it with uv, then add the MCP SDK as a dependency:
uv init dev-toolkit
cd dev-toolkit
uv add mcp
This creates a project folder with a pyproject.toml file and installs the official mcp Python package, which includes the FastMCP helper class used below to define tools with minimal boilerplate.
Step 10: Write the Server Code
Create a file named server.py in the project folder with the following code:
import re
import secrets
import string
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("dev-toolkit")
@mcp.tool()
def count_words(text: str) -> dict:
"""Count words, characters, and sentences in a block of text."""
words = text.split()
raw_sentences = re.split(r"[.!?]+", text.strip())
sentences = [s for s in raw_sentences if s.strip()]
return {
"words": len(words),
"characters": len(text),
"sentences": len(sentences),
}
@mcp.tool()
def slugify(text: str) -> str:
"""Convert text into a URL-friendly slug."""
slug = text.lower().strip()
slug = re.sub(r"[^a-z0-9]+", "-", slug)
return slug.strip("-")
@mcp.tool()
def generate_password(length: int = 16) -> str:
"""Generate a cryptographically secure random password."""
length = max(8, min(length, 128))
alphabet = string.ascii_letters + string.digits + "!@#$%^&*"
return "".join(secrets.choice(alphabet) for _ in range(length))
if __name__ == "__main__":
mcp.run()
Every function decorated with @mcp.tool() becomes a callable tool automatically. The docstring under each function isn’t just documentation — it’s what the AI model reads to decide when a tool is relevant, so writing a clear, specific one-line description matters as much as the code itself.
Step 11: Register and Run Your Custom Server
Add your new server to claude_desktop_config.json alongside the others, pointing at the absolute path of your project folder:
{
"mcpServers": {
"dev-toolkit": {
"command": "uv",
"args": [
"--directory",
"/absolute/path/to/dev-toolkit",
"run",
"server.py"
]
}
}
}
Fully restart your client again, then test it directly: ask “generate a 20-character password” or “slugify the text ‘MCP Servers Are Actually Useful’.” If the tool call succeeds, you’ve gone from zero to a working, custom MCP integration — the same basic pattern scales to wrapping internal APIs, database queries, or any script you already have.
Locking Down Security (Steps 12-13)
Step 12: Apply the Principle of Least Privilege
Every server you connect is a new capability the model can invoke, sometimes with very little friction. Point the filesystem server at a narrow project folder, not your entire home directory. Scope GitHub tokens to read-only access unless you specifically need the assistant to open issues or push commits. Review what each server can actually do — most reference servers document their tool list — before trusting it with broad access.
Step 13: Guard Against Prompt Injection and Secret Leaks
MCP’s security model has known, publicly documented weak points. Research summarized on MCP’s Wikipedia entry found “multiple outstanding security issues,” including prompt injection carried through malicious or poisoned tool descriptions and so-called lookalike tools designed to trick a model into calling the wrong server. In practice, that means a compromised or badly designed server can smuggle instructions to the model inside data that looks harmless — a file’s contents, an API response — and the model may follow them without you seeing it happen.
Only install servers from sources you trust, read a server’s source code before connecting it to anything sensitive if you can, and never paste raw API keys or tokens into a config file that syncs to cloud backup or a shared machine. If a client supports per-server permission prompts or tool-call confirmation, leave that setting on for any server touching write access, money, or credentials.
A useful habit borrowed from general application security: treat every third-party MCP server the same way you’d treat a browser extension asking for broad permissions. Ask what it actually needs access to versus what it’s requesting, check whether the project has recent commits and responsive maintainers, and prefer servers with a visible, readable source repository over ones distributed only as a compiled package. None of this is unique to MCP, but the stakes are higher here because a connected server can act on your behalf inside tools like email, code repositories, and databases rather than just rendering a webpage.
Popular MCP Servers Worth Installing Next
Filesystem and GitHub are the two most common starting points, but Anthropic’s original reference collection covers several other everyday tools, and the same mcpServers pattern you’ve already used twice applies to each of them. Add entries one at a time and restart between each one — that way, if a connection fails, you know exactly which addition caused it.
| Server | What It Connects To | Typical Use |
|---|---|---|
| Git | Local Git repositories | Reading commit history, diffs, and branches without leaving the chat |
| Google Drive | Google Drive files and folders | Searching and reading documents stored in Drive |
| Slack | A Slack workspace | Reading and posting messages, searching channel history |
| Postgres | A PostgreSQL database | Running read queries against a database schema in plain English |
| Puppeteer | A headless Chrome browser | Navigating web pages, taking screenshots, scraping page content |
Each of these follows the same two-part pattern you already know: a command (usually npx) with the package name in args, plus an env block for any credentials the service requires. The Postgres and Slack servers in particular are worth pairing with the least-privilege guidance in Step 12 — a database server configured with a read-only connection string is a very different risk profile than one configured with a superuser account, even though the JSON setup looks nearly identical either way.
Common Pitfalls When Setting Up MCP Servers
Most first-time MCP setups fail for a handful of predictable reasons. Watch for these before assuming something is broken at a deeper level:
- Relative paths instead of absolute paths. Servers often launch from a different working directory than you expect. A path like
./projectswill frequently fail where/Users/yourname/projectsworks. - Not fully restarting the client. Closing a window is not the same as quitting the app. Config changes are read once, at startup.
- Invalid JSON syntax. A single trailing comma or a missing closing brace silently breaks the entire config file, not just the one server you were editing. Validate the file before restarting.
- Granting far more access than a task needs. Pointing the filesystem server at your whole home directory, or issuing a GitHub token with full repo and admin scope “just in case,” turns a minor misconfiguration into a serious exposure.
- Committing secrets into version control. Config files with embedded API tokens are easy to accidentally commit or back up to a synced folder. Keep secrets out of any file that leaves your machine.
- Mixing up global and project-level config. Claude Code supports project-scoped MCP configuration in addition to the global Claude Desktop config file, and it’s easy to edit the wrong one and wonder why nothing changed.
- Assuming a tool call happened when it didn’t. A model can produce a plausible-sounding answer from its own training data instead of actually calling a connected tool. Get in the habit of checking for the visible tool-call indicator described in Step 7 rather than trusting the answer on its face.
- Forgetting that
npx -yalways pulls the latest version. A server that worked perfectly last week can change behavior overnight if its maintainer ships a breaking update, since nothing in the default config pins a specific version.
Troubleshooting: MCP Connection and Tool-Call Errors
When a server refuses to connect or a tool call fails, the fix is almost always in this list:
| Symptom | Likely Cause | Fix |
|---|---|---|
| Server never appears in the tools list | Malformed JSON in the config file | Validate the JSON syntax, then fully restart the client |
| “command not found” or similar spawn error | Node.js or uv isn’t installed, or isn’t on the system PATH | Re-run the Step 1 version checks; reinstall if a command fails |
| Server listed but shows zero available tools | The server process crashed immediately after starting | Check the client’s MCP log files for a stack trace |
| Connection closes right after starting | Missing or incorrect required argument (often a bad path) | Double-check every path in args is absolute and exists |
| GitHub server returns 401 or “Bad credentials” | Expired or malformed personal access token | Regenerate the token and confirm it has the needed scopes |
| Config edits don’t seem to apply | The client was reloaded but not fully quit first | Quit the application completely, then relaunch it |
| “uv: command not found” when running a Python server | uv isn’t installed or your terminal session predates the install | Reinstall uv and open a new terminal window |
| A tool call hangs indefinitely | Blocking code or an infinite loop inside a custom tool function | Add timeouts and test the function outside MCP first |
| Remote server fails to connect over Streamable HTTP | Wrong URL scheme, expired token, or certificate issue | Confirm the URL uses HTTPS and the auth header matches the provider’s docs |
| Model never actually calls a tool you know is connected | Vague or missing docstring/description on the tool | Rewrite the description to state clearly and specifically what the tool does |
If none of these match, most clients write a per-server log file you can tail while restarting — that log almost always contains the actual exception, even when the app’s UI just shows a generic “failed to connect” message.
Advanced Tips for Power Users
Once the basics are working reliably, a few habits separate a fragile setup from one you can actually depend on day to day.
Keep a separate config for experiments. Rather than editing your working claude_desktop_config.json directly when trying a new or unfamiliar server, duplicate it first. If the new server breaks the file’s JSON syntax, you can revert instantly instead of losing every server you already had configured.
Write narrow, single-purpose tools. A server with one tool that does exactly one thing is far easier for a model to use correctly — and for you to audit — than one giant tool with a dozen optional parameters. The three-tool dev-toolkit server built earlier in this guide is intentionally scoped that way.
Version-pin production servers. The npx -y pattern used throughout this tutorial always fetches the latest published version, which is convenient for learning but risky for anything you depend on daily — a breaking update to a server you didn’t touch can silently change its behavior. Pin to a specific version once a setup is working the way you want.
Treat tool descriptions as part of your prompt engineering. Since the model decides whether to call a tool based largely on its name and docstring, iterating on that description is often a faster fix for “the model won’t use my tool” than changing the underlying code.
Watch the spec, not just your client’s release notes. Because the official MCP blog ships spec revisions independently of any single AI vendor, a client update and a protocol update don’t always land on the same day. When something that worked yesterday breaks, check whether the spec moved before assuming your own config is at fault.
MCP vs. Traditional API Integrations and Plugins
If you’ve built a custom API integration or a chatbot plugin before, MCP will feel familiar in places and genuinely different in others. The core distinction is standardization: a traditional integration is built for one specific application, while an MCP server is built once and works with any compliant client.
| Dimension | Traditional API Integration / Plugin | MCP Server |
|---|---|---|
| Reusability | Tied to one app’s plugin system | Works with any MCP-compatible client |
| Integration effort | N apps × M tools = separate integrations for each pair | N apps + M tools = one server per tool, reusable everywhere |
| Discovery | Manually registered in each app’s ecosystem | Client queries the server directly for its available tools |
| Local file/data access | Usually requires a cloud round-trip | Can run entirely on your machine over stdio |
| Governance | Controlled by the platform that hosts the plugin store | Open standard stewarded by the vendor-neutral Agentic AI Foundation |
None of this makes traditional integrations obsolete — a deeply embedded, single-purpose plugin inside one app can still outperform a generic MCP server for that one use case. But for anyone building or connecting more than one tool, the standardization is the entire point: you stop rebuilding the same integration logic for every new AI client that shows up.
Where to Go From Here
By this point you’ve connected two official reference servers, tested a remote connection over Streamable HTTP, and shipped a working custom server with three real tools — which puts you ahead of most people who’ve only used MCP through a vendor’s pre-built integrations. The natural next step is picking one recurring task you do manually today (formatting a report, checking a status dashboard, searching internal documentation) and building a narrow, single-purpose server around it using the same FastMCP pattern from Step 10.
It’s also worth revisiting your config periodically rather than treating this as a one-time setup. Because the spec itself is still evolving — five revisions in under two years, most recently the 2026-07-28 release — a server or client that behaves one way today may pick up new capabilities, or deprecate old config fields, within a few months. Bookmark the official MCP blog if you plan to keep building on the protocol rather than just using a fixed set of servers.
Frequently Asked Questions
What is Model Context Protocol in simple terms?
It’s an open standard that lets AI models like Claude connect to outside tools and data — files, GitHub, databases, internal scripts — through one consistent interface, instead of needing a custom integration for every combination of app and tool.
Do I need to know how to code to use MCP servers?
No. Installing pre-built servers like the filesystem or GitHub examples in this guide only requires editing a JSON config file. Coding is only needed if you want to build your own server, as this tutorial’s final project does.
Is it safe to connect MCP servers to my AI assistant?
Official, well-maintained reference servers are reasonably safe when scoped narrowly, but the protocol has documented weak points around prompt injection and malicious tool descriptions. Only install servers from sources you trust, and follow the least-privilege guidance in Step 12 of this guide.
What’s the difference between a local and a remote MCP server?
A local server runs on your own machine and communicates over stdio, as configured in Steps 4-6 of this guide. A remote server runs elsewhere and is reached over Streamable HTTP, typically with an authentication header, as shown in Step 8.
Does MCP cost anything to use?
The protocol itself is free and open source. Individual servers may wrap paid APIs (a GitHub server still respects GitHub’s own rate limits and account permissions, for instance), but there’s no licensing fee to implement or use MCP itself.
Is MCP only for Claude, or do other AI models support it too?
MCP shipped first and most deeply integrated with Claude Desktop and Claude Code, since Anthropic created the protocol. It was designed from the outset as an open, vendor-neutral standard, and that positioning was reinforced when governance moved to the independent Agentic AI Foundation in December 2025 — but always check a specific client’s own documentation for its current level of MCP support before assuming feature parity with Claude.
Where can I find more MCP servers to install?
Anthropic’s original reference servers cover common tools like Git, Google Drive, Slack, Postgres, and Puppeteer. Beyond those, the community has published thousands of additional servers on GitHub and npm; vet the source code of anything outside the official reference set before granting it access to sensitive data.
What changed in the MCP 2026-07-28 spec update?
Anthropic describes it as a “stateless core” rework — the fifth major spec release since MCP launched — and calls it the largest revision to the standard so far. It’s already live in Claude as of late July 2026, according to Anthropic’s own announcement.
Will adding MCP servers slow down my AI assistant?
Local stdio servers add minimal overhead since they run as lightweight child processes on your own machine. Remote servers reached over Streamable HTTP add whatever network latency exists between you and that server, similar to any other web request. The bigger performance factor is usually how many tools are connected at once, since the model has to consider all of them when deciding whether to make a tool call.
Do I need to update my MCP servers manually?
If your config uses the npx -y pattern shown throughout this tutorial, you’ll automatically get the latest published version of a server every time it launches, with no manual update step. That convenience is also a risk for anything you rely on daily, which is why the advanced tips in this guide recommend version-pinning production setups instead.
Related Coverage
- How to Set Up LM Studio: 13 Steps, 80 Min [2026]
- How to Run a Local LLM With Ollama: 13 Steps, 90 Min [2026]
- How to Build a RAG Pipeline: 12 Steps, 90 Min [2026]
- How to Set Up GitHub Copilot: 12 Steps, 70 Min [2026]
- How to Install OpenCode: 13 Steps, 80 Min [2026]
- Claude Opus 4.8 Hits 61.4, Tops AI Leaderboard [2026]


