MCP is becoming the distribution layer for the agent economy

MCP is becoming a distribution problem, not just a protocol problem.

That is the clearest takeaway from this week's agent conversation.

On June 17, Google announced Agentic Resource Discovery, an open specification for publishing, discovering, and verifying AI capabilities across the web, including MCP servers. Around the same time, X started converging on a sharper version of the same idea: if agents cannot find and call your capability, you effectively do not exist to them.

I think that framing is directionally right.

A lot of teams still treat MCP like plumbing. Useful plumbing, but plumbing. That misses the bigger shift. MCP is slowly becoming part of the way software gets discovered, selected, and used by agents. Not the whole layer. But enough of the layer that product, growth, and SEO people should care right now.

The thesis

The important shift is not that MCP makes tool calling easier.

The important shift is that MCP, registries, connector directories, and discovery specs are starting to create a new surface where agents decide what exists.

That is why this matters.

In the search era, discoverability meant ranking pages humans could click.

In the agent era, discoverability increasingly means exposing capabilities an agent can identify, trust, and invoke.

That does not replace websites or SEO. It adds a new layer on top of them.

What changed this week

This topic has been simmering for months, but June 17 made it much harder to ignore.

Three signals mattered.

1. Google and Microsoft both pushed the discovery problem into the open

Google's ARD announcement was the cleanest official statement of the new stack shape.

The core idea is simple:

capabilities get published in machine-readable catalogs
registries index those catalogs
agents query the registries or fetch catalogs directly
once a capability is discovered and verified, the runtime hands off to the native protocol, including MCP

That is not a niche implementation detail. It is a map of how the agent-facing web could work.

Microsoft amplified the same point on June 17 with its own ARD announcement framing discovery, not creation, as the bottleneck.

When two major platforms start saying the hard part is finding the right AI capability, you should pay attention.

2. X stopped talking about MCP like an engineer-only toy

The language on X shifted this week.

The strongest recurring framing was not "look what I built with MCP."

It was closer to:

the Claude connector directory is becoming a distribution channel
being installed is becoming the new being discoverable
if an agent cannot call your capability, it does not exist to that agent

That is a much more strategic conversation.

It turns MCP from an integration pattern into a go-to-market question.

3. The examples got more concrete

This week was not just abstract protocol hype.

The conversation was tied to shipping examples:

Upwork becoming available inside Claude was cited as evidence that connector surfaces are turning into transactional distribution
Pinterest examples showed multi-server MCP setups behind a registry with human approval for sensitive operations
Unreal Engine shipping native MCP support reinforced the idea that the winners will increasingly expose callable surfaces, not just dashboards
MCP registry conversations kept circling around governance, signing, approval, and discoverability rather than raw demo novelty

That combination matters. A protocol starts looking real when people stop debating what it could be and start arguing about where the control points are.

Why I think people are underestimating this

Most people still interpret MCP through the wrong frame.

They ask: "How do I connect my product to an agent?"

That is a useful question. It is not the biggest one.

The bigger questions are:

How will agents discover that my product exists?
What metadata will help an agent trust and choose it?
Which actions are worth exposing as callable capabilities?
What governance or human gate belongs between discovery and execution?
If discovery shifts to registries and catalogs, where does that change my distribution strategy?

That is the real layer emerging here.

MCP is part of the answer because it defines how capabilities can be exposed and invoked. ARD matters because it points toward how those capabilities get found. Registries matter because they become the indexes, directories, and trust surfaces in between.

Together, they start to look a lot less like plumbing and a lot more like distribution infrastructure.

This is the new SEO, but only in one specific sense

I used the phrase "this is the new SEO" in my SF notes because the urgency felt similar. But the analogy only works if you use it carefully.

I do not mean:

websites stop mattering
keywords stop mattering
content stops mattering
classic SEO gets replaced by connector spam

I mean something narrower and more important.

In the old web, discoverability depended on whether a search engine could crawl, interpret, and rank your page.

