MCP Tools in 2026: What They Are, How to Install Them, and the 8 I Run Daily

Most people are still running Claude with the parking brake on. You get an AI that can think, write, and reason — but the moment it needs to touch a real system, you’re back to copy-pasting.

MCP tools remove that parking brake. They’re the callable functions an MCP server hands to your AI so it can stop describing the work and start doing it.

I run 10+ autonomous brand containers inside JonOps. Every day, Claude wakes up on a cron schedule, reads the content calendar from Airtable, drafts the post, generates images, publishes to WordPress, schedules to social, and logs everything — with zero keyboard input from me. The reason that’s possible is eight MCP tools wired into my Claude Code environment.

This guide is three things in one, because that’s what the question actually deserves: what MCP tools are at the protocol level, which ones are worth installing, and how to run them without shredding your context window or your security posture.

Updated September 2026. I first published this in June. Since then the spec moved to a new revision, Claude Code changed how it loads tools, and two of my original answers went from correct to flat wrong. I’ve marked both corrections in place rather than quietly deleting them — you deserve to see which claims aged badly, especially since most guides still ranking for this term were written before any of it happened.

What MCP Tools Are (And What the Spec Actually Says)

Let’s get the terminology right, because the framing you start with determines how useful everything after it will be.

MCP stands for Model Context Protocol — the open standard, originally from Anthropic and now maintained as a community spec, for connecting AI applications to external systems. The official docs describe it as a USB-C port for AI: one protocol, any system that ships a compatible server. It’s no longer a Claude-only story either — Claude, ChatGPT, VS Code, and Cursor all speak it.

An MCP tool is one callable function that a server exposes. A server usually exposes several. The protocol defines three distinct things a server can offer, and conflating them is the single most common mistake I see:

• Tools — model-controlled callable functions with side effects. Claude decides to invoke them. Open a pull request, trigger an n8n workflow, write an Airtable record.
• Resources — application-controlled data the client can read. Files, records, API responses. Nobody “calls” a resource; it gets attached as context.
• Prompts — user-controlled templates, typically surfaced as slash commands or menu items.

The distinction matters operationally: tools do things, resources know things. If you want Claude to read your database schema, that’s a resource. If you want Claude to run a migration against it, that’s a tool — and it should require confirmation.

Here’s what a tool definition looks like on the wire. The server returns this from a tools/list call:

{
  "name": "get_weather",
  "title": "Weather Information Provider",
  "description": "Get current weather information for a location",
  "inputSchema": {
    "type": "object",
    "properties": {
      "location": { "type": "string", "description": "City name or zip code" }
    },
    "required": ["location"]
  },
  "outputSchema": {
    "type": "object",
    "properties": {
      "temperature": { "type": "number" },
      "conditions": { "type": "string" }
    }
  }
}

That’s the whole contract: a name, a human-readable description, a JSON Schema for the input, and optionally a JSON Schema for the output. The description field is not decoration — it’s the only thing the model reads when deciding whether this tool is the right one for the job. Vague descriptions are the number one cause of “why didn’t Claude use the tool I installed.”

Two details from the current spec that bite people in production:

• Tool names have rules. 1–128 characters, case-sensitive, and only letters, digits, underscore, hyphen, and dot. No spaces, no commas. Names only need to be unique within a server.
• Collisions across servers are your problem, not the protocol’s. Run two servers that each expose search and you need a disambiguation strategy — the spec suggests prefixing with a server identifier. It also explicitly warns that the server’s own reported name isn’t guaranteed unique, so don’t build your prefix on that.

If you’re starting from zero on the underlying concept, I wrote the foundational explainer separately: what an MCP server actually is. This guide assumes you’ve got that and want to know which tools to run and how to run them safely.

How MCP Tools Work — The Wire-Level Mental Model

Picture Claude as an operator at a switchboard. Without MCP, there’s exactly one live connection: to you. You ask, it answers. You paste data, it processes. Every interaction routes through you as the relay.

