You have been building the same picture across this series. There is a wise Librarian behind a mail slot who has read everything but can only finish a note you slip in. Then, in the last two articles, you met the Runner — the helper who stands at the slot for you, fetches things, and does the legwork. Today we get to the two trickiest-sounding buzzwords in all of AI: function calling and MCP. Both of them are, at heart, just agreements — like agreeing to use a standard form at the post office instead of writing a random letter. Once you see that, they stop being scary.

This is part 6 of the AI in Plain English series. No background needed.

The problem: the Librarian's requests are hard to read

Imagine the Librarian has decided they need today's weather in London. They write a note back to the Runner. The trouble is, the Librarian is a genius at language — which means they might write any of these:

  • "Could you please pop out and find out what the weather is doing in London right now?"
  • "London weather, today, if you would be so kind."
  • "I require current meteorological conditions for the city of London, England."

All three mean the same thing. But the Runner is not a genius — the Runner is a simple, reliable programme that follows instructions. It can't cope with a hundred ways of asking the same question. It needs something it can parse reliably every single time.

So the Librarian and the Runner make an agreement. Instead of a rambling sentence, the Librarian agrees to fill in a tidy form — a small card with labelled blanks:

Action: get_weather
Location: London
Units: celsius

Fixed labels. Fixed slots. No ambiguity. The Runner reads it in a split second and knows exactly what to do.

That agreement — that the Librarian must use a structured form with fixed labels rather than free prose — is what techies call function calling. The word "function" here just means one named action (like get_weather or search_calendar). "Calling" means asking for it to be done. The real idea is: a fill-in-the-blank form so the two sides can cooperate reliably.

The form format most commonly used looks like JSON (JavaScript Object Notation — a way of writing data that both humans and computers can read). You do not need to know what JSON is. Just picture a neat card with labelled blanks.

The problem: too many different tool-shops

Now the Runner has its form. It trots off to fetch the weather. But where does it go?

Out in the world there are dozens of "tool-shops" the Runner might visit: a weather shop, a calendar shop, a maps shop, a database shop, a file-storage shop. Each of these shops was built by a different team. Before anyone agreed on a standard, each shop had its own private way of doing business:

  • The weather shop might say: "Send us a GET request with a city parameter."
  • The calendar shop might say: "Post us a JSON envelope with a query key."
  • The maps shop might say: "Call our API with OAuth headers, thank you very much."

The Runner would have to learn each shop's private manners separately. That is exhausting and fragile — if a new shop opens, someone has to teach the Runner a new set of manners from scratch.

The solution is the same one that solved the plug-and-socket problem. Instead of a different socket shape for every country, you agree on one standard plug. Then any device and any socket work together without adaptation.

For AI tool-shops, that standard plug is called MCP — the Model Context Protocol. It defines one shared way for the Runner to ask any tool-shop two basic questions:

  1. "What can you do?" (The shop lists its actions in a standard format.)
  2. "Please do this. Here are the details." (Sent in the standard format from question one.)

Any shop that follows MCP speaks the same language as any Runner that follows MCP. The Runner learns one set of manners, and every MCP-compliant shop understands it perfectly.

The confusion everyone has: aren't they the same thing?

No. They work at different points in the chain.

Function calling is about the conversation between the Librarian and the Runner. It is the internal form the Librarian fills in to say "I want you to go and do THIS, here are the details." The Runner reads the form. That is it.

MCP is about the conversation between the Runner and the outside world. Once the Runner has the form, it needs to go and knock on the door of a tool-shop. MCP is the standard set of manners for that knock.

Think of it as two separate agreements:

  • The Librarian and the Runner agree: requests must go on this form. (Function calling.)
  • The Runner and the tool-shops agree: shops must speak this common language. (MCP.)

They are not rivals. They do not do the same job. They are two links in the same chain.

The whole picture, finally

Let us put the whole series together in one clean view.

You are sitting at a desk. You have a question. You talk to the Runner — the agent, the AI assistant in your chat box or your phone. The Runner is the reliable, tireless helper who does the mechanical legwork. It is smart enough to follow a recipe, keep notes, and run errands. It is not the genius.

When a question needs real wisdom, the Runner writes a note and slips it through the mail slot to the Librarian — the AI model (the LLM, the large language model), the one who has read everything. The Librarian reads, thinks, and writes a note back. That note might be a full answer, or it might be a form saying "go fetch this first."

If the note says "go fetch," the Runner reads the form (function calling) and heads out to the right tool-shop. It knocks using the standard handshake (MCP). The shop does its job and sends the result back. The Runner staples the result to the context, goes back to the slot, and slips a new note in so the Librarian can carry on.

You, the Reader, never see any of this. You just see the reply.

The Librarian cannot leave the room. They cannot search the web, check your calendar, or ask the weather on their own. That is not a flaw — it is the whole point. They do the one thing that actually needs a genius: reading the note and writing the next word. Everything else is handled by the Runner, the forms, and the standard plug.

Why should you care about any of this?

You probably do not need to configure function calls or write MCP servers. But once you know what these words mean, a whole category of AI news makes sense.

When you read "AI tool use expanded" or "this model now supports 50 integrations" or "we added a new connector" — that is the Runner gaining access to more tool-shops via MCP. When you read "structured output" or "JSON mode" or "the model returns a schema" — that is function calling, the form coming back in the agreed format.

Most importantly, the next time a salesperson says their AI product "integrates with everything," you know the question to ask: does it use the standard plug (MCP), or does it need a custom cable for each shop?

What comes next

In the next article we look at the places you actually encounter all of this: the chat box, the coding assistant, the desktop helper. The slot and the Runner look different in different places, but now you know what is happening behind every one of them.

Back to the AI in Plain English series hub, or explore aitutors.me to see how a real AI tutor is built on all of these ideas.