---
title: "How AI Agents Use APIs: A Beginner's Guide"
url: https://apyhub.com/blog/how-ai-agents-use-apis-a-beginner-s-guide
author: ApyHub
published: 2026-09-15T10:48:34.979116Z
---

# How AI Agents Use APIs: A Beginner's Guide

## Introduction

An AI agent uses an API by reading a machine-readable description of it, deciding that a task needs it, and sending a structured request that the model fills in on its own. The API then does the work the model can't do reliably by itself, such as producing a real file, fetching live data, or checking a record against an official registry.

This is now a mainstream pattern. Postman's [2025 State of the API Report](https://www.postman.com/state-of-api/2025/) (October 2025, based on a survey of more than 5,700 developers, architects, and executives) found that calls to AI APIs on its platform grew 40% year over year, while only 24% of developers design their APIs with AI agents in mind. Agents are already calling APIs. Most APIs were written for human readers.

This guide explains the ideas behind that shift: what an agent is, the four steps it follows to use an API, the two ways agents connect to APIs, what an agent needs from the APIs it calls, and where [ApyHub](https://apyhub.com/) fits into that picture.

## What an AI agent is, in API terms

An AI agent is a language model running in a loop with access to tools. Each time around the loop, the model looks at the goal, looks at what has happened so far, and picks one of three moves: answer, ask the user something, or call a tool.

A tool is any function the agent is allowed to invoke. Most tools are thin wrappers around APIs. When people say an agent "uses an API," they mean the model chose a tool, produced the arguments for it, and received the API's response back into its context.

The model never opens a network connection itself. The application running the agent (usually called the host or client) makes the call and passes the result back. The model decides, and the host executes.

## The four steps an agent follows

Every agent API call goes through the same four steps, whichever model or framework is involved.

text

```
User goal
   │
   ▼
1. Discover  ──►  the host shows the model which tools exist
   │
   ▼
2. Decide    ──►  the model matches the task to a tool and writes the arguments
   │
   ▼
3. Call      ──►  the host sends the request and waits
   │
   ▼
4. Read      ──►  the model reads the result, then answers or loops back to step 2
```

### Step 1: Discover

A model can only use a tool it knows about. Before any work starts, the host loads a list of tools into the model's context. Each entry has three parts: a name, a plain-language description, and a JSON Schema describing the inputs.

In the [Model Context Protocol (MCP) specification](https://modelcontextprotocol.io/specification/2026-07-28/server/tools), a client discovers tools by sending a `tools/list` request, and each tool is identified by a unique name plus metadata describing its schema. An illustrative tool entry looks like this:

json

```json
{
  "name": "convert_document",
  "description": "Converts a document into another file format. Takes the source file and the target format, returns a link to the converted file. Use when the user needs an actual file rather than formatted text.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "source_url": { "type": "string", "description": "Link to the file to convert." },
      "target_format": { "type": "string", "enum": ["pdf", "docx", "html"] }
    },
    "required": ["source_url", "target_format"]
  }
}
```

The description carries more weight than most beginners expect. It sits in the model's context for the whole session, and it is often the only thing the model knows about the tool. A vague description produces a tool the model never picks.

### Step 2: Decide

When a request arrives ("send me this report as a PDF"), the model compares the task against every tool description it has. If one fits, it writes arguments that match the tool's input schema.

Two things decide whether this step goes well. The first is the description: it has to say what the tool takes in, what it returns, and when to use it over similar tools. Postman's report makes the same recommendation, calling for documentation that explains when and why to use an endpoint as well as how. The second is the schema. Typed fields, required markers, and stated limits let the model produce a valid request on the first attempt.

### Step 3: Call

The host sends the request. With MCP, this is a `tools/call` message naming the tool and passing the arguments the model chose (the protocol's required `_meta` fields are left out here for brevity, as the specification does in its own examples):

json

```json
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "convert_document",
    "arguments": {
      "source_url": "https://example.com/files/q3-report.docx",
      "target_format": "pdf"
    }
  }
}
```

The host handles authentication and network traffic. The model never sees an API key.

### Step 4: Read

The result comes back into the model's context as structured content:

json

```json
{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [
      { "type": "text", "text": "{\"file_url\": \"https://example.com/output/q3-report.pdf\"}" }
    ],
    "isError": false
  }
}
```

The model then decides again. It can hand the link to the user, or loop back to step 2 and call another tool, for example to email the file. Chaining calls this way is how agents finish multi-step jobs, and the ApyHub guide to [API chaining](https://apyhub.com/blog/api-chaining-in-2026-combining-api-calls-into-workflows-agents-can-run) covers that pattern in more depth.

## Two ways agents connect to APIs: function calling and MCP

Most agents reach APIs through one of two approaches, and many teams use both.

**Function calling** is built into most model APIs. The developer writes a tool definition for each API inside their own application and writes the code that executes the call. It works well for a small, stable set of APIs that one product owns.

**MCP** moves tool definitions onto a server. Any MCP-compatible client can connect to that server and discover its tools at runtime. The server owner writes the tool surface once, and every connected client can use it.

|                             | Function calling                   | MCP                                      |
| --------------------------- | ---------------------------------- | ---------------------------------------- |
| Where tool definitions live | Inside each application            | On an MCP server                         |
| Who writes them             | The application developer, per API | The server owner, once                   |
| When tools are discovered   | When the app is built              | At runtime, via tools/list               |
| Reuse across clients        | One application                    | Any MCP-compatible client                |
| Good fit                    | A few APIs in one product          | Many APIs, shared across tools and teams |

Function calling gives a developer full control over every definition. MCP pays off as the number of APIs grows, because the work of describing each API happens once instead of in every application that needs it.

## What an agent needs from the APIs it calls

APIs built for human developers assume a person reads the docs, notices odd behavior, and fixes things by hand. An agent does none of that. Five properties matter much more once the caller is a model.

1. **Findability.** An agent can only use what it can discover. If the right API isn't in its tool list, or its description doesn't match how the task is phrased, the agent will either give up or try to improvise the result itself.
2. **Predictable contracts.** An agent writes its own requests from the schema. Consistent input formats, typed errors, and stated limits let it get the call right, and recover when it doesn't.
3. **Cost it can reason about.** A single task can trigger many calls. When the price of each call is visible and comparable across APIs, the agent (and the person supervising it) can weigh cost before committing.
4. **Tolerance for uneven traffic.** Agents fan out. They call several tools in parallel or retry in quick succession. Strict per-second limits turn that normal behavior into failures.
5. **Trust it can check.** A person builds trust in a vendor over time. An agent has no gut feeling. It can only rely on properties it can read, such as where a service runs and how it handles data.

When an agent works with APIs from many separate vendors, each of these properties varies from one API to the next: different documentation styles, different error formats, different billing units, different rate limits, and compliance information that sits in PDFs and web pages rather than anywhere a model can read it.

## Guardrails for beginners

Giving an agent access to APIs gives it the ability to act, and that needs limits. The [OWASP Top 10 for LLM Applications (2025 edition)](https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf) lists Excessive Agency (LLM06) as a core risk and traces it to three root causes: excessive functionality, excessive permissions, and excessive autonomy. The MCP specification adds that there SHOULD always be a human in the loop with the ability to deny tool invocations.

Four habits address those risks:

* **Give the agent only the tools its task needs.** A focused tool set is safer, and it also makes the model better at picking the right tool.
* **Keep credentials out of the model's reach.** Keys belong in the host or the server, scoped to what the agent is meant to access.
* **Require approval for high-impact actions.** Reading data is low risk. Sending messages, moving money, or deleting records should wait for a human decision.
* **Set spending and usage ceilings.** A looping agent can run up real costs, and a hard cap stops a bad loop early.

## Where ApyHub fits

[ApyHub](https://apyhub.com/) is a curated catalog of APIs and an operational layer designed for both developers and AI agents. It addresses the five needs above in one place, so a team doesn't have to reconcile them across dozens of vendors.

**Findability through ApyHub MCP.** Every endpoint in the [catalog](https://apyhub.com/catalog) is accessible via ApyHub MCP, so an AI agent can discover, evaluate, and call an API directly without a hand-written wrapper or tool definition. The agent searches the catalog by describing the task in plain language, and teams can scope which APIs their agents see, which keeps the tool set focused in line with the OWASP guidance above. Connecting a client takes under five minutes.

**Predictable contracts.** APIs are curated and verified before they are listed, and each one exposes a full machine-readable schema that an agent can read before it calls. Requests go through one gateway with one authentication model, so the agent handles one way of calling APIs rather than one per vendor.

**Cost in one unit.** Usage is priced in atoms, a single unit that reflects the actual work each call performs, and an agent can see the cost of an endpoint before calling it. One subscription covers the whole catalog, so atoms bought for one API can be spent on any other.

**Room for bursts.** ApyHub supports bursting, which lets usage briefly exceed the base rate limit within a controlled threshold. Short spikes from parallel agent calls are absorbed instead of turning into rate-limit errors.

**Trust an agent can read.** Every endpoint carries machine-readable certification describing data handling and alignment with GDPR, SOC 2, and ISO 27001. That turns compliance from a document someone has to find into a property an agent, or the team behind it, can check before a call.

For a closer look at how the server works, see [ApyHub MCP Server: Native API Discovery and Execution for AI Agents](https://apyhub.com/blog/apyhub-mcp-server-native-api-discovery-and-execution-for-ai-agents).

[**Explore the catalog →**](https://apyhub.com/catalog)

## A starter checklist

If you are connecting your first agent to APIs, work through this list:

1. Write down the tasks the agent should handle, and give it only the tools those tasks need.
2. Read each tool description the way a model would. If it doesn't say what goes in, what comes out, and when to use it, rewrite it.
3. Test each API directly before testing it through the agent, so you can tell agent mistakes from API problems.
4. Decide which actions need human approval, and configure the host to ask.
5. Set a spending cap, and check that errors tell the agent when to stop.
6. Log every tool call with its arguments and result, so you can see what the agent actually did.

For ideas on which capabilities to give an agent first, see [Top 5 APIs Every AI Agent Needs in 2026](https://apyhub.com/blog/top-5-apis-every-ai-agent-needs-2026).

## Conclusion

An AI agent uses an API in four steps: it discovers the tool, decides the tool fits, calls it with arguments it writes itself, and reads the result to choose its next move. Function calling and MCP are two ways to give an agent those tools, and the right choice depends on how many APIs you need and how many clients will share them.

How well an agent performs depends as much on the APIs as on the model. It needs APIs it can find, contracts it can follow, costs it can compare, limits that tolerate bursts, and trust signals it can read. Getting those from one layer is simpler than assembling them vendor by vendor, which is the problem ApyHub is built to solve.

[**Try ApyHub →**](https://apyhub.com/)

## FAQ

**How does an AI agent know which API to call?** It reads the name and description of every tool it has been given and matches them against the task. If a description doesn't clearly say what the tool does and when to use it, the agent is unlikely to pick it.

**Does the AI model make the API request itself?** No. The model produces the tool name and arguments as structured JSON. The host application sends the request, handles authentication, and passes the response back.

**What is the difference between function calling and MCP?** Function calling defines tools inside one application, written by that application's developer. MCP defines tools on a server that any compatible client can connect to and discover at runtime.

**Do I need to write code to let an agent use an API?** With function calling, yes: you write each tool definition and the code that runs it. With an MCP server such as ApyHub MCP, a compatible client can connect and use the available APIs without new integration code.

**Can an AI agent see my API keys?** It shouldn't. Keys belong in the host application or the MCP server, and the model only sees tool names, arguments, and results.

**What happens when an API call fails?** The error returns to the model's context, and the model decides what to do next. Specific, typed errors help it correct the request or stop, while vague errors often lead to repeated retries.

**How do I keep an agent's API costs under control?** Set a hard usage cap, give the agent only the tools it needs, and prefer APIs that show the cost of each call up front. On ApyHub, every call is priced in atoms, so costs are comparable across the whole catalog.

**Is it safe to give an agent access to many APIs?** Only with limits. OWASP's 2025 list names excessive functionality, permissions, and autonomy as the root causes of agent misuse, so scope the tool set to the task and keep a human on high-impact actions.

## About ApyHub

[ApyHub](https://apyhub.com/) is a curated API catalog and trusted operational layer for developers and AI agents, with over 1,500 endpoints or capabilities and growing. Teams use the whole [catalog](https://apyhub.com/catalog) through a single subscription priced in atoms, a unit that reflects the actual work each call performs. Every endpoint ships with machine-readable certification aligned with GDPR, SOC 2, and ISO 27001, and is MCP-ready by default, so AI agents can discover and call it without custom wrappers. ApyHub is headquartered in Amsterdam, with offices in the Netherlands, Greece, and India, and serves 65,000+ developer workspaces every month. The free Starter plan includes 5 API calls per day and 1,000 atoms per month, with no card required. Building an API of your own? [Become a provider →](https://apyhub.com/api-provider)