What is the Model Context Protocol (MCP)?
The Model Context Protocol (MCP) is an open standard for connecting AI applications to tools and data. It defines how a client (an agent, a chat application, or a coding assistant) discovers what a server offers, calls a tool with arguments, reads a resource, and receives the result. Before MCP, each agent framework had its own way of declaring tools, and each integration had to be rebuilt for each framework. With MCP, a company writes one server for its ERP system and any compliant client can use it.
An MCP server is a small program that wraps a system and exposes it in three forms. Tools are actions the model can call, such as “create_sales_order” or “search_tickets”, each with a typed schema for its inputs. Resources are data the client can read into context, such as a document, a database row, or a configuration file. Prompts are reusable instruction templates the server offers for common tasks. The server runs either as a local process that talks to the client over standard input and output, or as a network service reached over HTTP. The protocol was introduced by Anthropic and is maintained as an open specification with software development kits in most major programming languages.
How the Model Context Protocol works
A session follows a fixed sequence. The client connects to the server and the two exchange capabilities. The client asks the server to list its tools, resources, and prompts, and places the tool descriptions in the model’s context. When the model decides to act, it emits a tool call; the client forwards it to the server, which executes it against the underlying system and returns a result. The client appends the result to the conversation and the model continues. Every message in this exchange uses a defined JSON format, which is what makes servers and clients interchangeable.
The server owns the connection to the real system and its credentials. The model never sees a database password or an API key; it sees only the tool names, descriptions, and whatever the server chooses to return. That boundary is where access control and logging belong.
Why the Model Context Protocol matters
For a business, MCP changes integration from a per-project cost into a reusable asset. An MCP server for the ticketing system, written once, serves the support agent, the IT operations agent, and an analyst’s chat assistant. It also decouples the choice of model and agent platform from the integration work. A company can start with a hosted model and later move to an open-weight model on its own servers without touching the servers that connect to its systems.
In Kirk Tech Solutions engagements, line-of-business systems such as ERP, CRM, and ticketing are exposed to agents through MCP servers that run inside the client’s own environment, and FlatClaw, the open-source private AI platform from Kirk Tech Solutions, uses MCP as its tool interface.
Model Context Protocol in practice
A machine shop runs an ERP system, a quality management system, and a shared drive of work instructions. The IT team writes three MCP servers. The ERP server exposes read tools for jobs, inventory, and routings, and one write tool that creates a purchase requisition. The quality server exposes nonconformance reports as resources and a tool to open a corrective action. The documents server exposes work instructions as searchable resources. A production planning agent uses all three to answer “why is job 8812 late” with the actual material shortage, the open nonconformance on the supplier, and the relevant work instruction, and then drafts the requisition for a buyer to approve.
Model Context Protocol compared with function calling
| Aspect | Function calling | Model Context Protocol |
|---|---|---|
| What it is | A model API feature for returning structured tool calls | A protocol for connecting clients to tool and data servers |
| Where tools live | Defined in the application code for each model call | Published by a separate server that any client can discover |
| Reuse | Rewritten for each application and often for each model vendor | One server serves every compliant client |
| Execution | The application runs the function itself | The server runs it and holds the credentials |
The two work together. The model still produces a tool call through function calling; MCP standardizes where that call goes and how the result comes back.
What to watch for
- Treat every MCP server as a privileged integration: run it inside your own network, give it least-privilege credentials, and log every call.
- Be careful with third-party servers, since a server’s tool descriptions enter the model’s context and a malicious description is a form of prompt injection.
- Keep write tools few and explicit, and route them through an approval workflow.
- Check that a vendor’s “MCP support” includes the parts you need (tools, resources, authentication), since implementations vary in completeness.
- Version your servers; changing a tool’s schema changes how every agent that uses it behaves.