Model Context Protocol gives AI applications a shared way to access tools and data. A company can expose one integration to several assistants, reducing the need to build a separate connection for each. MCP can sit above an existing API. The underlying system still checks permissions, retrieves an order or saves a change. MCP specification.
At Lazarus Systems, we see MCP as a strong candidate for a common AI integration standard. We expect it to coexist with REST, GraphQL and internal services. How widely it will be adopted remains uncertain: a shared protocol helps connect a tool, while tool design and client support determine how useful that connection is.
How MCP works
The user works in a host application. Its MCP client communicates with a server that exposes capabilities. That server can run on the same machine or remotely. The documentation describes two transports: stdio for local processes and Streamable HTTP for network communication. MCP architecture.
A server can expose tools, which execute operations; resources, which provide context; and prompts, which supply interaction templates. An order lookup could be a tool, product documentation a resource and a report brief a prompt. The application discovers tools through tools/list and invokes one through tools/call. MCP tools.
MCP, APIs and OpenAPI serve different purposes
An API defines how software interacts with a system. OpenAPI describes HTTP interfaces in a format that people and programs can read, covering operations, parameters and responses. That description can support documentation and API client generation. OpenAPI specification.
MCP adds a shared contract between an AI application and a provider of tools and context. An MCP server can call an existing CRM API, query a database or run a local program. Architecturally, it often provides another interface to services already in place. Connecting an assistant rarely justifies rewriting an entire backend.
Consider a hypothetical order-support integration. The shop API exposes dozens of operations. For an assistant handling returns, we would design three narrow tools: retrieve order status, check return eligibility and create a draft support request. Each would have defined arguments and results. Issuing a refund would remain a separate operation with its own access controls.
Turning every endpoint into a tool would leave the model choosing between many similar functions. We would first define the task the user needs to complete, then decide which tools to expose. The number of available operations would tell us little about the quality of the integration.
Evidence for a shared standard
On 9 December 2025, Anthropic announced that it was donating MCP to the Agentic AI Foundation under the Linux Foundation. Anthropic, Block and OpenAI co-founded the foundation, with support from companies including Google and Microsoft. The announcement also named products from several vendors that had adopted MCP, including Cursor and Visual Studio Code. This documents industry support, although a vendor announcement does not measure the quality of every integration. Anthropic announcement.
A shared specification lets developers design a server for more than one client. Compatibility still needs testing. Applications may support different protocol versions and features. The 28 July 2026 specification also describes optional extensions, including Tasks and MCP Apps; their availability should not be assumed in every client. MCP specification and extensions.
Permissions remain an implementation responsibility
A tool server lets an application operate on real data. The MCP security documentation covers risks including confused-deputy attacks, improper token forwarding and untrusted local servers. Implementers still need to enforce access controls correctly. MCP security guidance.
In the shop example, we would test attempts to retrieve another customer's order, invalid identifiers and repeated requests. We would also check whether text retrieved from a customer note can steer the model into an additional operation. The system enforcing permissions should reject an unauthorized command even when the model decides to send it.
For operations that write data, we would specify which require user approval, how duplicate actions are prevented and what the audit log records. Those rules give a team something concrete to assess before allowing an integration to work with company data.
MCP with a local model
An application running a local model can also include an MCP client. The protocol does not prescribe how the application runs its model or manages context. A local server and a local model are separate architectural choices. MCP scope.
For a project using a Qwen model, we would separately test tool selection, argument validity and the response to an access denial. Running a model on company hardware does not establish that the entire application operates without external connections. Tool servers, telemetry and services used by the host all need to be accounted for. We cover model selection in our analysis of Qwen for local AI.
Lazarus Systems commentary: where to start
We see the strongest case for MCP where several AI applications or teams need the same capabilities. For a single process that always retrieves the same report from one API, a direct integration may take less work to build and maintain.
We would start a pilot with one task and read-only tools. Two MCP clients would perform the same task, allowing us to compare correct results, latency, failed tool calls and the work required to connect the second client. That last measurement would show how much the shared standard contributes to this particular project.
When selecting a vendor, we would ask for a demonstration using our own test data, a list of supported protocol versions and exportable tool-call logs. A buyer can include those requirements in an integration's acceptance criteria today.
Sources checked on 2 October 2026. The shop example and proposed tests are editorial recommendations from Lazarus Systems, not a report of a completed deployment.