Insight series · Part 2 · 14 September 2026 · Part 1 · Part 3 · Part 4

API, MCP and tools — how AI goes from talking to doing

The first article followed what happens when you ask a question. This one answers the natural follow-on: if the LLM is the brain, how does an agent actually get into other systems and do things?

In part 1, we followed:

Question → Prompt → RAG → Context → LLM → Response

That mostly explains how AI thinks and answers.

What happens when you ask it to actually do something?

For example:

• “Book a meeting with Sarah for next Tuesday.”
• “Update this customer's address in our CRM.”
• “Prepare the VAT return from this quarter's transactions.”

Now the AI needs something more than language. It needs a way to interact with other systems. That is where terms such as API, tools, function calling and MCP become important.

Start with the API

API stands for Application Programming Interface. The name makes it sound more complicated than the idea.

An API is simply a defined way for one piece of software to ask another piece of software to do something.

Imagine a restaurant. You don't walk into the kitchen and start using the equipment yourself. You give the waiter an order. The waiter knows how to communicate that request to the kitchen and bring the result back.

An API performs a similar job between software systems.

For example, your accounting system might provide APIs that allow authorised software to:

• retrieve an invoice;
• create a customer;
• record a payment;
• retrieve transactions;
• update a record.

Your calendar might provide APIs to check availability, create or move appointments, or cancel meetings. Your CRM might expose APIs to find customers, retrieve opportunities, update records or create tasks.

The API is therefore not the AI. It is an interface through which software can interact with another system.

From an answer to an action

Suppose you tell an AI assistant:

“Book a meeting with Sarah next Tuesday afternoon.”

An LLM can understand what you mean. But understanding the request doesn't put anything into your calendar. Something needs to bridge that gap.

A simplified journey might look like this:

Your request → LLM understands the intention → Agent decides it needs the calendar → Calendar tool is selected → Tool uses the calendar API → Available times are retrieved → Agent selects or asks you to confirm a time → Calendar API creates the meeting → Result returns to the agent → “Done. The meeting is booked.”

That is a major difference between an AI answering and an AI acting.

So what is a tool?

A tool is a capability made available to an AI agent — for example: search customers, check calendar, create appointment, retrieve invoice, update CRM, send email, calculate VAT.

Behind many of those tools will be an API.

API = how software systems communicate.

Tool = a capability the AI is allowed to use.

The distinction matters. A CRM might expose hundreds of API operations. You probably don't want your customer-service AI to have unrestricted access to all of them.

Instead, Aadi might be given three carefully defined tools: find customer, read customer status, create follow-up task. The underlying CRM might be enormously powerful. The digital worker only gets the capabilities required for its job.

That is governance becoming practical rather than theoretical.

What is function calling?

You may also hear the term function calling. This is the mechanism that allows an LLM to say, in effect: “I need this particular tool, with these particular pieces of information.”

For example, instead of generating “I have booked your meeting,” the model might request something equivalent to: create_meeting — person Sarah, date Tuesday, time 14:00, duration 30 minutes.

The surrounding application executes the function or tool and returns the result. Only then should the AI say that the meeting has actually been created.

Function calling is widely used to connect models to external systems and actions. See OpenAI's overview of function calling.

Saying something happened is not the same as making it happen. The tool execution provides the bridge.

Then what is MCP?

Another acronym that is becoming common: MCP — Model Context Protocol.

A common way for AI applications to discover and use external capabilities and information.

Without a common protocol, every AI application may need its own custom way of connecting to every system — Aadi to CRM, Aadi to calendar, another product to the same CRM, and so on. Lots of bespoke connections.

MCP attempts to standardise part of this relationship. An MCP server can expose resources, prompts and tools to an AI application. Tools can allow the model to perform actions or retrieve information from external systems. See the MCP server overview.

A useful analogy is USB. USB didn't create the keyboard or the hard drive. It created a more standard way of connecting them. MCP is trying to play a similar role in the AI ecosystem.

