MCP and API: Findings from a Survey of 56 Business Systems on Integration Realities

A survey investigating the reality of external integrations in Japanese business systems using only public documentation has been released. In a report by Qiita’s songchong, the provision status of MCP and APIs (REST, SOAP, GraphQL, gRPC) was organized for 56 business systems used domestically. Published on September 2, 2026, the article is characterized by its strict adherence to comparisons based on primary source descriptions, without involving implementation or performance measurements.

The conclusion is clear. It points out that the order of consideration should be based on what the target system provides, rather than starting with the technology one’s own company wants to use. MCP is not a substitute for APIs. All 14 systems providing MCP also coexisted with APIs. REST, SOAP, GraphQL, and gRPC should not be understood under the single umbrella of “API” but as distinct standards.

MCP is not a substitute for APIs. All 14 systems providing MCP also provided APIs.

Based on this fact, the report by Qiita’s songchong attempts to organize the correct sequence for IT personnel to begin their tasks to avoid mistakes.

Conclusions and Overview from the 56-System Survey

The survey covered 56 Japanese business systems, spanning business domains including CRM and cloud accounting. Integration methods publicly available in each product’s official documentation were confirmed. The methodology was limited to reading public materials, with no actual invocation, speed, or stability testing conducted.

The author frames the issue around typical consultations from small and medium-sized enterprises. These include requests from accounting departments for client integration, inquiries from management about leveraging AI agents, and concerns from general affairs departments about data flow safety to clouds and AI. When these requests come simultaneously, terms like MCP, REST, SOAP, GraphQL, and gRPC become mixed, making it easy to lose the starting point for investigation.

The proposed solution is to start with what the counterpart provides. Instead of deciding one’s own technology first, the approach is to check the availability and type of interface provided by the integration target, and only then make one’s own selection. For readers needing urgent verification, the article consolidates a list of 15 systems co-providing API and MCP in Chapter 5 as a practical consideration.

16 Definitions and Primary Information to

Prevent Confusion The article states that the multitude of terms is a cause of confusion and defines 16 items in a single line each, including links to primary information. All definitions are based on official specifications or RFCs.

API stands for Application Programming Interface, referring to a reception window for calling other systems from a program. REST is short for REpresentational State Transfer, a calling method that points to objects via URLs (e.g., /customers/123) following HTTP conventions. There is no formal specification; it refers to Fielding’s paper (2000) and RFC 9110 for HTTP itself. SOAP, from version 1.2 onwards, does not expand the acronym; it is a method of sending XML-wrapped messages to a single entry point, based on W3C SOAP 1.2.

GraphQL is a proper noun, a query language where the caller specifies desired fields, referencing the GraphQL specification. gRPC stands for gRPC Remote Procedure Calls, a method where code is generated from definition files for invocation, often used within corporate systems. MCP stands for Model Context Protocol, a common description format for informing AI what it can do; this article references the MCP specification dated July 28, 2026.

OpenAPI, formerly Swagger, is a format for describing REST API blueprints in a machine-readable form, referencing OpenAPI 3.2.0. WSDL is the Web Services Description Language, equivalent to a blueprint for SOAP, referencing WSDL 2.0. JSON-RPC stands for JSON Remote Procedure Call, a protocol describing function calls in JSON, with JSON-RPC 2.0 positioned as the foundation of MCP.

OAuth is Open Authorization, a mechanism for granting specific operational permissions without passing a password, referencing RFC 6749 (2.0) and the OAuth 2.1 draft. API keys are a single-string authentication method, limited to the scope defined at issuance—a key difference from OAuth. Some, like kintone, allow narrowing per app or operation, but many grant near-full privileges with a single key.

Statelessness is the property of not remembering previous calls, requiring all information to be sent each time. JSON Schema is a format for describing data shapes, used in MCP to describe input/output of functions. Protocol Buffers are the data shape and invocation definition format used by gRPC. 429 stands for 429 Too Many Requests, an HTTP response indicating excessive transmissions within a certain time, based on RFC 6585. AI agents refer to AI that, given an objective, autonomously decides what to invoke and acts.

Four Connection Pathways Linking MCP and API

The article organizes the relationship between MCP and API into four connection pathways. Solid lines represent prepared routes; dotted lines represent possible but circuitous routes.

First, connection from a program to an MCP server is possible. Since MCP is a communication protocol, it can be called from human-written programs. However, the list published by an MCP server is filtered for AI use, so for comprehensive operations required in typical business integration, APIs are often more suitable.

Second, connection from an AI agent to an API server is also possible. Most traditional AI integrations were built this way. However, it requires humans to pre-teach which APIs to call and with what parameters.

Third, connection from an AI agent to an MCP server is the originally intended pathway for MCP. The MCP server publishes a list of functions at the entry point, allowing AI to discover and use what it can do autonomously. This eliminates the need to pre-teach individual invocation methods, a key difference emphasized from API-based approaches.

Fourth, connection from a program to an API server is the fundamental pathway for business system integration. Regardless of the pathway, the underlying business system itself is the same, and constraints such as write permissions, rate limits, authentication, and terms of service remain applicable. Routing through MCP does not relax these restrictions.

This organization aims to correct misunderstandings like “AI can only use MCP” or “programs can only use APIs.” It shows that both are mutually callable and should be differentiated based on purpose and exposed scope.

Comparing Five Standards on Equal Footing

The article does not lump APIs together but places REST, SOAP, GraphQL, gRPC, and MCP side-by-side for comparison on the same metric. A key comparison axis is whether the function list is exposed at runtime.

