The models get the headlines. MCP does the work.
August 2025
When I wrote Demystifying MCPs in August 2025, MCP was still new. I’d just talked through my “aha” moment with it on Supra Insider, and I was an early adopter in the most literal way: I was mostly running the local Memory MCP, fetch, and a few others Anthropic rolled out in their initial release and that Fleur supported.
This was by and large the biggest leap I took with AI in terms of actually feeling confident doing higher-impact work and feeling like it was both more efficient and more valuable.
Now
Fourteen months later, building one isn’t the hard part. Anybody can have Claude build an MCP: hand it an API’s documentation, or describe something you want to do, and you’ll have a working server. Not all of them are useful. Some are hyper-specific, and a lot of them weren’t built with much intent. That’s why I’m revisiting this. The question has moved from what exists to how you evaluate what you add: how it authenticates, what data it can reach, and whether there’s anything malicious inside.
Those directory counts tell you nothing now. On 15 October 2026, Glama’s registry alone listed 98,928 MCP servers, and Smithery listed 26,758+. The official TypeScript SDK was downloaded 273,345,683 times on npm between 13 September and 12 October 2026, and the Python package 235,193,557 times on PyPI in the month to 15 October. In July, the MCP team said its Tier 1 SDKs were seeing “close to half-a-billion downloads a month.” Nobody needs a bigger directory from me.
The counts, October 2026
98,928
MCP servers in Glama’s registry
26,758+
MCP servers on Smithery
273M
npm downloads of the TypeScript SDK in a month
235M
PyPI downloads of the Python package in a month
How I use them has changed completely. MCP is now a heavy factor when I choose a tool for the entire organization. If I’m evaluating competitors and one has a really well-written MCP and really well-written developer docs and tools, I’m more likely to pick that one.
So the question isn’t which servers exist anymore. It’s which few you’ve wired in on purpose, by name, with the tool calls spelled out.
In this post
The argument
The models get the headlines. MCP does the work.
I’ll argue this one to my grave: regardless of model, AI is at least 50x more valuable when it’s connected to the tools you use, both for context and for actually getting the work done.
Before that, AI was fun and semi-useful. There was a lot of copying and pasting, downloading files and uploading them again, and everything you fed it went out of date fast. Once it can check real-time information in the tools your whole team or organization already uses, it replaces the real time people had to put in to get the work done.
Everybody has been pushing new models and model variations out back-to-back-to-back, and that’s what gets the headlines. What makes those models really powerful at work is buried underneath: the connection to your actual systems.
That connection is now everywhere. In December 2025 Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI. By August 2026 it counted 242 member organizations, including Visa, Wells Fargo and Alibaba. And every major agent speaks it:
Claude
calls them connectors. There’s a Connectors Directory, and you can add any custom connector by its remote MCP server URL.
ChatGPT
lets you connect custom MCP servers and calls them apps and connectors. Full MCP is limited to Business and Enterprise/Edu for now.
Gemini CLI
configures MCP servers directly.
GitHub Copilot in VS Code
Grok, through xAI’s API
That’s the step between casual AI use and higher-impact AI use at the business or enterprise level: the model stops working only from what you paste in and starts working inside the systems where the work lives.
A quick aside: where consumers are
Before the builder pitch, look at where people already spend their AI time. ChatGPT is at 1.2B weekly users, per OpenAI in September 2026. Google’s Gemini app passed 1 billion monthly users in August 2026, which Google calls the fastest-growing product in its history. Anthropic doesn’t publish Claude user counts, but it told TechCrunch in March that paid subscriptions had more than doubled that year.
1.2B
ChatGPT, weekly users
1B+
Gemini app, monthly users
Not published
Claude user counts
What none of the three publishes is how many of those people have connected an app or an MCP server. So nobody can tell you the connector share yet. What you can see is where the vendors are putting their effort: directories, app stores and connectors, front and center.
For builders
If you’re building a product, MCP is a requirement
This one’s for the builders. Whether you ship a consumer app, a developer tool or B2B software, more and more of your users’ work is happening outside your product, inside an AI assistant. OpenAI is now inviting developers to launch “native experiences” right inside ChatGPT.
The companies that saw this early are already in the room. Booking.com, Canva, Coursera, Figma, Expedia, Spotify and Zillow were the pilot partners for apps in ChatGPT, and that Apps SDK “builds on the Model Context Protocol.” GitHub maintains its own MCP server. Atlassian’s MCP server works with ChatGPT, Claude, Gemini and GitHub Copilot. Notion recommends its remote MCP server for most clients.
And it isn’t just text anymore. In January, MCP Apps became the protocol’s first official extension: a tool can return a real interface, like a form, a chart, a map or a document viewer, that renders right in the conversation in a sandboxed frame. Claude, GitHub Copilot in VS Code, Microsoft 365 Copilot and Goose all render them. ChatGPT implements the same standard, and OpenAI now tells developers to build on MCP Apps first and use its ChatGPT-only APIs only for extras the standard doesn’t cover.
That’s the momentum signal I’d pay attention to. OpenAI and Anthropic now share one way for your product to show up inside their assistants, and in July’s spec release, extensions like this became a formal part of the protocol. You build the interface once, and it isn’t a bet on a single vendor.
Remember which side of the table I’m on, too. When I’m choosing a tool for the whole organization, a well-written MCP and well-written developer docs make me more likely to pick you.
So put it in the requirements:
01
A remote server with OAuth, so people can add you from a connector directory instead of a config file.
02
Tools built around jobs, not endpoints. OpenAI’s own guidance says great apps “don’t try to recreate the entire product”; they give users a few specific powers.
03
Docs a model and a developer can both read. That’s the bar I judge you on.
04
A listing in the Claude and ChatGPT directories, so your customers find you where they already work.
For product teams
Designing an MCP is a product job
The trust section below is mostly about security. This part is about design, and it belongs to the product team, not just engineering. You’re designing for someone who asks for things in sentences, through an agent. That’s a very different process than designing a UI.
How will they ask?
Don’t map your MCP one-to-one to your screens or your API. Anthropic’s engineering team calls that “a common error”: tools “that merely wrap existing software functionality or API endpoints.” Their example: instead of separate list_users, list_events and create_event tools, build one schedule_event tool “which finds availability and schedules an event.” Start from the request a user would actually type.
What’s tedious in your UI?
Look for the complex things people do that feel like busywork but are just a requirement of a typical UI. Setting up a Jira epic with all its tickets, details and links is my example. Those are often easier through an API, and they’re exactly what people will hand to an agent first.
What context does the agent get?
Your tool names and descriptions are the agent’s only map. Anthropic notes that tool descriptions are “loaded into your agents’ context” and “can collectively steer agents toward effective tool-calling behaviors.” Write them so the agent knows exactly which tool to call, for what, and with which inputs.
How much of their usage will you burn?
Every tool you expose and every response you return costs the user context. Fewer, well-scoped tools “reduce the number of tools and tool descriptions loaded into the agent’s context.” Return what’s relevant, not every field you have; Claude Code itself caps tool responses at 25,000 tokens by default. If connecting your MCP eats someone’s weekly usage, they’ll disconnect it.
Does it need a screen?
Now that a tool can return an interface, decide where one actually earns its place. The MCP Apps docs point to exploring complex data, configuring something with a lot of interdependent options, viewing rich media, live monitoring, and working through items one at a time, like approvals. Everything else can stay a sentence. And keep every tool useful without the UI: OpenAI’s guidance is that the model should still be able to finish the workflow in clients that don’t render it.
The landscape
The kinds of MCP you’ll run into
MCP isn’t one thing anymore. Inside the same client you can have:
Local servers
that run on your machine: your files, a database, a dev tool.
Remote services
the connectors that reach Jira, Slack, Granola or Figma on the vendor’s side.
Servers that call other models.
Some MCPs hand part of a task to a different model that’s better at it.
Websites themselves.
This is the newest one, and it’s moving fast.
WebMCP: the website is the tool
WebMCP is a proposed web standard that lets a site expose structured tools to AI agents, through JavaScript or annotated HTML forms, “so that agents know exactly how to interact with page features.” Instead of an agent squinting at your UI and clicking buttons, the page tells it what it can do: here’s search, here’s add to cart, here’s the input I need. The tools run on the page itself, visibly, so the user can see what happened.
The tooling is arriving quickly. Google’s Chrome team publishes WebMCP Skills, a set of agent skills for designing, evaluating, auditing and implementing WebMCP tools, last updated 16 October 2026.
It also left the lab this year. Chrome opened a public origin trial in Chrome 149, so sites can run WebMCP for real visitors instead of only behind a developer flag, and in September Google extended it through Chrome 162 after feedback from the first round led to API changes. Microsoft opened its own trial in Edge 150. On the agent side, ChatGPT’s desktop browser now calls WebMCP tools, which it calls site tools, from ChatGPT Work and Codex.
Commerce is where this gets real first. On August 5, Shopify switched WebMCP on for every Liquid storefront, with nothing for merchants to install. An agent in the shopper’s browser can call tools like search_catalog, get_product, update_cart and proceed_to_checkout, all in the tab the shopper is looking at. In October, Commerce.com and Cloudflare turned on WebMCP shopping tools across Commerce.com’s storefronts, almost 100,000 domains, with an opt-out for merchants. Shopify also keeps a server-side endpoint, its Universal Commerce Protocol endpoint at /api/ucp/mcp, for agents that connect to a store directly. A store can now be reached both ways.
It isn’t settled. Apple’s WebKit team opposes the proposal, arguing agents should use sites the way people do and that the fix belongs in HTML and accessibility work. Mozilla is neutral until there’s more evidence of how sites use it. And Google said in May that Gemini in Chrome would support WebMCP “soon,” without a date. But Shopify and Commerce.com aren’t waiting for the standards debate to end, and that’s the part a product team should notice.
Try this: open your agent, give it a website, and ask how it can interact with the site without using the UI. When I do that with David’s Bridal, it can search for products, pull prices and even add to cart.
For product teams, it’s the same lesson as the builder section.
Your website is already an interface for agents, whether you designed it as one or not.
Before you install
Not every MCP deserves the same trust
Keep using them. Just know which kind you’re adding, because there are two, and they aren’t equally safe.
Generally safe
Connectors from a marketplace or a URL.
The ones approved in a directory, and the remote ones you add by URL endpoint, run on the vendor’s side and sign you in with a secure method like OAuth 2. They’re generally pretty safe and well controlled. Firecrawl is a good example: it’s in the directory now, and it also gives you a remote server URL that handles OAuth if you’d rather add it as a custom connector. That’s where a lot of teams start when they’re testing. One caveat from Anthropic’s own docs: verification “isn’t a security audit.”
Be careful
Servers you download and run locally.
The more dev-focused ones you add by hand in a config file run on your machine, with your permissions. That’s where you need to be careful. The official MCP security guidance warns that a malicious startup command in a client config means “arbitrary code execution.” In September 2025, Snyk reported that an npm package called postmark-mcp had been modified to secretly blind-copy email contents to an outside domain.
Before you install a local one, ask:
- Who built it, and is anyone maintaining it? An official server from the vendor beats something hyper-specific nobody has touched in months.
- How does it authenticate? OAuth, an API key you paste into a config file, or nothing at all? Where does that key end up?
- What can it read, and what can it do? Read-only or write? Which accounts and which data? If it can send, delete or post, know that before your agent does.
- What exactly runs? Read the command in the config and skim the code before you run it. The MCP guidance says a client should show you “the exact command that will be executed.”
- Can you start smaller? Start read-only or in a test account, pin the version so an update can’t change it under you, and add write access once you trust it.
If you’re not savvy enough to answer those, don’t install it yet. Find the directory version, or ask someone who can review it.
My setup
What I actually wire in
I’ve always hated going into Jira and manually configuring a new epic: the tickets, the details, the links. I always miss something. With the Atlassian connector, I build all of it from the requirement spec. And when I research, debug or investigate something, I can put what I found into the existing ticket, or check that there’s a ticket at all. That’s a huge lifesaver.
That gets even more useful with Claude Code. Even when the dev team is doing the work and I’m only investigating something based on what I see, the findings can still go straight into the ticket.
Outside Jira, I use a handful of MCPs to grab context from email, my Granola meeting notes and Slack, then compile and organize the key details. The next day, or whenever I go back to reflect, I know where that information lives, what it means in practice and what I’m doing with it.
Name the MCP and the call
This is the part that still matters most. Not “search my notes.” Granola MCP. Not “get my meeting notes,” but “call list-meetings for yesterday, then fetch-transcript for each.” A year ago I told you to put the same idea in your system prompt: “If I ask you to ‘find an issue’ I want you to use your Linear MCP to find the most relevant issue based on the context.” Mention the MCP you want right in the prompt or the conversation, and Claude doesn’t have to go shopping for it.
Know the subtleties before you trust it
Don’t get overly confident that an MCP will let you do everything. Figma is a good example. I use the Figma MCP almost daily, and to get assets and details from Dev Mode, the Figma desktop app has to be open and running. From the browser alone, I really only get a screenshot. Whether you’re in Claude Design, pulling Figma into Claude Code, or generating from something you’re working on, the details differ by server. Figma documents which tools run where. Read it first.
Do this this week
Open your connectors and make a list: every server you have on, and the tool calls you actually used from it in the last two weeks. Anything with no calls next to it, turn off. Then pick the one you use most and write its calls down, in your system prompt or a Skill, as “when I ask for X, call this server’s that tool.”
You don’t have to do the inventory by hand. Paste this into a new conversation:
List every MCP server and connector you have access to in this conversation, and every tool each one exposes, one line per tool. Don’t call any of them. Then ask me which of these I’ve actually used in the last two weeks and what for. From my answers, write a short instruction block I can paste into my system prompt or a Skill, one line per job, in the form “When I ask for X, call [server]’s [tool].” Leave out anything I haven’t used. Stop there. Don’t change any settings or connect anything.
It lists, it asks, it writes. It doesn’t toggle anything for you. Then test the block before you save it: ask for X a few different ways in a fresh conversation and check it calls the tool you named every time.
The cost
Collecting servers costs you context
The old way MCP loaded used a ton of your context. Every connected server’s tool definitions went into every conversation before you’d typed a word. Anthropic’s engineering team wrote that agents connected to thousands of tools “need to process hundreds of thousands of tokens before reading a request.”
The platforms have started fixing that on their side:
Anthropic
rolled out the Tool Search Tool in November 2025, so Claude finds tools on demand instead of loading them all. In their tests that was “an 85% reduction in token usage,” and Opus 4.5 went from 79.5% to 88.1% in their accuracy evaluation. In Claude Code, tool search is on by default: only tool names load at the start.
OpenAI
has its own tool search in the API, which loads deferred tools “at runtime so models only import the definitions they need.”
Gemini CLI
lets you allowlist or block specific tools per MCP server.
And people are attacking it from the outside.
Caveman, a Claude Code skill that “cuts 65% of tokens by talking like caveman,” had 103.3k GitHub stars when I checked on 15 October 2026. It trims the model’s output, not your tool definitions.
Headroom, at 75.4k stars the same day, compresses tool outputs, logs and files before they reach the model.
What I do on my end comes down to two habits:
- Plan ahead. Decide which servers a task needs before you start, and name them.
- Use subagents. In Claude Code, each subagent runs in its own context window, so the noisy tool output stays there and only the summary comes back.
There’s a lot more to what I actually do for context. If you want a full post on it, reply and tell me.
The limits
Where MCP stops
MCP only reaches what a vendor exposes. When a company hasn’t built a good server, or the server can’t do the thing you need, you hit a wall.
That’s why the same companies pushing MCP are also building browser use and computer use. Anthropic made Claude in Chrome generally available on every paid plan in August 2026, pitched at the tools that don’t have connectors: “internal dashboards, legacy systems, and vendor portals.” OpenAI’s ChatGPT agent pairs connectors with its own virtual computer. Google’s Gemini 2.5 Computer Use model exists because, in Google’s words, “many digital tasks still require direct interaction with graphical user interfaces.”
So here’s what I want to know: how many MCP servers do you have connected right now, and how many of them could you name a tool call for? Reply with both numbers. I read every reply.
Mike Bal is Head of Product and AI at David’s Bridal and sits on its executive leadership team. He’s building Pearl Planner — an AI-native wedding planning platform. He writes about product management, AI implementation, and building your command center at mikebal.com.
Resources
Related Leading Product posts
- Demystifying MCPs — the August 2025 post this one follows up
- How MCP enables AI to know you better — my Supra Insider conversation, back when MCP was new
- I Overlooked Agent Skills — where the named tool calls actually live
Worth reading
- Introducing advanced tool use (Anthropic) — the Tool Search Tool and its numbers
- Security Best Practices (MCP) — read before you add a config-file server
- MCP Apps (MCP) — how a tool returns an interface, with working examples
- WebMCP (Chrome for Developers) — the proposal, the origin trial and the testing tools
- Caveman and Headroom — two open-source takes on cutting context