It doesn't replace the CRM, its API, or the AI model. It provides a more standard way for an AI application to discover and interact with capabilities and context exposed to it.

API vs MCP

These terms are sometimes treated as alternatives. They aren't necessarily.

API: “Here is how software can communicate with this particular system.”

MCP: “Here is a standard way of presenting tools, resources and capabilities so an AI application can understand and use them.”

An MCP tool might itself call an API behind the scenes:

AI agent → MCP tool → Accounting API → Accounting system

MCP doesn't make APIs obsolete. It can make APIs easier to expose consistently to AI systems. The MCP specification supports tools that interact with external systems, including API calls — see MCP tools.

Why does this matter for agentic AI?

An AI that can only generate language is limited to: explain, summarise, draft, recommend.

Give it controlled access to tools and it can potentially: search, retrieve, calculate, create, update, submit, book, escalate.

That is the transition from “Here is what I think you should do” to “I have prepared it for you” — and, where appropriate, “It has been done.”

Modern AI agents use tools to retrieve data and take actions in external systems; the model can decide which appropriate tool is needed as it works through a task. See also OpenAI's practical guide to building agents.

But access is not permission

Just because an AI can call an API does not mean it should be allowed to perform every available action.

Consider a bookkeeping digital worker. It might reasonably be allowed to read transactions, categorise them, identify anomalies, calculate VAT and prepare the return.

Should it automatically submit the VAT return to HMRC? Perhaps. Perhaps not. That is a business and governance decision, not simply a technology decision.

You might instead define:

• Read transactions — autonomous
• Categorise — autonomous within rules
• Calculate VAT — autonomous
• Flag anomalies — autonomous
• Prepare VAT return — autonomous
• Submit VAT return — human approval required

That is bounded autonomy in practical terms. MCP guidance similarly emphasises human control around tool invocation where tools can cause actions.

Put the pieces together: VAT example

Suppose you tell an Aadi bookkeeping assistant:

“Prepare our VAT return for this quarter.”

1. Prompt — you give Aadi the job.
2. Context — which company, which period, instructions and permitted boundaries.
3. Tools — the worker determines it needs accounting transactions.
4. API / MCP — the appropriate tool retrieves authorised information from the accounting system.
5. LLM + rules — interpret, categorise where appropriate, identify exceptions.
6. Workflow — the defined VAT process determines the sequence of checks.
7. Guardrails — missing information, out-of-authority cases, need for human judgement.
8. Human approval — the responsible person reviews the prepared return and exceptions.
9. Action — if authorised, the filing tool submits approved information.
10. Audit trail — what was done, what data was used, what required approval.

Outcome: VAT return prepared, reviewed and submitted. That is a long way beyond a chatbot.

The complete picture

• LLM — language and reasoning engine
• Prompt — what you ask it to do
• Context — what it knows for this task
• RAG — how it retrieves relevant knowledge
• Tool — a capability the AI is allowed to use
• API — how software communicates with another system
• Function calling — how the model requests a tool with structured information
• MCP — a standard way of exposing tools, resources and context to AI applications
• Workflow — the sequence required to complete the business process
• Guardrails — rules defining what the AI may and may not do
• Human-in-the-loop — where a person must review, approve or decide
• Agent — AI that can choose permitted steps and tools towards an objective
• Digital worker — the whole organised around a defined business job

Why this distinction matters

It is tempting to look at the latest LLM and ask: “What can this model do?” For a business, that may be the wrong starting question.

A more useful question is: “What job do we want done?” Then work backwards: what information, systems, APIs or tools, autonomous decisions, human intervention points, and evidence of done?

That brings us back to the Aadi model:

Process → Job → Digital worker → Outcome

The LLM provides intelligence. RAG provides knowledge. APIs provide connections. Tools provide capabilities. MCP can help standardise how those capabilities are exposed. Workflows provide process. Guardrails provide boundaries. Humans provide judgement where it matters.

Put them together properly and AI stops being something you simply talk to. It becomes something you can give a job.