The agent loop and where tools fit
An LLM on its own only produces text. An agent is an LLM wrapped in a loop that can take actions. On each turn the model is shown the conversation plus a list of available tools (each described by a name, a short description, and a JSON schema for its inputs). The model either answers or emits a tool call; the runtime executes that call, appends the result to the context, and runs the model again. The loop ends when the model decides it has enough to answer.
Tools are therefore the agent's entire interface to anything outside the model: a calculator, a SQL query, a file write, a web search, a page fetch. The model never runs code itself - it asks the runtime to, and reads the result. Good tool design is mostly good descriptions: the model chooses a tool the same way it chooses words, by matching your description text against the task.
How tools reach the model: tool use vs MCP vs frameworks
There are three common ways to wire a tool to an agent, and they are not exclusive.
| Path | What you provide | Reaches | When to use |
|---|---|---|---|
| Native tool use / function calling | A JSON schema per function in the API call | One model/provider | You control the agent code and want the shortest path |
| MCP server | A server exposing tools over a shared protocol | Any MCP client (Claude Code, Cursor, etc.) | One tool, many clients; no per-client glue code |
| Framework tool | A class/function in LangChain, LlamaIndex, CrewAI | Agents built in that framework | You already build agents in that framework |
A Claude Skill is a fourth, complementary layer: not a tool itself, but packaged instructions that tell the model how and when to use the tools it already has.
Web-access tools are the hard part
Most agent tools are simple: a calculator always returns the right answer, a file read either succeeds or throws. Web-access tools are different, because the web actively resists automated clients. A "fetch this URL" tool that does a plain HTTP request works on a static blog and then returns an almost-empty shell on any site that renders content with JavaScript, or a verification page on any site behind bot protection.
The failure is quiet, which is the dangerous part: the tool returns something, the model treats it as the page, and the agent confidently reasons over a challenge screen. Reliable web-access tooling therefore needs real browser rendering and residential IPs underneath - the same infrastructure a web scraping API provides. Pointing an agent's fetch and search tools at a managed web-data API that returns clean Markdown is the most reliable way to give an agent web access; see web scraping for LLMs for the full pipeline.