Install MCP tools and the board lights up. GitHub on line one. Airtable on line two. n8n on line three. A real browser on line four. When Claude needs something from one of those systems, it picks up the line itself.

The actual message flow is simpler than the diagrams suggest:

1. Discovery. The client sends tools/list. The server returns its tool definitions.
2. Selection. The model reads the names, descriptions, and input schemas, and picks one.
3. Invocation. The client sends tools/call with the tool name and arguments.
4. Execution. The server does the real work and returns a result — text, an image, audio, a link to a resource, an embedded resource, or structured JSON validated against the tool’s outputSchema.
5. Continuation. The model reads the result and keeps going.

Two things worth internalising because they explain most weird behaviour:

Tool lists are not static. A server that declares the listChanged capability can push a notification when its tool set changes mid-session — a server that just got authenticated can suddenly expose twenty tools it was hiding. Claude Code picks these up live.

There is no protocol-level session. This surprises people. MCP has no built-in concept of “our conversation so far” on the server side. The spec’s guidance for stateful work — a shopping cart, an open browser context, a database transaction — is to return an explicit handle from a creation tool and accept it as an argument on later calls:

// → tools/call
{ "name": "create_basket", "arguments": {} }

// ← result
{
  "content": [{ "type": "text", "text": "Created basket bsk_a1b2c3" }],
  "structuredContent": { "basket_id": "bsk_a1b2c3" }
}

// → tools/call
{ "name": "add_item", "arguments": { "basket_id": "bsk_a1b2c3", "sku": "..." } }

The model is responsible for carrying that handle forward. Which means: if you’re building a server, the spec’s own advice is to make handles opaque, give them a bounded lifetime, state that lifetime in the creation tool’s description, and — critically — re-validate the caller’s authorization against the handle on every single call. A handle is a name, not a capability. For unauthenticated servers it’s effectively a bearer token, so generate it with real entropy.

What makes this powerful for a one-person business isn’t any single tool. It’s composition. GitHub plus Airtable plus n8n plus a browser means Claude can run research → write → publish → log → trigger as one autonomous session. That’s the difference between an assistant and an operator, and it’s the same principle behind every Claude Code agent I run in production.

What Changed for MCP Tools in the 2026-07-28 Spec

This is the section no other guide currently ranking for “mcp tools” has, and the reason is simple: they were written before it happened. The current protocol revision is 2026-07-28. Every listicle on page one of this SERP predates it.

MCP versions are dated strings in YYYY-MM-DD form, and the date marks the last time backwards-incompatible changes shipped — not the last update. Backwards-compatible improvements land continuously without bumping the number. So a dated version is a compatibility marker, not a changelog.

Here’s what actually moved, and why you’d care.

Version negotiation moved from the handshake to every request

This is the big architectural one. In the handshake-based revisions — 2025-11-25 and earlier — client and server agreed on a protocol version once, at initialization, and lived with it. Now every request declares its own version via the io.modelcontextprotocol/protocolVersion key in its _meta field, and the server accepts or rejects each request independently. Over Streamable HTTP the same value rides along in an MCP-Protocol-Version header.

If the server can’t handle the requested version it returns an UnsupportedProtocolVersionError that lists what it can do, and the client retries or surfaces the error. Clients and servers may support multiple versions simultaneously.

There’s also a new mandatory RPC, server/discover, which returns a server’s supported protocol versions, capabilities, and identity in a single call. Calling it is optional — you’re free to fire a request and handle the version error if one comes back — but it’s there when you want to know what you’re talking to before you talk to it.

Why this matters to you as an operator: it’s a useful staleness test. Any tutorial that describes MCP version agreement as something that happens once during initialize was written before July 2026. That includes a lot of what’s currently ranking.

Tools can now ask you for input mid-call

Previously a tools/call either succeeded or failed. Now a server MAY respond with an input-required result — resultType: "input_required" — carrying a set of inputRequests (typically an elicitation/create form) and an opaque requestState blob. The client collects the answers from the user and retries the call with inputResponses plus that same requestState.

