Contents
- About the KanseiLink Dataset
- Overview: Three Tiers Across 225+ Services
- Law 1: Official MCP Server Advantage Is Decisive
- Law 2: Error Type Composition Sets the Success Rate Ceiling
- Law 3: Latency Compounds — Small Differences Become Large
- Category-Level AEO Gaps — Why They Form
- Three Principles for MCP Adoption
Figures in this article are from KanseiLink's evaluation dataset and early data collected April 13–14, 2026. Per-service success-rate measurements are still being accumulated (observing). Per-service data is retrievable via get_insights(service_id) from KanseiLink's MCP server. This article is published to increase transparency in KanseiLink's rating methodology.
About the KanseiLink Dataset
KanseiLink is an AEO (Agent Engine Optimization) rating agency for Japanese SaaS. KanseiLink grades are our own assessment based on a published methodology, and MCP call outcome data — latency, error types, and more — is being accumulated as AI agents interact with services through the KanseiLink MCP server.
Data density varies significantly: freee has 212 recorded calls, Slack 113, Backlog 91. Analysis below focuses on services with sufficient data for statistical confidence.
Overview: Three Tiers Across 225+ Services
KanseiLink classifies all tracked services into three agent-readiness tiers:
| Status | Definition | Representative services | Avg. success rate |
|---|---|---|---|
| verified 🟢 | Official MCP server + KanseiLink MCP handshake verified | Slack, freee, MoneyForward, Backlog | observing |
| connectable 🟡 | API/MCP exists but not yet battle-tested | Chatwork, kintone, Garoon, Sansan | observing |
| info_only ⚪ | Service information only, no agent connection data | Most niche vertical SaaS | No data |
The gap between verified and connectable is striking. This polarization is not about company size or marketing budget — it reflects the depth of commitment to the MCP implementation.
Law 1: Official MCP Server Advantage Is Decisive
The clearest signal in KanseiLink's data is the rating gap between official and third-party MCP implementations.
| Service | Grade | MCP Type | Success Rate | |
|---|---|---|---|---|
| MoneyForward Cloud | AA | Official | observing | |
| Slack | AAA | Official | observing | |
| freee | AA | Official | observing | |
| Backlog | AA | Official | observing | |
| kintone | AAA | Official | observing | |
| Garoon | AA | Official | observing | |
| Chatwork | A | Official | observing | |
| Salesforce Japan | C | Third-party | observing |
Two findings stand out:
① The top official MCP servers all sit at high grades. This isn't coincidence — these services implement authentication, error handling, and tool schemas in conformance with the MCP specification, maintained by the teams who know the API internals best.
② Services relying on third-party MCP servers lag in ratings. A third-party implementation — built against public API docs alone — is structurally slower to adapt. Internal API specification changes hit third-party implementers last.
The single most important variable in service selection is whether an official MCP server exists. Official vs. third-party shows a clear rating gap. No matter how feature-rich the underlying SaaS, depending on third-party MCP carries fundamental reliability risk.
Law 2: Error Type Composition Sets the Success Rate Ceiling
KanseiLink's error data goes deeper than a simple failure rate. The type of errors determines whether a low success rate is fixable or structural.
freee MCP Error Breakdown (212 calls)
- api_error: 15 events (79% of errors) — transient server errors, recoverable with retry
- auth_expired: 4 events (21% of errors) — OAuth 2.0 24-hour token expiry, fixable on the agent side
- timeout: 1 event — resolved by narrowing date range to 3 months
Slack MCP Error Breakdown (113 calls)
- api_error: 9 events (90% of errors) — recoverable with retry
- invalid_input: 1 event — resolved by switching from Block Kit to simple mrkdwn format
Backlog MCP Error Breakdown (91 calls)
- api_error: 6 events (67% of errors) — retriable
- search_miss: 2 events (22%) — resolved with Japanese keywords or category filter
- auth_error: 1 event — resolved by regenerating the API key
Auto-recoverable errors (api_error)
Transient 5xx responses and momentary outages. Implementing exponential backoff retry resolves these automatically. In KanseiLink data, api_error represents 70–90% of all errors across top services — paradoxically, a high api_error share in a high-grade service means retry logic is working.
Implementation-side fixes (auth_expired, invalid_input)
auth_expired is an agent-side token management problem. freee's OAuth 2.0 tokens expire every 24 hours — long-running workflows and overnight batch jobs require automated refresh logic. invalid_input signals a misunderstanding of the tool's API contract, resolvable by reading the spec or calling get_service_tips().
Discoverable failures (search_miss)
search_miss occurs when the agent can't locate the right service through KanseiLink's discovery. Japanese-language intent queries sometimes fail to surface the correct service. KanseiLink is actively improving indexing for Japanese intent patterns; on the service side, optimizing AEO metadata reduces this failure mode.
High-grade services have few errors beyond api_error. Each auth_expired or invalid_input represents a fixable implementation gap. Knowing the error type breakdown lets you diagnose exactly where your ceiling is and how to raise it.
Law 3: Latency Compounds — Small Differences Become Large
Average per-call latency across verified services:
- Backlog MCP: 128ms
- Slack MCP: 163ms
- freee MCP: 216ms
The 88ms gap between Backlog and freee feels trivial for a single call. But in real agent workflows:
- A single task triggers 10–50 MCP calls
- Cumulative latency at 10 calls: 1.3s (Backlog) vs 2.2s (freee) — already a 70% difference
- At 50 calls: 6.4s vs 10.8s — approaching typical agent timeout thresholds of 10–30s
When using freee MCP in a loop (e.g., bulk invoice creation), multiple calls per record accumulate rapidly. The one timeout event in KanseiLink's freee data was resolved by "narrowing the date range filter to 3 months." Query scope design is the first line of defense against latency-induced failures.
Category-Level AEO Gaps — Why They Form
Across the 23 categories KanseiLink tracks, AEO grades vary widely. The structural reasons are consistent.
High-AEO categories share these traits
- Communication (Slack AAA): Real-time messaging has clear agent use cases (send, receive, react). Long API history, developer-first culture.
- Accounting (freee AA, MoneyForward AA): Standardized data structures. AI reconciliation and journal entry have obvious ROI. Regulatory pressure encourages API openness.
- Project management (Backlog AA): Tasks, issues, and wikis are natural agent targets. Digital-native user base, developer-friendly culture.
Low-AEO categories share these traits
- Reservation management (all services MCP-free, max grade C): Customer-facing UI focus, low incentive to open APIs for external agents.
- Logistics / delivery (major players API-only): Proprietary legacy systems, no competitive advantage from API openness.
- Legal (e-signature ahead, business tools lagging): E-contract APIs are advancing, but contract management and legal research tools remain agent-inaccessible.
The gap is not determined by company size or engineering capability. It is driven by two factors: whether agent-side use cases are clearly valuable, and whether API openness creates competitive differentiation.
Three Principles for MCP Adoption
Principle 1 — Prioritize official MCP servers: Make "has an official MCP server" a hard requirement in service selection. Third-party MCP tends to lag in ratings and carries API drift risk.
Principle 2 — Design for authentication lifecycle: For OAuth 2.0 services (freee and others) with 24-hour token expiry, build token refresh into the workflow architecture from day one. Assume tokens will expire during long-running workflows.
Principle 3 — Implement per-error-type recovery: Exponential backoff retry for api_error, token refresh for auth_expired, alternative query strategies for search_miss. Three specific handlers cover the vast majority of failure modes observed in KanseiLink's dataset.
An AEO grade is a starting point, not a finish line. Even AAA-grade services see failures. Selecting high-grade services, building proper authentication flows, and implementing error-specific recovery logic — these three steps, stacked together, are where real workflow automation ROI materializes.