Tool Calling, and MCP: A Story, Not a Manual
So, my learning friends, today we will dive a little bit into the topic of tools and MCP. What is it? What is the difference between them? Let’s hope at the end of this short reading, both me and you, will have no doubt about it!
As you have probably heard about RAG by now, which is a system that gives a model a superpower of retrieving information from a knowledge base before answering. Think of it like a student that is in the middle of the exam and he or she, instead of relying only on what they memorized while learning, is allowed to check the textbook before writing down an answer. This is already a big advantage. But what if we gave our student even more superpowers? Not just the possibility to retrieve something from the knowledge base, but to pick up a phone and call someone, check on internet, or actually go and do something? That is exactly the journey we are going on today and what the topic is about. So, let’s go!
Enter Tool Calling
Here is where tool calling (sometimes also called as function calling) comes in. If RAG gives a model the superpower to retrieve, tool calling gives it the superpower to act, or at least to ask something else to act.
So, in general, it works like this: first, you present to the model a set of functions (tools) that the model is allowed to use. Not the code itself, just a description which include the name of the function, what the function does, and what inputs it expects. Something like “get_weather(city): looks up weather information for the CITY”. Important to know: model never actually runs this function itself. What it actually does is only decide, based on the conversation, whether calling one of these functions would help answer the question. If yes, it is telling you which one to call and with which inputs.
So, for example, when you ask “what is the weather in Wrocław right now”, the model does not try to guess the answer from training data (which would be a pretty bad idea, since weather changes and its training data has a cutoff date that is much far back). Instead, it recognizes that this question matches the description of your function, and it replies not with a final answer, but with a structured request to call get_weather() with city=Wrocław. Your code is the one that actually executes that call, gets the real result, and hands it back to the model. Only then does the model turn that raw result into a nice, human-sounding sentence. You can look at the really simplify version of this flow below.
As you can see this is solving some problems RAG could not on its own, which is getting live, current information, calling some external services, doing some specific calculations or doing things like sending email. Amazing, no?
Multi-Turn and Loops: It Is Rarely Just One Call
Tool calling is almost never a single, one-shot event. It is mostly a loop. Think about a question like “what is the weather in Wrocław, and should I bring an umbrella to the meeting tomorrow at 4pm?” To answer that properly, the model might need to call get_weather() first, chech the result, realize it also needs to check your calendar to know where “tomorrow at 4pm” is. So, in order to do that it would need to request a call to a second function, something like, get_calendar_event(), look at that result too, and only then put both pieces together into one answer.
So the actual flow looks something like: the model gets your message, decides a tool call is needed, your app runs the tool and returns the result as a new message, the model reads that result and decides whether it needs yet another function call or maybe this time it is finally ready to answer you. This can repeat several times before you or your user ever see a reply. This hidden conversation is happening between the model and your tools, with you or the your user only seeing the final answer at the end.
This loop is also what turns a simple chatbot into something closer to what people now call an agent: not just a model that generate simple answers, but a model that can plan a small sequence of actions, check results, and adjust before giving you the answer.
So Why Is Not This Enough?
Tool calling on its own is powerful, but there is a catch noone will tell you about upfront: every single tool has to be connected by hand, for every single application, again and again.
Only imagine that you are building three different AI apps: one that needs access to your calendar, one that needs your CRM, and one that needs your file storage. With plain tool calling, for each app, you have to write the code that describes the function, write the code that actually executes it, handle the authentication for that specific service, the errors, and keep it all in sync whenever that service changes its API. Now imagine you have ten tools and five different applications that all want to use some combination of them. Suddenly you are not writing ten integrations, you are writing up to fifty, because every app talks to every tool in its own custom way. This is sometimes called the M×N problem: M applications, N tools, and a spaghetti of custom code connecting each of them.
Nobody wants to reinvent the “how do I call Google Calendar” wheel inside every single project they build. And this is exactly the gap MCP was built to close. So, let go find out how!
Enter MCP: Model Context Protocol
MCP, which is short for Model Context Protocol, does not invent a new superpower for the model. It is not a smarter kind of tool calling, and the model itself does not even really know MCP exists. What MCP changes is how tools get delivered to the model in the first place.
Get Dominika Sułot’s stories in your inbox
Join Medium for free to get updates from this writer.
Instead of every application writing its own custom integration to every tool, MCP defines one standard way for a tool (or a whole set of tools) to describe itself and expose itself, so that any MCP-compatible application can plug into it without writing additional custom code.
Think of it a bit like USB-C: before it existed, every device had its own charger and its own cable, and connecting anything to anything else was a small nightmare. USB-C did not make your device smarter, it just gave everyone a shared plug. MCP is that shared plug, but for connecting AI applications to tools, data sources, and services. You can see the same call with the use of MCP. I know, for now it looks much more complicated, but at the end, it is making everything easier. Look at this, note your doubts and all the answers you will find in a seconds.
As you see above, MCP setup usually has two sides: an MCP server, which wraps some capability (say, your calendar, your Slack, your weather function) and exposes it in the standard MCP format, and an MCP client, which is inside your application and knows how to talk to any MCP server. The application connects to the server with the client and asks “what can you do?” gets back a list of available tools, and from there it is just… tool calling, the exact same mechanism we already talked about. The only difference is that everything is coordinated between your app, MCP client and MCP server. You do not need to describe manually each tool and sometimes, you do not need to even write the functions. You can use the MCP servers that were provided by others or you can write your own servers to share some common tools for your company or if you want to share the tools with everyone. For example, you can use the MCP servers that were exposed by service providers like code repos or calendar companies. The question that I had, and probably you have right now, is why use MCP if I can use their API deirectly? Well, you can, but then you need to do all the manual work again, writing tool description and code to connect with this API. The MCP servers has this done already, so why doing it again?
As for your application, the flows stays the same. You still pass the question from user to the model. The model still decides when to call a tool and with what input, the same loop still happens.
So, Tools vs. MCP: Where Is the Actual Line?
This is the part I wanted us to leave with no doubt about, because I mixed these up myself in the beginning. Tool calling is a capability: the ability of a model to recognize that a tool call would help, and to ask for it to be called with the right inputs. It is a behavior that happens at the model level, inside that request-response loop we walked through.
MCP is a protocol: a standardized way of packaging, exposing, and discovering those tools (and other context, like resources or prompts but that’s not important for now) so that connecting a new tool does not mean writing another custom integration code from scratch every time. And, just for clarity, you can have tool calling without MCP, plenty of applications did, and still do, by wiring functions by hand. But you cannot really have MCP without tool calling, because MCP still needs that same request-response mechanism to actually let the model use what it exposes.
So if RAG is the librarian who fetches books, tool calling is that same librarian learning she is also allowed to pick up the phone and call other departments when a book is not enough. And MCP is the moment the whole building agrees on one universal phone system, so the librarian does not need to learn a new dialing code every time she wants to reach a new department.
Quick Glossary, For Future Me (and You)
- Tool calling is the ability of a model to recognize that previously described function can help answer a question, and to request that this function will be called with specific inputs, rather than answering directly from memory alone.
- Agent loop is the repeating cycle of the model requesting a tool call, the application executing it and returning the result, and the model deciding whether it needs another call or is ready to answer.
- MCP (Model Context Protocol) is a protocol for exposing tools (and others) to AI applications, so that connecting a new tool does not require custom code for every pair of app and tool.
- MCP server is MCP side that wraps tools and exposes it in the standard MCP format.
- MCP client is MCP side that is inside the application. It has a knowledge how to talk to any MCP server without needing custom code per server.
Wrapping Up
What started as a way to clear up a little bit the topic of tools and MCP ended into its own walk-through. From the librarian (her again) who can only fetch books, to the librarian who can pick up the phone, to even the moment the whole building finally agreed on some one, shared phone system.
As always, if there is one thing worth remembering above everything else, it is this: tool calling is what the model can do, and MCP is how it get delivered to it without the need for everyone to reinvent the same code over and over again. Everything else that we got to know today, the loops, the servers, the clients, it is just engineering built on top of that one idea.
And, as always, writing about it helped me see the line between them far more clearly than just reading about it ever did.