// ← server needs something from the human
{
  "resultType": "input_required",
  "inputRequests": {
    "github_login": {
      "method": "elicitation/create",
      "params": {
        "mode": "form",
        "message": "Please provide your GitHub username",
        "requestedSchema": { "type": "object", "properties": { "name": { "type": "string" } }, "required": ["name"] }
      }
    }
  },
  "requestState": "eyJsb2NhdGlvbiI6Ik5ldyBZb3JrIn0..."
}

One sharp edge if you’re implementing this: the JSON-RPC id must differ between the original request and the retry. Reuse it and you’ll spend an afternoon debugging.

Practically, this is what lets a tool ask “which account?” or “confirm the destination branch?” without the server author faking it through error strings. For anyone running unattended agents, it’s also a new failure mode to plan for: a tool that blocks on human input will stall a cron run. In JonOps I keep elicitation-capable tools out of the fully autonomous skills and reserve them for interactive sessions.

Tool parameters can be mirrored into HTTP headers

The x-mcp-header extension property lets a server designate specific tool parameters to be copied into HTTP headers on the Streamable HTTP transport, arriving as Mcp-Param-{name}. The point is infrastructure: load balancers, proxies, and WAFs can route and filter on a parameter value without parsing the JSON body.

This is a “you’ll know when you need it” feature — it exists for teams putting MCP traffic behind real network infrastructure. But it’s a strong signal about where the protocol is heading: MCP is being built for production topologies, not just laptops.

Deprecation now has a published contract

Features can be marked Deprecated under a formal feature-lifecycle policy. A deprecated feature stays in the spec for at least twelve months — or at least ninety days under an expedited-removal exception — and has to document a migration path before it becomes eligible for removal. There’s a public registry of currently-deprecated features.

For anyone building on MCP commercially, this is the most underrated change in the release. It converts “will this break?” from a vibe into a schedule.

The 8 MCP Tools Running Inside JonOps Right Now

Here’s my actual operating stack of MCP tools. Not a roundup of what’s popular — the servers that are installed and firing inside the JonOps container, today. For each one: what it does, what it unlocks in practice, and whether you should bother.

1. GitHub MCP Server

What it does: Direct access to your repositories — read files and directories, create branches, open pull requests, post reviews, manage issues, check history, push changes.

In JonOps: When I’m building or debugging a skill, Claude opens the codebase, finds the relevant files, makes the edits, opens a PR, and posts a review summary. No copy-pasting between editor and chat. Claude is the editor for autonomous tasks.

Install it if: You build anything with code — even if you don’t write it yourself. Full setup walkthrough: GitHub MCP Server guide.

2. Playwright MCP Server

What it does: Gives Claude a real browser. Navigate, click, fill forms, screenshot, extract content from JavaScript-rendered pages that plain HTTP can’t reach.

In JonOps: SERP research and competitor monitoring on pages that block simple scrapers — and post-publish verification. Claude opens the live URL and confirms the page rendered before marking the job done. That verification step has caught more silent failures than every log line I’ve ever written.

Install it if: You need Claude to touch the web beyond API calls. Details: Playwright MCP Server guide.

3. Filesystem MCP Server

What it does: Read and write files on your machine or inside a container, scoped to configured paths.

In JonOps: Every skill file, generated image, log, and config passes through it. When the blog-writer skill runs, Claude reads the skill markdown, executes each step, writes intermediates, and logs results — all through this server. It’s the spine of container-based autonomy.

Install it if: You’re running Claude Code locally or on a server. Table stakes. Install it first, and scope the path tightly.

4. Fetch MCP Server

What it does: Arbitrary HTTP requests — GET, POST, PATCH, DELETE — to any API, with the response returned into context.

In JonOps: The catch-all for every API without a dedicated server. Metricool scheduling, Sendy sends, Telegram alerts, DataForSEO queries, WordPress REST calls. Highest raw call volume in my entire stack, by a wide margin.

Install it if: You use any REST API that doesn’t have its own server. Which is most of them.

5. n8n MCP

