MCP: how an agent connects to your tools

A customer wants a blue jacket in size M. The sales assistant asks an AI assistant: “Do we have any left in our Lyon store?”

To answer, the assistant must identify the product, check inventory at the right store and read the result. Its language model can interpret the question. The available quantity lives in the retailer’s software.

This is the starting point for MCP: giving an AI application a common way to discover and use another application’s capabilities.

The problem: connecting the assistant to business software

The retailer already has an API for checking inventory. A team can therefore build a connection for its assistant: select the right endpoint, pass identifiers and handle the response.

Then the retailer wants that function available in a second AI application. If this application expects tools to be defined and invoked differently, part of the integration needs adapting. As applications and services multiply, those adaptations accumulate.

The need is to share a connection interface while keeping existing business systems.

Where MCP came from

On November 25, 2024, Anthropic introduced and open-sourced the Model Context Protocol. Its aim was to standardize exchanges between AI applications and systems that hold data or perform actions. Anthropic’s original announcement

For our retailer, a team builds an MCP server that exposes inventory lookup. A compatible application can discover and invoke that tool using the protocol. The retailer’s API remains behind the server and continues supplying the data.

How it works technically: who does what?

Return to the sales assistant’s question. Three roles share the work:

• The host application is the assistant she uses. It displays the conversation, calls the model and manages tool execution.
• The MCP client is a component inside that application. It sends requests to the server in MCP format and receives responses. The sales assistant does not use it separately.
• The MCP server is the program exposing the retailer’s tools. For check_stock, it calls the inventory API and returns the result. The business system remains responsible for quantities and access rules. MCP architecture

In this example, the model proposes a call; the application decides whether to execute it under its rules. The client carries that call, and the server performs it through the retailer’s software.

An inventory question, end to end

On connection, the client retrieves the tool catalog through tools/list. For the sales assistant’s question, the application gives the model the description and parameters of check_stock. It then sends the proposed call through tools/call. Tools specification

The local or remote choice concerns where the server runs and how messages reach it. Locally, the application can launch a process and use its standard input and output (stdio). Remotely, it can reach a server over HTTP. The roles described above remain the same. MCP transports

Benefits for this retailer

• Reuse. The same server can serve multiple compatible applications, each with its own configuration and permissions.

• Keep existing systems. The team can expose an API function without rewriting its inventory software.

• Choose which capabilities to offer the agent. To help the sales assistant, the team can start with product search and inventory reads. Catalog changes can be a separate integration with their own controls. This is a server design decision.

Implementation limits to plan for

• Permissions still need enforcing. A sales assistant allowed to check Lyon should not gain access to every store. MCP provides an authorization framework for HTTP, but the server and business service must enforce actual permissions. MCP authorization

• The contract must be precise. “Available inventory” might mean physical stock or stock remaining after reservations. Developers must explain what the tool returns and how it reports unavailable data.

• The integration needs operation and maintenance. Timeouts, API outages, call logs and compatibility between client and server versions all need handling.

• Model context remains limited. Offering hundreds of tools requires selecting relevant ones. The protocol guarantees neither that selection nor the accuracy of the final answer.

An initial implementation could therefore focus on inventory reads, then be tested against ambiguous products, denied access and service outages before enabling changes.

Continue with MCP, API and CLI compared and how to write good tools.