AI agents in practice: tool calling, permissions, and why MCP matters for procurement

On a Wednesday break, a Primary 5 class teacher in the staff room said: "If AI could pull every pupil in 5B who was late more than three times this month and draft the parent text, I'd save an hour every month." The IT coordinator replied: "The chat window can't see your attendance register unless we give it a channel to query records—and rules for which steps you must press confirm yourself."

That is the last piece of module 4 on how applications land in school. Earlier lessons covered how knowledge reaches the model and how context caching controls cost. This one covers how a model asks something else to act instead of pretending to know everything.

Tool calling means filling a work order, not doing the job. An agent schedules the next step from the result. MCP determines whether those work orders can attach to another provider later. Together, that is what school automation should look like.

---

Work orders: the model proposes, the system executes

Treat the model as a consultant in the school office: articulate, fast, but without keys to the general office. Ask how many assembly absences class 5B had in September and it cannot know. Ask what 847 divided by 23 leaves as a remainder and it may sound confident while getting the arithmetic wrong, because it predicts text rather than calculating.

Tool calling means telling the model in advance which tools exist, what each is called, what it does and which parameters it needs. When it hits something it cannot do, it emits a structured request along the lines of "please call attendance_by_class with class=5B, month=2026-09, field=late_count".

The crucial point: the model never touches the database. Your backend receives the work order and decides whether to run it, whether the head of year must approve, and whether to write ai_audit_logs. That split is what makes the arrangement safe for a school.

From reply to loop

A chatbot is one question, one answer. An agent adds a layer: after reading what a tool returned, it decides whether to call another.

A typical loop looks like this:

1. grasp the goal (find pupils with frequent lateness and draft parent texts);
2. break it into steps (query records, filter, draft per pupil);
3. choose a tool and wait for the result;
4. if the result is empty or a figure looks wrong, change parameters, re-query or flag for a human;
5. repeat until finished or until a human interrupt fires.

An AI that schedules its own next step saves repeated clicking; the risk is ten steps in a row while you only watched the first—so permission design matters more than model choice.

How to cut three permission tiers

In practice, write three tiers into procurement and information-security documents:

• Read only: attendance lookup, timetable lookup, knowledge-base passage—may run automatically;
• Draft only: parent texts, comments, circulars—return text, nothing goes out;
• Outward action: email, app push, grade write-back—runs only after a teacher confirms on screen.

More on process design is in from chatbot to AI agent with tool calling. Boundaries are in defending against jailbreaks and prompt injection.

MCP: install the tool once

Years ago, every change of AI provider meant rebuilding bespoke connectors for library, assessment and parent-comms systems. IT teams often said: "Not impossible—just nobody has time for a third rewrite."

MCP, the Model Context Protocol, is an open standard for how tools and data sources describe themselves to AI applications and get called. Official docs call it a USB-C port for AI applications. The point is not the slogan but that the same attendance query tool can, in principle, attach to different models or platforms, so changing provider does not restart integration from zero.

For school procurement the implications are concrete:

• tools a panel builds can be reused across projects;
• bargaining is not hostage to "integration too painful";
• long-term data and process assets stay with the school rather than locked inside one vendor UI.

One clarification: the standard does not solve permissions or prompt injection. A tool wired to administrative systems still needs gating and audit, see AI guardrails.

Edor.ai today centres on retrieval and templates; an outward MCP server is a planned direction, not a shipped feature. We would rather stabilise the knowledge base and four-layer gating before opening action.

A trial in a primary admin team

One primary school hands high-absence cases to the guidance team every month, copying between attendance software, a spreadsheet and a Word template. One colleague once spent 4.5 hours on the copy work alone.

Their trial split the job like this:

• read_attendance_monthly: read only, automatic;
• filter_absence_rate: calculate only, automatic;
• draft_parent_text: generate from the school template, do not send;
• push_parent_app: runs only after the discipline master sees the full text and presses confirm;
• audit throughout: who approved which draft at 14:32.

After the trial the colleague said: "Copying is gone, but the push step is still my click—that's the right design." The three time-saving steps are low-risk reads and maths; the single high-risk outward step keeps a human. School automation was never meant to remove teacher judgement, only copying.

Where people go wrong

• Wrong turn: assuming "connected to the database" equals safe, with no tiered permissions. Self-check: list every action that runs without human confirmation; if outward send or grade write-back appears, demand a redesign.
• Wrong turn: treating the agent as a magic chatbox with "look up attendance, send notices and change the timetable" in one breath. Self-check: ask the vendor for a step diagram naming each tool and who may approve.
• Wrong turn: procurement asks only "do you support agents" and not whether interfaces are open. Self-check: ask how much existing tooling must change if the model provider switches, and whether MCP or an equivalent open description is supported.

Try it once

Time: about 12 minutes. Materials: any conversational AI tool.

1. Paste the prompt below (no real system connection needed):

You may use only the two virtual tools below and must not answer from memory:
Tool A "class_attendance_summary": input class and month, returns attendance rate and absence count.
Tool B "filter_list": input pupil list and condition (e.g. late_count > 3), returns matches.
Task: for class 5B in September 2026, list pupils late more than three times and state what tool would be missing to draft parent texts next.
Write step by step which tool you would call, with what parameters, and what you would do with each result. Do not give a final answer sheet.

2. Watch for: step breakdown and an honest note that drafting texts needs a third tool.
3. Hand in: the full reply plus one sentence from you naming which step must require teacher confirmation and why.

You got it right if the output is an ordered call plan with a clear gap report, and your sentence points to outward send never running unattended. The next lesson covers who wires these work orders in development: LangChain and LlamaIndex. For cost, return to context caching.