What it does: Connects Claude to your n8n instance — list workflows, read definitions, trigger executions, check logs, enable and disable workflows.

In JonOps: n8n handles newsletter routing, lead distribution, and third-party sync. When a content pipeline finishes and should kick off a send, Claude triggers n8n directly instead of waiting on a timer. Claude becomes the trigger layer rather than a node inside it.

Install it if: You run n8n and want Claude deciding when things fire. Full integration guide: n8n MCP for solopreneurs.

6. Airtable MCP

What it does: Read/write access to your bases — filter formulas, record creation, field updates, linked-table lookups.

In JonOps: Airtable is the source of truth for everything: content calendar, keyword queue, published posts, social queue, outreach leads, newsletter queue, image log. Every skill reads from it and writes back to it. Without this, Claude would be blind to what’s queued and unable to record what it finished. This is why JonOps has continuity across runs.

Install it if: Airtable is in your workflow. One caution from experience — paginated endpoints lie to agents that don’t turn the page. If a query returns exactly 100 rows, that’s a page cap, not a total.

7. Slack MCP Server

What it does: Post messages, create channels, read history, mention users, react.

In JonOps: End-of-run notifications, error alerts, status summaries. Telegram handles my mobile push; Slack is the team-facing audit trail a VA or collaborator can scroll.

Install it if: You use Slack, or you want a shared channel where Claude reports outcomes and escalates the things a human has to decide.

8. Memory MCP Server

What it does: Persistent storage across sessions. Store facts, decisions, project context, preferences; retrieve them next time without re-explaining.

In JonOps: This is what turns a stateless model into an operator. Every cron run loads brand config, recent posts, what’s published, what’s queued, what went wrong last time. Without it, every run starts cold and repeats yesterday’s mistakes. With it, the fleet compounds.

Install it if: You run anything recurring. If you only add one tool beyond the core three, make it this one.

Where to Find MCP Tools (And How to Vet One Before You Install It)

There are three places to go looking for MCP tools, in descending order of how much I trust them.

1. The official MCP registry. There’s now a canonical registry at registry.modelcontextprotocol.io with a public API. Every entry carries official metadata — a status, a published date, a last-updated timestamp — alongside the server’s declared name, version, and remote endpoints. That provenance is the whole value. A community list tells you a server exists; the registry tells you who published it and whether the listing is still active.

I paginated that API while writing this section, because I wanted a real number instead of a repeated one. I stopped counting at 40,000 entries and had still not reached the end of the cursor — 39,377 of those 40,000 carried an active status. So treat 40,000 as a floor, not a total. The relevant point isn’t the figure anyway: it’s that “there’s an MCP server for that” is now true by default, and the scarce resource has flipped from availability to judgement.

2. Community directories. mcpservers.org and mcp.so are both large, browsable, and organised by category — development, database, search, file system, communication, memory. Better for discovery than the registry, weaker on provenance. Use them to find candidates, then verify elsewhere.

3. The vendor’s own docs. If you want the Notion server, the Notion docs are the source of truth for its URL and auth flow. First-party servers are the safest category on the board.

The five-minute vetting checklist

Installing MCP tools means handing a third party a credential and letting your AI call its code. That deserves five minutes. Mine:

• Who publishes it? First-party vendor server, official registry entry, or a random GitHub account with eleven stars? These are not the same risk.
• Remote or local? A remote HTTP server means your arguments travel to someone else’s infrastructure. A local stdio server runs on your machine and can only leak what you give it. For anything touching sensitive data, prefer local.
• What’s the narrowest credential that works? Not “does it need write access” — “can I give it a token scoped to one repo, one base, one channel.” Almost always yes, and almost nobody does it.
• Read the tool descriptions before you trust them. The spec is blunt on this point: clients MUST treat tool annotations as untrusted unless they come from a trusted server. A tool’s own description of itself is a claim, not a guarantee.
• Does it need to be on all the time? Most don’t. Scope it to the one project that needs it.

The failure mode nobody warns you about isn’t a malicious server — it’s an over-permissioned honest one. A read-write token handed to a tool that only ever reads is a bad trade you make once and forget about for a year.

