Blog · Opinion

MCP connectors are the App Store moment for AI

By Muhammad Tayyab Ilyas · · 7 min read

The short answer

An MCP connector is to an AI assistant what an app was to the 2008 iPhone: a standard way for anyone to add a capability to a platform people already use every day. The Model Context Protocol gives every assistant the same socket, directories now list thousands of connectors, and one builder can ship a working integration in a day. The difference is that the user of a connector is increasingly another AI, which changes what good software looks like.

Why does this feel like 2008?

When the App Store opened, the phone stopped being a product and became a platform. The phone's maker no longer had to build every feature; anyone could ship one, and users installed what they needed. The Model Context Protocol does the same for AI assistants. A connector exposes a set of named tools, Claude or another client discovers them, and from then on the assistant can act in a system it was never built for.

The numbers moved fast in 2026. The public MCP registry passed roughly 17,000 to 20,000 indexed servers by August, and a community index of Anthropic's own catalogue counted 3,044 Claude integrations across its web directory and in-app catalogue by late September, up from a directory of a few hundred entries in June (sources below). Search interest followed: Semrush shows US searches for “claude connectors” at about 1,900 a month in September 2026, roughly triple what they were three months earlier.

What exactly is an MCP connector?

A connector is a remote MCP server: a small web service that publishes tools with names, typed arguments and a description of what each does. A client such as claude.ai lists the tools, asks the user before running anything that changes data, and calls them over HTTPS with OAuth sign-in. Nothing about the AI model changes. The capability lives in the connector.

MCP or a plain API: what is the difference?

An API is written for programmers who read documentation and write client code. An MCP server is written for a model that reads tool descriptions at run time and decides which to call. That shifts the design work. A good API is complete and flexible; a good connector is narrow, explains itself in plain language and makes the dangerous operations obvious. My retail connector, TillBridge, exposes nine tools and deliberately no delete and no raw query, because the model only needs the nine.

What did shipping six connectors teach me?

In the past few months I have built and run six MCP servers: a catalogue connector for a grocery's legacy till, a gateway for coding assistants, the connector for my multi-agent platform LoopCodeLab, one that drives a Debian desktop and a Windows machine, one that creates disposable sandbox VMs, and one that lets Claude supervise a team of xAI Grok Bots. Four lessons repeated across all of them.

  • Distribution is solved, trust is not. Adding a connector to claude.ai takes one URL. Deciding what it may do takes most of the design: who can sign in, which tools need confirmation, what gets logged.
  • Tool annotations are product decisions. Marking a tool read-only lets the assistant run it without asking. Marking a shell read-only by mistake would let it run unconfirmed. I pin the exact read-only set in tests.
  • OAuth is where builders get stuck. Most of the support questions around custom connectors are about sign-in, not tools. I wrote up the redirect URI mistake that costs people hours.
  • The most valuable connectors bridge things that have no API. A legacy till, a desktop, and a team of agents that can only be messaged in an app. That is where an assistant gains abilities nobody else offers.

Where does the analogy break?

The App Store had one gatekeeper, one payment system and one kind of user. MCP has none of those. Directories are fragmented across the official registry, vendor catalogues and community hubs, many listed servers are abandoned, and quality varies enormously. And the user is changing: when Claude supervises Grok agents through my bridge, one AI is consuming a connector on behalf of another. Software built for that reader needs smaller, sharper tools and very clear error messages, because the reader acts on them immediately.

What should a builder do now?

Pick one system your users already live in and that their assistant cannot reach. Expose the smallest set of tools that does the job, put sign-in and an audit log in from day one, and publish it where people look. The window is the same one early app developers had: the platform has users, the catalogue is still young, and a well-made niche connector stands out.

Sources

Questions people ask

What is an MCP connector?

A remote MCP server that publishes named tools to an AI assistant such as Claude. The assistant discovers the tools, asks before running anything that changes data, and calls them over HTTPS with OAuth sign-in.

Is MCP replacing APIs?

No. MCP usually sits on top of an API, a database or a command line. It repackages capabilities for a model that chooses tools at run time, so the design favours a few narrow, self-describing tools over a large flexible surface.

Is there an app store for MCP servers?

Not a single one. In 2026 there is the official MCP registry, vendor catalogues such as Claude's connectors directory, and community hubs. Discovery and quality control are still the unsolved part.

How long does it take to build a Claude connector?

A focused connector with a handful of tools can work in a day. Sign-in, confirmation rules, logging and failure handling are what take the time, and they matter most.

About the author. Muhammad Tayyab Ilyas is an Applied AI & Solutions Engineer in Barcelona who builds and operates MCP servers, multi-agent systems and the infrastructure under them. He has shipped six MCP connectors, from retail to multi-agent supervision.

Talk about a project More posts