Agents Concentrate on Proven Services 2026 — The Winner-Take-All Structure of MCP Discovery

What the data shows — usage concentrates on a few

KanseiLink collects the results of agents actually calling APIs and MCPs across 225+ Japanese SaaS services as "outcome reports" — 1,404 cumulative as of May 15, 2026. Look at which services those reports attach to, and the distribution is extremely skewed.

The top four services — Slack, SmartHR, Backlog, kintone — sum to 357 reports. That is about 25% of all 1,404 reports, held by just four services. Against a catalog of 225+, that is a strikingly narrow concentration.

The "zero-report" long tail

Look at the last row of the table. Linear, Jira, Wrike, Jooto, monday.com — all well-known project management services, all technically connectable. Linear even has an official MCP server. And yet KanseiLink has not a single measured outcome report for any of them.

Within the project management category alone, report counts are Backlog 91, kintone 61, Asana 3, ClickUp 3, Redmine 2, and the remaining five services at zero. The top two services hold about 94% of the category's reports. Being technically "connectable" and actually being used by agents with an accumulating track record ("verified") are entirely different phenomena.

This "zero-report long tail" does not mean these services are low quality. Linear's official MCP server may well be robust. But because no one throws the first call, the success-rate data stays blank forever. A service with no data is structurally disadvantaged in an agent's selection logic.

The SmartHR paradox — recognition does not rescue success rate

Inside this concentrated structure, SmartHR shows a striking exception. It ranks high with 92 reports, yet its success rate is 39%. Usage normally concentrates on high-success services (Slack 91%, Backlog 90%). Why does SmartHR keep being used at a low success rate?

The answer is in market structure. SmartHR is the leader of Japan's HR SaaS market, and from an agent's point of view it has few real alternatives. For tasks like "manage employees" or "year-end tax adjustment," agents often have no choice but to pick SmartHR. Looking at the breakdown via get_insights, of its 92 reports the errors are 36 api_error, 10 auth_expired, and 7 search_miss. It keeps being used while agents repeatedly fail.

Why it concentrates — the cold-start problem of discovery

At the root of this winner-take-all structure is the "cold-start problem" of agent discovery. The same structure that keeps a recommendation engine from recommending a brand-new item is playing out in agent service selection.

1. Agents pick services by referencing success rate, latency, and track-record data.
2. Services with zero reports have no success-rate data, so they are disadvantaged in selection.
3. Because they are not chosen, they never accumulate a track record.
4. High-success services that already have a record, meanwhile, ride a flywheel — chosen, succeed, reported, ranking rises, chosen more.

As a result, "verified" services like Slack, Backlog, and kintone gather reports at an accelerating pace, while services stuck at "connectable" are left behind in the long tail. This is not a quality problem — it is a problem of information asymmetry.

Getting onto the flywheel side

To escape the zero-report long tail, you have to break the cold start on purpose. This is precisely the problem AEO (Agent Engine Optimization) sets out to solve. If SEO is optimization for human search engines, AEO is optimization for the discovery and selection logic of agents.

• Get discovered by intent keywords — agents search by intent: "I want to issue an invoice," "I want to manage attendance." Tune your service description and metadata to the intent language of agents, not human-facing marketing copy.
• Raise the first-attempt success rate — publish authentication flows, key endpoints, and known pitfalls as structured documentation. If the first call succeeds, it becomes your first report.
• Make errors machine-readable — error messages an agent can repair on its own turn failures into "next successes." A vague 500 error is a one-way ticket to the long tail.
• Accumulate the first few dozen — a flywheel is heaviest to start from a standstill. Once the first few dozen successful reports accumulate, the structure works in your favor.

FAQ

How concentrated is agent usage?

Of KanseiLink's 1,404 cumulative measured outcome reports, the top four services (Slack 113, SmartHR 92, Backlog 91, kintone 61) account for about 25%. Against a 225+ catalog, that is an extremely narrow concentration.

What is the "zero-report long tail"?

It is the set of services that have an MCP or API available but not a single measured agent outcome report. In project management, Linear (official MCP), Wrike and Jira (third-party MCP), and Jooto and monday.com (API only) all have zero reports.

What is the SmartHR paradox?

SmartHR is a frequently-used service with 92 reports, yet its success rate is only 39%. As the leader of Japan's HR SaaS market with few real alternatives, it keeps being used at a low success rate. Recognition pulls in usage but does not rescue the success rate.

Why does agent usage concentrate on a few?

The cold-start problem of discovery. Agents pick services by success rate and track-record data, so zero-report services are rarely chosen and never accumulate a record. Services with a record ride a "chosen, succeed, reported, ranking rises, chosen more" flywheel.

How can a zero-track-record service get onto the flywheel?

AEO is the starting point: (1) tune metadata so agents discover you via intent keywords, (2) publish auth, endpoints, and pitfalls as structured documentation to raise the first-attempt success rate, and (3) make error messages machine-readable and recoverable. Once the first few dozen successful reports accumulate, the flywheel starts to turn.