How to Install MCP Tools in Claude Code (2026 Commands)

Correction from the June version of this guide: I originally walked you through hand-editing claude_desktop_config.json. That still works, but it’s no longer the path I’d point anyone at. Claude Code has a proper CLI for this, and it handles the JSON, the scope, and the auth flow for you.

Remote HTTP server — the recommended option for cloud services:

# Basic syntax
claude mcp add --transport http <name> <url>

# Real example
claude mcp add --transport http notion https://mcp.notion.com/mcp

# With a bearer token
claude mcp add --transport http secure-api https://api.example.com/mcp \
  --header "Authorization: Bearer your-token"

Local stdio server — for anything that needs direct system access:

claude mcp add --transport stdio <name> -- <command> [args...]

A note on SSE: that transport is deprecated. Some services still only expose an SSE endpoint, but on current Claude Code you add them with the same --transport http command — it tries HTTP first and falls back to SSE automatically. Only reach for --transport sse explicitly on older versions.

Pick the right scope — this is the part people get wrong

MCP tools install at one of three scopes, and the choice controls both which projects see the tool and whether your credentials end up in version control:

Scope	Loads in	Shared with team	Stored in
Local (default)	Current project only	No	~/.claude.json
Project	Current project only	Yes, via version control	.mcp.json in project root
User	All your projects	No	~/.claude.json

Rule of thumb: project scope for the server, never for the secret. Commit the .mcp.json that tells your team which servers the project uses; keep the credentials in environment variables that .mcp.json expands at runtime. Local scope is the default and the right home for anything experimental or personal.

Two gotchas worth knowing before they cost you an hour

• A JSON entry with a url but no type is a configuration error. Claude Code reads a typeless entry as a stdio server, skips it, and tells you to add "type": "http". If you’re pasting config from someone’s README, check for that field first. (The spec calls this transport streamable-http; Claude Code accepts that as an alias for http, so copied config works unmodified.)
• npx-based servers need Node.js in the environment. Desktop usually finds it. Containers often don’t. In JonOps I pre-install server packages globally at image build time rather than letting npx cold-start on every cron run — that alone cut tens of seconds off each execution.

Verify any install by running /mcp in a Claude Code session. You’ll get every registered server, its connection state, and its tools.

Second correction, and this one’s a bigger deal. In June I wrote that you couldn’t use custom MCP servers with Claude on the web. That’s no longer true. Servers you add as connectors at claude.ai/customize/connectors now flow automatically into Claude Code when you’re signed in with a claude.ai account — they show up in /mcp marked as coming from claude.ai. One caveat that matters for headless setups like mine: connectors are only fetched when a claude.ai subscription login is your active auth method. If ANTHROPIC_API_KEY is set, or you’re routed through Bedrock or Google Cloud, they won’t load at all.

For the full walkthrough including environment-variable management and container-specific traps: the Claude Code MCP setup guide.

How Many MCP Tools Can You Run? (I Got This Wrong in June)

Here’s the claim I need to retract.

In June I wrote that every registered server adds its tool descriptions to Claude’s context window, so the practical ceiling was somewhere around 8–12 servers before you started eating the space your actual work needs. That was accurate when I wrote it. It isn’t anymore.

Claude Code now ships tool search, and it’s on by default. Instead of loading every tool definition at session start, it loads only tool names plus each server’s instructions, and pulls the full definitions on demand when Claude actually needs them. Anthropic’s own documentation puts it plainly: adding more MCP servers has minimal impact on your context window, and there’s no fixed per-server tool cap — the practical limit is your context budget.

So the honest 2026 answer to “how many MCP tools can I run” is: more than you think, and the number is no longer the interesting question.

What replaces it is selection quality — which MCP tools you run, not how many. A few things that actually still matter:

