“i really don't want to use your agent, i want to use my agent to use your thing.”

Ali Spittel on X, August 21, 2026

By August 23, the post had passed 629,000 views and 4,400 likes. Earlier that day, Zeno Rocha wrote that he now chooses some software by whether it offers an official MCP server; that post passed 111,000 views. Read Zeno Rocha’s original post.

These are two public anecdotes, not a market survey or a forecast. But the response makes one product question worth asking: are you building another agent for users to adopt, or making your service useful to the agent they already chose?

The distribution signal grew by more than 100×

Monthly npm downloads reported for the official @modelcontextprotocol/sdk package rose from 1.87 million in March 2025 to 191.92 million in July 2026.

Downloads include CI, caches, automated installs, repeat installs, and five API-reported zero days with no published explanation. They are not unique developers, active users, deployed servers, customers, successful tasks, revenue, or proof that a product needs MCP.

View source data and method
The distribution signal grew by more than 100×
MonthDownloads
March 20251,874,545
April 20254,212,709
May 202520,933,359
June 202516,837,593
July 202521,605,761
August 202524,658,353
September 202531,258,519
October 202531,805,028
November 202535,008,987
December 202538,516,712
January 202650,249,918
February 202671,656,771
March 2026141,911,796
April 2026140,092,905
May 2026153,164,130
June 2026165,176,305
July 2026191,923,439
npm download-count API The 518 public daily counts were grouped into 17 complete calendar months and reviewed August 24, 2026.

Some users want a second front door

Model Context Protocol, or MCP, is an open standard that lets compatible AI applications connect to outside data, tools, and workflows. A product can expose a bounded set of capabilities through an MCP server, and a user can connect that server to a compatible AI client. Read the current official MCP overview.

Think of the product as having two front doors. The human door is the interface you designed. The agent door is an MCP connection used through an AI application the person chose. Both lead to the same service, but each needs signs, locks, and a clear idea of what belongs on the other side.

Human front door

Person → product UI

Capture, explore, review

Agent front door

Person → chosen AI client → MCP

Ask, combine, automate

One product The same accounts, permissions, and data rules
The UI and MCP are complementary paths into one product. They should not create separate identity, permission, or data boundaries by accident.

The UI is not the loser

Raphael Schaad’s reply supplied the useful counterweight. An AI-native fitness service might expose data and tools from the start, he argued, but it would still need an excellent interface for capturing an activity. Without the activity, the agent has nothing valuable to use. Read Raphael Schaad’s original reply.

Use the UI where direct manipulation, visual judgement, confirmation, or data capture matters. Use MCP where a compatible agent should discover bounded tools and combine them with the user’s wider context.

Two doors should not mean two products. Both should inherit the same identity, authorization, tenant, retention, and safety rules. MCP is another product surface, not a route around those controls.

Treat MCP support as a product decision, not a badge

A viral post can reveal a question. It cannot answer it for your product. Before building a broad integration, test four smaller decisions:

Start with a real task

Find work users already ask an AI assistant to do with your data or service. Do not begin with protocol coverage for its own sake.

Expose the smallest useful surface

A few clear, bounded tools are easier to understand and protect than a mechanical wrapper around every endpoint.

Design the agent-facing contract

Tool names, descriptions, inputs, errors, and results are part of the experience. An official MCP server can still be hard for an agent to use.

Measure the task, not the announcement

Watch whether representative users can connect, finish the intended job, understand confirmation points, and recover from failure. Likes are not completion data.

The agent door is only useful if it opens cleanly

An MCP endpoint can connect and still be a poor product surface. A tool may be hard to discover, advertise an invalid or vague schema, or return a result that breaks its promise.

mcp-doctor v0.4.0 can start with a passive inspection. It connects to the local command or remote endpoint you choose and validates discovery, definitions, and schemas without calling any listed tool.

Inspect the target you already use:

Local STDIO server

mcp-doctor inspect -- node ./dist/server.js --stdio

Remote Streamable HTTP server

mcp-doctor inspect https://mcp.example.com/mcp

Use the result as a first contract check before you ask customers’ agents to rely on this surface.

Inspect the MCP surface your users will see

What the X signal does—and does not—say

The evidence is useful only if its boundary stays visible:

  • It shows that this idea earned unusual attention in one developer-heavy conversation.
  • It does not measure how many customers will switch, pay, or stay because of MCP.
  • It does not mean every user wants an agent path or that every workflow belongs in chat.
  • It does not show that MCP should replace your UI, API, CLI, or product-specific agent.
  • It says nothing about whether a specific MCP server is useful, safe, or well built.

The next step is not “ship MCP because a post went viral.” It is “test whether your users already bring an agent to this job, then give that agent the smallest reliable door.”

Let users choose the interface

Some products will still win through a focused built-in agent. Others will become more useful when they let a customer’s chosen agent reach a bounded part of the service. Many will need both.

If you add the second door, treat it like a real product surface: official, scoped, documented, and tested before users find the rough edges for you.

Sources and evidence limits

Engagement is a dated X snapshot observed August 23, 2026. Counts change and do not represent unique people, customers, or purchase intent.