Tools and Knowledge: How an Agent Reaches Past the Model

What this slice covers

A model alone can only produce text from what it was trained on and what you paste in front of it. Tools are the mechanism that lets an agent consult something it does not know and do something in the world. This note covers the two purposes tools serve, what attaching one actually involves, the shape of the tool catalogue, where execution happens, and what changes once an organisation has more tools than any single agent can carry.

Knowledge and action

Microsoft frames tools around two verbs. You make an agent more capable either by giving it knowledge — specific files or indexes it can search — or by allowing it to take actions, such as calling external APIs. Almost every tool you meet is one or the other, and keeping the pair straight is the fastest way to reason about a scenario question.

Knowledge tools change what the agent can find out. File search over uploaded documents and a search index over your corpus both sit here, and both are grounding mechanisms: the agent retrieves passages and answers from them rather than from recall. Action tools change what the agent can do. An OpenAPI-described REST API, a Model Context Protocol server, or a call to another agent all sit here, and all of them mean the agent's output can have consequences beyond the conversation.

Some tools blur the line usefully. Code interpreter writes and runs code in a sandbox, which is an action taken in service of producing a knowledge-like answer — a calculation, a transformation, a chart.

What attaching a tool involves

The practical rule is short and easy to trip over: to save an agent with a tool attached, the tool must be configured successfully first. If a tool needs authentication or a connection to a resource, complete that setup before you try to save the agent version. This is why "add a tool" is often a two-part task — the tool itself, and the connection that lets it reach the thing it talks to.

The good news is that configured tools are reusable. Once a connection exists in the project, other agents can use it, so the setup cost is paid once per resource rather than once per agent.

The catalogue, and where code runs

The tool catalogue spans several shapes: web search, search over an index, code interpreter, file search, OpenAPI-described services, MCP servers, agent-to-agent calls, browser automation, and connectors to enterprise data surfaces such as SharePoint, Fabric, and Work IQ.

One distinction in that list matters more than the rest. Function calling executes on the client side — the service tells your application which function it wants called and with what arguments, and your code runs it and returns the result. Most other tools execute service-side. This is a security and architecture fact, not a trivia item: a function-calling tool runs inside your trust boundary with your process's permissions, whereas a service-side tool runs with an identity Foundry manages.

The scaling problem, and Toolbox

At one agent with three tools, none of this is hard. The picture changes when an organisation builds many agents. Each agent wires its own tools, so the same integration gets re-implemented by different teams, credentials get duplicated across agents that each manage their own secrets and token refresh, and nobody can answer which tools exist or who is using them.

Toolbox is the answer to that shape of problem. It provides a centralised way to define a curated set of tools once and expose them through a single MCP-compatible endpoint that agents consume across frameworks and runtimes. Because the toolbox is a managed resource, tools can be added, removed, or updated without changing agent code — and versioning lets you promote a new default version that consuming agents pick up without redeployment. It is not restricted to agents built in Foundry: any MCP-compatible runtime or client can use one.

Two capabilities inside Toolbox are worth naming because they answer problems learners can predict. Tool search addresses the fact that sending every tool definition on every request costs input tokens whether the tool is used or not, crowds the context window, and degrades selection accuracy once a model must choose among hundreds of options; it hides tools by default and exposes two meta-tools, one to describe what you need and get relevant tools back, and one to invoke a discovered tool by name. Skills package reusable, multi-step workflows that agents invoke like any other tool — where tools define what an agent can do, skills define how a task gets performed.

Mistakes people make

Attaching a tool and expecting the save to succeed before finishing its authentication is the most common. Assuming every tool executes server-side, and therefore misreading where a function actually runs, is the most consequential. Adding tools indiscriminately is the quietest failure: every definition you attach competes for context and makes the model's choice harder. And treating a tool as a substitute for grounding discipline — attaching search and assuming accuracy follows — skips the validation step that tools were supposed to make possible.