• Tool search needs a model that supports tool_reference blocks — Sonnet 4.5, Haiku 4.5, Opus 4.5, and later. On older models you’re back to upfront loading and the old ceiling applies.
• It gets disabled in some environments. Point ANTHROPIC_BASE_URL at a non-first-party host and Claude Code turns tool search off, because most proxies don’t forward tool_reference blocks. If you run through a gateway, check this before assuming you have headroom.
• Server instructions became load-bearing. With definitions deferred, the server’s instruction text is how Claude decides whether to go looking for your tools at all. If you’re publishing a server, say what category of work your tools handle and when Claude should search for them. Descriptions and instructions truncate at 2KB each, so front-load the important part.
• More tools still means more ways to pick the wrong one. Context pressure was never the only cost. Twenty overlapping tools with vague descriptions produce a model that hesitates, and hesitation in an unattended cron run looks like a hang.

My stack sat at eight for months because eight was what the work needed — not because I was rationing context. That reasoning happened to survive the change. The number I published did not, and I’d rather show you the correction than let a stale ceiling talk you out of a tool you need.

Which MCP Tools Do You Actually Need? (Matched to Your Business Type)

Now that context pressure isn’t the constraint, the temptation is to install every MCP tool on the board. Don’t. Every tool you add is a credential you’re responsible for and a decision surface the model has to navigate. Here’s how I’d sequence it by business type.

Content creators (bloggers, newsletter writers, course builders):
Start with Filesystem + Airtable + Fetch. Filesystem is where your drafts live. Airtable is your editorial queue. Fetch covers every API without a dedicated server. Add Playwright when you want real-browser competitive research.

Software builders and developers:
Start with GitHub + Filesystem + Fetch. GitHub MCP is the one that turns Claude Code from a coding assistant into something that opens PRs and manages issues. Add Playwright for automated testing.

Service businesses and consultants:
Start with Airtable + Slack + Fetch + Memory. Airtable holds the client pipeline, Slack handles comms, Fetch reaches your CRM and billing. Memory is the one people skip and shouldn’t — you want Claude holding each client’s context between sessions instead of relearning it every time.

Automation operators (the JonOps model):
You’ll end up with all eight. Add them in this order: Filesystem → Fetch → Airtable → GitHub → n8n → Memory → Playwright → Slack. Data layer, then action layer, then orchestration, then monitoring. Each addition should retire a specific place where you’re still the one clicking.

The honest 80/20: Filesystem + Airtable + Fetch covers most solopreneur use cases. Those three alone let Claude manage your content, your data, and your API calls. Everything after that is deliberate leverage, not completeness.

The selection rule hasn’t changed and I don’t expect it to: follow the friction. Don’t install speculatively. Install when you catch yourself thinking “I wish Claude could just push this” — then install the server that removes exactly that step. If you want to see where this ends up, I documented the full picture in what it actually takes to run a fully autonomous AI agent.

MCP Tools Security: What the Listicles Leave Out

Every roundup tells you which MCP tools to install. Almost none tell you what you’re accepting when you do. The spec itself is explicit, so let’s just read it.

What a server is required to do: validate all tool inputs, implement proper access controls, rate limit invocations, and sanitize outputs. Those are MUSTs. If you’re building a server, that’s your floor, not your aspiration.

What a client should do — and this is the list to hold your setup against:

• Prompt for user confirmation on sensitive operations
• Show tool inputs to the user before calling the server, specifically to prevent malicious or accidental data exfiltration
• Validate tool results before passing them to the model
• Implement timeouts on tool calls
• Log tool usage for audit purposes

Read the second one again, because it’s the one that should change your behaviour. The risk isn’t only that a tool does something bad — it’s that a tool receives something it shouldn’t. Arguments get composed by a model that has your whole session in context. A remote server sees whatever ends up in those arguments. That’s an exfiltration path, and it’s silent.

Three operator habits that fall out of this:

• Scope every credential to the narrowest thing that works. GitHub MCP can be limited to specific repositories. Airtable can be limited to one base. Start read-only, confirm the behaviour you expected, then widen. The default is almost always broader than the job.
• Treat tool metadata as untrusted input. The spec says clients MUST consider tool annotations untrusted unless the server is trusted. A tool that describes itself as read-only is making a claim about itself. Verify with a scoped credential rather than a hopeful one.
• Log everything, and check the log. Unattended agents fail quietly. Audit logging is in the spec’s client guidance for a reason — it’s the only way you find out that a tool has been failing for six days. My own rule after a few painful lessons: every autonomous run writes a structured result line, success or failure, no exceptions.

None of this makes MCP tools dangerous to use. It makes them infrastructure, which is exactly how you should treat anything holding a credential to your business.

Frequently Asked Questions About MCP Tools

What’s the difference between MCP tools, resources, and prompts?
Tools are model-controlled functions with side effects — Claude decides to call them. Resources are application-controlled data the client reads and attaches as context. Prompts are user-controlled templates, usually surfaced as slash commands. Shortest version: tools do things, resources know things, prompts start things.

Do I need to be a developer to use MCP tools?
No. Installing one is a single claude mcp add command, or a few clicks if you’re adding a connector in claude.ai. Getting the API credential for the underlying service is usually the longest step, and it’s a five-minute job for most services.

Are MCP tools safe? Can they delete my data?
They operate with exactly the permissions you grant. A read-write Airtable key means Claude can write to Airtable. A read-only key means it can’t. Start narrow, verify, then expand — and keep in mind the spec’s own advice that clients should show you tool inputs before a call and confirm sensitive operations.

Can I use MCP tools with Claude on the web?
Yes — this changed since the first version of this guide. Servers added as connectors at claude.ai/customize/connectors work in claude.ai and sync into Claude Code when you’re signed in with that account. On Team and Enterprise plans only admins can add them. The one gap: connectors don’t load in Claude Code if your active auth is an API key or a third-party provider like Bedrock.

How many MCP servers can Claude handle at once?
More than the old advice suggested. Tool search defers tool definitions until they’re needed, so extra servers cost very little context and there’s no fixed per-server cap. The real limit is your context budget and your own ability to keep the tools distinguishable from each other.

How do I know if a guide I’m reading is out of date?
Two quick tests. If it describes protocol version agreement as a one-time initialize handshake, it predates the 2026-07-28 revision. If it tells you to hand-edit claude_desktop_config.json as the primary install path, it predates the CLI. Neither makes the advice wrong, but both tell you how much has happened since.

What if there’s no MCP server for a tool I use?
Use Fetch to hit the REST API directly — that covers most cases — or build your own server. Building one is a matter of hours with the Claude Agent SDK, not weeks. Reach for Fetch first; build custom only when Fetch’s flexibility genuinely isn’t enough.

Do MCP tools work with anything other than Claude?
Yes. MCP is an open protocol with broad client support — ChatGPT, VS Code, and Cursor all speak it alongside Claude. That’s the actual argument for building on it: the server you write today isn’t locked to one vendor’s roadmap.

The Bottom Line: Start With Three, Stack From There

MCP tools aren’t magic. They’re infrastructure. And like all infrastructure, the payoff compounds in proportion to how deliberately you build it.

The honest JonOps take after months in production: the single biggest jump in leverage came from three tools — Filesystem, Airtable, and Fetch. Those three turned Claude from a conversational assistant into something that could complete multi-step work without me in the loop. Everything after was additive and intentional.

What changed since June is worth naming plainly. The protocol got a new revision with real production features. The context ceiling I warned you about got engineered away. Claude on the web went from “can’t” to “can.” Two of my own answers went stale inside three months, and I’d rather correct them in public than leave you optimising for a constraint that no longer exists.

That’s the actual lesson, and it outlasts any tool list: this stack moves faster than the guides written about it. Check the spec date. Check the CLI. Check whether the ceiling you’re designing around is still there.

Then start small. Install Filesystem, Airtable, and Fetch. Run one workflow end to end without touching it. Add the next tool when you hit the next bottleneck — not before.

The autonomous business doesn’t arrive overnight. But with the right MCP tools in place, every week it needs a little less of you. That’s the whole point.