MCP, in a form like tools/list, has the entry point itself announce “what operations are provided.” The caller can obtain the list without prior knowledge. In contrast, while description mechanisms exist for REST or SOAP (OpenAPI, WSDL), they are for humans or tools to read at design time, not a mechanism for the counterpart to self-announce at runtime. GraphQL has type introspection, allowing queries about available types, but its purpose differs from MCP’s self-describing operation list.

This difference directly impacts whether an AI agent can autonomously discover operations. MCP assumes runtime self-description, enabling agents to dynamically grasp options. In contrast, descriptions for REST etc. assume pre-shared design documents, requiring a separate step to teach the agent.

Furthermore, the underlying infrastructure for communication and description differs. REST is based on HTTP and URL design; SOAP on XML messages and WSDL; GraphQL on query languages and schemas; gRPC on Protocol Buffers and code generation; MCP on JSON-RPC 2.0 and JSON Schema. Authentication commonly involves OAuth 2.0 or 2.1, API keys, etc., but granularity of permissions and operations vary by product. The handling of rate limiting via 429 also depends on the business system’s policy.

Coexistence Reality Shown by 14

Dual-Support Systems All 14 systems providing MCP in the survey also provided APIs without exception. This fact indicates that MCP is not replacing APIs but is provided as an added AI-oriented interface on top of APIs.

According to the article, operations exposed by MCP servers are often a subset of the full functionality available via APIs. Bulk updates, administrative operations, and detailed search queries inherent to business systems might only be available via APIs. MCP, filtered for AI, tends to be limited to high-frequency operations like reference, registration, and updates.

Therefore, for typical system-to-system integration, batch processing, or automating existing business workflows, APIs will continue to be central. For use cases involving instructing an AI agent via natural language, MCP is suitable. The article organizes them as not competing but coexisting based on purpose.

From an IT personnel’s perspective, it proposes first checking via public documentation whether the integration target provides only APIs or also coexists with MCP, then confirming authentication methods, rate limits, and write permissions. Especially regarding security, to address concerns about data flow to clouds and AI, accurately understanding differences in authentication methods, permission scopes, and contractual constraints is essential. The difference between OAuth’s scope limitation and API key’s blanket authentication, stateless invocation characteristics, and handling of 429 responses directly impact operational design.

Consideration and Implementation Sequence for

On-site Teams The article refrains from implementation, focusing on providing decision-making materials based solely on public documentation. Therefore, it contains no evaluation of performance or stability. What it proposes as the sequence for on-site teams concerns prioritization at the stage of reading public documentation.

First, confirm which of REST, SOAP, GraphQL, or gRPC the counterpart uses to expose APIs. Clues like the presence of OpenAPI or WSDL, GraphQL schema publication, or gRPC definition file availability will influence integration effort and required technical elements.

Second, check for the availability of MCP. Even if MCP is provided, it should be assumed that APIs coexist. Compare the scope of operations possible via MCP with those via APIs. Determine whether operations intended for the AI agent are fully covered by MCP or if gaps need to be supplemented via APIs.

Third, verify authentication and limitations. Compliance with OAuth 2.0 or 2.1, API key issuance units, scope granularity, 429 thresholds, and retry policies are directly linked to operational failures and information leakage risks. To address concerns from general affairs departments, it is necessary to confirm from both contractual and technical specification perspectives which data flows externally via which route.

As AI agent autonomy increases, integration design goes beyond mere technology selection. The characteristic of agents autonomously discovering and executing operations influences delegation of authority and auditing. In this regard, it can be seen as overlapping in design philosophy with discussions on the tension between autonomy and control, as argued in Anthropic Mythos Export Restrictions, Risk of Treading the PGP Path, and the interaction between real environments and models, as shown in Real2Sim Replaces Sim2Real, NVIDIA and Li Fei-Fei’s New System. Furthermore, regarding foundational implementation technology, processes like open implementations becoming standardized and spreading, as with Mesa Rusticl, Standard Activation of Mali Panfrost, can be considered valuable reference points for thinking about the spread of integration standards.

Editorial Opinion

In the short term, we foresee the inclusion of “MCP availability” as a checklist item when selecting business systems becoming more prevalent. The coexistence reality of 14 out of 56 systems indicates that MCP is not emerging as a standalone new standard but as an AI-oriented extension of existing APIs. Within a 3-6 month span, we evaluate that MCP compatibility columns will be added to RFPs and comparison tables, and scenarios where the distinction between API and MCP is discussed from the initial requirements definition stage in PoCs assuming AI agent integration will increase. In the long term, there is a possibility that the initiative in integration will shift from pre-sharing design documents to runtime self-description. If methods like MCP, which publish function lists at the entry point, become widespread, the operation of agents dynamically discovering and reconfiguring business workflows becomes a realistic prospect. On the other hand, questions will arise regarding the scope of operation limitation, auditing, and permission management. The industry consensus on how far to expose the broad operations held by APIs to MCP will evolve over 1 to 3 years as a balance between convenience and control. The editorial team’s question concerns who should be responsible for designing the exposure scope. MCP’s self-descriptiveness enhances AI autonomy but also increases the risk of erroneous operations and excessive delegation of authority.

References

• “MCP vs. API（REST・SOAP・GraphQL・gRPC）どれが使える？ 日本の業務システム 56 件を調べてみた”, by songchong — Qiita, 2026-09-02T19:42:43.000Z (ARR)
• Source URL: https://qiita.com/songchong/items/64a8710cffb39963c2b3?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items