How the Model Context Protocol Lets AI Agents Discover and Call Tools

Ask an AI assistant to "create a minimal landing page in Figma for an AI SaaS called FlowAI, with a dark background, one headline, a call-to-action button and three feature cards", and a well-connected assistant can do it: it produces the frame in Figma without you opening the app or anyone writing a custom Figma integration. The first result is a starting point, and you can keep iterating by asking for new screens, typography or font changes. The same approach works with many other applications.

That raises obvious questions. How does a language model control another application? Is MCP just another API? What actually happens between the request and the result, and why has the protocol become so widely discussed? This article answers each of them, so you can reason about MCP as an engineer rather than treat it as a black box.

What MCP is

MCP, the Model Context Protocol, is a standard way for AI applications to discover external tools and use them. In the Figma scenario, the simplest mental picture is a chain: the AI application talks to MCP, and MCP talks to Figma. You describe what you want, the model interprets the request, looks at which tools are available through MCP, and invokes the one that fits the task.

Figma is just one example. Through the same protocol, an AI application can reach a database, Slack, GitHub and practically any other system that offers an MCP server.

In this context, a "tool" simply means a function that a service exposes for the model to call, such as "create a frame", "search messages" or "run a query". MCP gives those functions a common shape, so any compatible AI application can find and use them.

The integration problem MCP solves

Without a shared protocol, every pairing of AI application and tool needs its own custom code. Connecting one assistant to Figma is an integration. Connecting a second assistant to Figma is another one. Adding Slack means another, and a database another still. The number of integrations grows with every application multiplied by every tool, and maintaining them quickly becomes unmanageable.

With MCP, each tool provider exposes its functions once through the protocol, and each AI application implements the protocol once. Any compatible application can then use any compatible tool. A useful way to remember it: MCP acts like a universal adapter between AI models and the tools they need.

Is MCP a replacement for APIs?

No. APIs are not going anywhere. Figma, Stripe and Slack still have their APIs, and your PostgreSQL database still exists behind whatever you build on top of it. In practice, many MCP servers are thin layers over existing APIs.

What changes is how those capabilities are presented to and consumed by an AI application. In a traditional integration, a developer reads the API documentation, picks the right endpoint, writes the client code, deals with authentication, sends requests and parses responses. All of those decisions are made in advance and fixed in code.

With MCP, the AI application can ask a server at runtime which tools it offers. A server for an online shop might answer with tools such as:

• search products
• get an order
• create a refund

Each tool comes with a name, a description of its purpose and a structured input schema that the model can read. Based on the user's request, the model chooses the tool that fits and supplies arguments that match the schema. The decision about which operation to perform moves from code written ahead of time to the model's reasoning at request time.

The three building blocks: host, client and server

MCP is organized around three roles.

The host

The host is the AI application the user actually interacts with: a chat assistant, an AI coding tool or any application with a language model at its core. It owns the conversation and the model, and it decides which servers the model is allowed to use.

The MCP client

The client is the component inside the host that manages communication with an MCP server. In the protocol's design, a host typically runs one client per server connection, so an assistant connected to Figma and GitHub maintains two separate client sessions.

The MCP server

The server exposes tools to the AI application and connects them to real systems. When a tool is called, the server is the part that actually talks to Figma's API, runs the database query or posts the Slack message.

What happens during a tool call

Put the three roles together and the flow becomes clear. The client lets the host discover the tools a server offers and call them with properly structured parameters when the model decides they are needed.

This is not a single fire-and-forget request. It is a conversation between client and server. They first establish a session and agree on capabilities, then the client asks for the list of tools, and later it sends tool calls and receives their results. Under the hood, these messages use JSON-RPC, carried either over standard input and output for servers running locally or over HTTP for remote ones.

The language model is what makes this different from a conventional integration. There are no hard-coded call sequences; the model reads the tool descriptions, works out which ones serve the user's goal, and requests them in whatever order the conversation requires.

Walking through an e-commerce assistant

Consider a support assistant for an online store whose MCP server exposes three tools:

• get_order
• search_products
• create_refund

A customer writes: "Where's my order?" The model recognizes the intent, notices that a get_order tool is available, and decides to call it with the customer's order ID. The request goes through the client to the server, which queries the order database or the internal orders API and returns structured data about the order. The model then turns that data into a natural reply, for example: "Your order shipped yesterday and should arrive on Thursday."

The customer follows up with: "Actually, refund it." Because the model still has the conversation context, it knows which order "it" refers to. It sees that create_refund is available and calls it with the same order details. If the server also exposed a tool such as notify_finance, the model could include that step in the workflow as well.

This division of labor is the core idea of MCP. The model decides which tool to use and with what arguments. The server carries out the actual operation. In a production system you would add one more element to this flow: a refund is a consequential, irreversible action, so many teams require explicit user confirmation or policy checks on the server before executing it, rather than trusting the model's judgment alone.

What MCP gives you

Three benefits stand out.

1. Standardization: AI applications interact with external tools in one consistent way, instead of a different pattern for every integration.
2. Flexibility: the model discovers available tools and reads their schemas directly, so you no longer have to describe every function by hand inside a sprawling system prompt.
3. Reusability: an MCP server is built once and can then serve many compatible AI applications.

What MCP does not do

It helps to be precise about the limits, because the hype around the protocol can blur them.

• MCP is not magic, and it does not make an underlying API any more capable than it already is.
• It does not make an AI system reliable. The model can still pick the wrong tool or pass the wrong arguments, so validation and sensible error handling on the server remain essential.
• It does not remove authentication or security concerns. Servers still need credentials, access control and auditing, and tool outputs can carry untrusted content that tries to steer the model.
• It does not mean every internal system should be exposed to an AI agent. Grant the smallest set of tools and permissions that a use case genuinely needs.

AI calling an API is not new; developers have wired models to APIs for years. What MCP adds is a standardized interface through which a model can discover and use many different tools without a bespoke integration for each one.

Key takeaways

• MCP is a protocol for connecting AI applications to tools. It sits on top of APIs rather than replacing them.
• Servers expose tools with descriptions and input schemas; the host and its clients handle discovery and communication.
• The model chooses which tool to call and with what arguments; the server performs the real operation.
• Standardization turns a growing web of one-off integrations into components that are built once and reused.
• Reliability, authentication, least privilege and confirmation of risky actions remain your responsibility.

If you are starting out, begin by connecting existing MCP servers, such as those for GitHub, Slack or Figma, to an assistant you already use and watch how the model picks tools. Once the value is clear, building your own server for an internal database or service is a natural next step. For a look at how MCP fits into larger agent frameworks, see our article on standardizing tool integration in LangGraph with MCP.