In the agent web, discoverability will increasingly depend on whether an agent can find, verify, and call your capability.

That is a different kind of optimization problem.

It overlaps with what I wrote in AEO is the new SEO, but it pushes the idea one level deeper. AEO is about being cited in answers. MCP-era distribution is about being usable inside workflows.

Citation gets you mentioned. Callable capability gets you executed.

That difference is huge.

What this means for builders and operators

I think there are five practical implications.

1. Products need an agent-facing surface, not just a human-facing interface

A lot of software is still designed around the assumption that a human user will arrive, click around, and operate the interface manually.

That assumption is weakening.

If the best path to value is predictable and repeatable, there is a good chance an agent should be able to reach it directly.

That does not mean every product needs a giant MCP project tomorrow. It does mean every product should be asking:

what are the highest-value actions we want an agent to perform?
what permissions and review gates do those actions need?
what would a clean capability surface look like?

2. Distribution teams need to think beyond page views

Growth teams are used to thinking in impressions, rankings, clicks, and conversion paths.

That still matters. But agent-native distribution introduces a new funnel:

listed or published
discoverable
trusted
callable
retained inside a workflow

Those steps look closer to platform distribution than classic content marketing.

3. Trust metadata becomes part of marketing

This is one of the weirdest but most important shifts.

In an agent ecosystem, the metadata around your capability becomes part of the persuasion layer.

Not just branding. Things like:

authentication model
permission scope
documentation clarity
approval requirements
reliability signals
trust manifests
registry reputation

That is not just security work. It is discoverability work.

4. The winners will expose outcomes, not raw APIs

Agents do not need every internal endpoint.

They need clean capability design.

The best MCP surfaces will not look like a dump of backend methods. They will look like opinionated outcome layers that map to real jobs-to-be-done.

That is where product taste matters.

5. Governance is not optional

One thing I liked about the Pinterest-style examples circulating this week was the use of human approval for sensitive actions.

That is the right instinct.

If agents become a serious distribution and execution layer, then signing, approval, scoping, registry hygiene, and auditability become part of the product.

Without that, the whole space turns into a trust tax.

The mistake I expect most companies to make

I think most companies will make one of two mistakes.

Mistake 1: They ignore the layer entirely

This will be common in companies that still think agent interaction is a novelty.

They will keep optimizing their website and app while exposing nothing callable, nothing structured for discovery, and nothing that lets agents do real work.

That is risky because the surface area where users make decisions is already shifting.

Mistake 2: They ship an MCP server and think the job is done

This is the opposite failure mode.

They treat MCP support like a badge.

But a bare MCP endpoint without discovery, capability design, trust, and governance is not a distribution strategy. It is a technical checkbox.

The companies that benefit most will be the ones that think through the whole chain:

how they get discovered
how they get trusted
how they get invoked
how they get retained inside repeated workflows

That is a product and growth problem, not just a protocol problem.

My broader take

We are still early enough that most MCP discussion sounds like developer tooling discourse.

That will not last.

The strategic question is bigger: where does demand get routed when software starts being chosen by agents as much as by humans?

This week made that question easier to see.

Google's ARD announcement gave the ecosystem a discovery narrative. X gave it sharper market language. Shipping examples gave it credibility.

Put those together and a pattern emerges:

websites are still for humans
search is still for humans and answer engines
registries, catalogs, and connector directories are increasingly for agents

If that pattern holds, then MCP is not just a protocol story.

It is part of the distribution stack for the agent economy.

What I would do now

If I were running product or growth for a software company, I would start with five questions.

What are the highest-value actions in our product that an agent could perform safely?
Do we have a clean, opinionated capability layer for those actions?
How would an agent discover and trust those capabilities today?
Where do we need a human gate, approval step, or scoped permission model?
If agent discovery grows fast, who on the team owns that surface?

You do not need to overbuild this.

But I do think you need to stop treating it like a side quest.

Because once agents become a real acquisition and execution surface, discoverability stops being a page-level concern.

It becomes a capability-level concern.

That is the shift worth watching.