From chatbot to AI agent, with tool calling and MCP

A discipline master once asked a deceptively simple question: "Can AI work out which pupils were late more than three times this month and then draft the notice to parents?"

The answer is that a chat model alone cannot, and the reason is worth understanding. The model does not know your attendance records, and it does not do reliable arithmetic, because it is a system that predicts text one token at a time rather than a calculator. But give it a calculator and a channel for querying attendance records and the picture changes entirely.

Give it a calculator and a phone

Imagine engaging an extraordinarily well-read teaching assistant. Ask her for last month's average attendance rate at your school and she will not know, because it is in no book. Ask her what 3,847 divided by 41 comes to and her mental arithmetic will slip.

Now put a calculator on her desk and a phone line to the general office beside it, and tell her: press the calculator when you cannot work something out, ring the office when you do not know something. She can handle both questions immediately.

Tool calling does exactly that. We tell the model in advance which tools exist, what each one is called, what it does and what information it needs. When the model meets something it cannot do itself, it asks for a tool.

There is one crucial and frequently misunderstood detail here: the model executes nothing. It only emits a structured request meaning "please use the attendance lookup tool with the parameters September and late count greater than three". What actually queries the database is your system, and your system may refuse, may require human confirmation, and may log it. That division of labour is precisely what makes this safe for a school to use.

From chatbot to agent

Once tools exist, one more thing makes it an agent: letting it read the results and decide the next step itself.

A chatbot works question by question. An agent works in a loop:

1. understand the goal ("find pupils late more than three times and draft notices");
2. break it into steps (query records, then count, then draft one per pupil);
3. choose a tool and run it;
4. look at the result — if nothing came back, try a different query; if a number looks odd, check it again;
5. repeat until finished or until a human is needed.

The power and the risk of that loop are the same property. It can work around small obstacles by itself, and it can also do ten things in a row while you are not watching. So the first principle for a school using agents is not technical but about permissions: which tools may only read, which may write, and which must wait for a human to press confirm.

More on practical process design is in from chatbot to AI agent with tool calling.

MCP, the standard plug socket

Now for a clean analogy.

A decade or so ago every phone had its own charging connector. Change phone and you replaced the whole set of cables, car chargers and travel adapters. Then the industry settled on one specification and a single cable charged everything.

The world of AI tools started out as one connector per phone. Connecting a school library system to OpenAI meant writing one integration, connecting it to Anthropic meant writing another, and changing provider meant starting again.

MCP, the Model Context Protocol, is that common plug specification. It is an open standard defining how tools and data sources describe themselves to AI applications and how they get called. The official documentation calls it a USB-C port for AI applications: one standard way to connect, so any compliant tool works with any compliant model or application.

For a school the implications are concrete:

• No lock-in. An integration built once for the library or assessment system can, in principle, carry across providers.
• Tools accumulate. A tool one panel builds can be connected by another panel without being rewritten.
• Bargaining power stays with the school. When switching models is cheap, a school is not forced to renew because the integration would be too painful to redo.

One clarification. The standard does not solve safety. A tool connected to school administrative systems still needs permission design, audit logging and defences against prompt injection, each handled separately. See AI guardrails and defending against jailbreaks and prompt injection.

As for Edor.ai: our teacher tools and AI tutor today are built around retrieval and templates, and an outward-facing MCP server capability is a planned direction, not a shipped feature. We would rather make the knowledge base and the gating solid before we talk about taking action.

An example from the classroom

The administration team at one primary school repeats the same job every month: reconcile last month's attendance, identify pupils with high absence, draft letters of concern from the list, and hand a case list to the guidance team. Four steps, copied by hand between three different systems, taking one colleague most of a day.

Designed as a tool-using process, the division of labour looks like this:

• an attendance lookup tool that is read only and runs automatically;
• a counting and sorting tool that only calculates and runs automatically;
• letter drafting, generated by the model using the school's template and forms of address;
• sending to parents, which only runs after the master presses confirm, with the draft shown first;
• an audit record throughout, so who approved what and when can be traced.

Notice that the three steps saving the most time are all low-risk reading and calculation, and the single high-risk step, sending outwards, keeps human confirmation. That split is not a compromise, it is the correct design. The aim of automation in a school was never to remove teacher judgement, only to remove copying.

What this means for your classroom

1. Unreliable arithmetic is not a defect but the nature of the thing. Anything involving marks, statistics or date calculation should go through a tool rather than the model's head. This is worth telling pupils directly.
2. The more capability, the more permission design matters. When evaluating any AI automation proposal, the first question is which actions run without human confirmation. A proposal that cannot answer should not be adopted.
3. Ask vendors whether they use open standards. It is a procurement question with long-term value, because it determines the cost of changing provider later.
4. Explaining tool use to pupils is genuinely educational. It turns AI from magic into a system they can reason about: it does not know, so it looks it up; it cannot calculate, so it presses the calculator.

A small experiment to run now

You can feel the mechanism without connecting anything. Paste this into any AI tool:

You may use only the two tools below and must not answer from memory:
Tool one is called attendance_lookup. Give it a month and a class, and it returns that class's attendance records.
Tool two is called average. Give it a set of numbers, and it returns the mean.
My request: work out the average attendance rate for class 5A in September and identify pupils late more than three times.
Do not give me an answer. Write out step by step which tool you would call in which order, what parameters you would pass, and what you would do next with each result. If any step cannot be done with these two tools, say plainly which tool is missing.

You will see it break the task into calls and honestly report that a tool for looking up lateness records is missing. That output is an agent's reasoning in miniature, and the closing admission of a gap is the most valuable behaviour a well-designed agent has.

What comes next

The retrieval, caching and tool calling of the last few lessons are rarely written from scratch in real development, but built on ready-made frameworks. What those frameworks actually do, and whether a school needs to understand them, is the subject of what LangChain and LlamaIndex actually do. To revisit cost structure, return to context caching and cost control. To see what the platform ships today, see features.