…
Module 1 · Part C of 3

Tools at Scale

In Module 1b you wired a single tool into the agent loop: the model requested a named function, your harness ran it, and the result went back into the next model call. That round-trip does not change here. What changes is the tool surface: the model must choose among more descriptions, and each tool may hide a larger capability.

The page follows that contract from local functions to a search backend and a sub-agent. A sub-agent as a tool places one focused agent behind a single schema so the outer workflow can route work without exposing every internal capability. Model Context Protocol (MCP) gives a client a standard way to discover and call tools served by another process. Use it at a capability boundary, after validating the server, identity, and scope. Both patterns keep the main loop's tool list small and motivate Module 2's scoped workflows.

The tool-call contract stays fixed

The figure traces the cycle from 1b. Later sections change where the schema comes from and what the executor does, while the model still requests a named tool and reads its result.

The model requests a tool. The harness executes it and returns the result for the model's next decision.
Validate the tool request before execution. The input schema describes the argument names, types, and required fields offered to the model. It does not execute the tool or guarantee that the model's proposed arguments are safe. Check the returned name, parse the arguments, and validate their values before dispatch. The examples below show the requested calls and stop on invalid input.

How the model picks between several tools

With several tools available, the model uses their names, descriptions, argument schemas, the conversation, and any tool_choice constraint to propose a call. The description in each tool definition explains when that tool is useful. Inspect the Tool spec node below for the complete definition, or consult the function-calling guide for the request format.

The cell below gives the model two tools and a question that requires picking, and the visualization shows which way the model went and why.

Editing either description shifts how the model routes, since the description field is one of the most consequential prompt-engineering surfaces in any tool-using agent.

Wiring glossary_search to a real tool

The cell wires glossary_search to an in-page catalog of NVIDIA terms. Ranked search runs in the browser without a key and returns short definitions with source links. The course's shared web_search applies the same ranking to the full catalog. Open the glossary explorer to inspect every term, read the live webSearch and instantAnswer source, or run the query yourself.

The next section swaps the executor to full-article retrieval behind the same tool contract, so you can watch the contract stay fixed while the backend changes underneath it.

A tool name should describe a capability. A tool called nvidia_glossary_api is brittle: changing the backend forces you to update every prompt that references the name. A tool called glossary_search describes what the caller needs. Ranked search, exact lookup, or a richer index can sit behind that contract without changing the agent prompt.
Swap the executor without changing the tool?

Swapping the backend while the tool contract holds

The same loop runs here as a flat mountRunCell script, with one change: the executor. The earlier search returned a short blurb for each of several matches. This backend returns the whole article for the single best match, fetched from the term's cached glossary page. The schema and the loop do not move; only the source behind glossary_search got richer.

The model only sees the contract. It asks for glossary_search with a natural query and reads whatever comes back, unaware which backend answered. You can start with a blurb index and later swap in full articles or a live search without touching the loop. Accuracy may drift when a backend resolves a match differently, but the contract holds.
Hide a focused agent behind one tool?

Hiding a whole agent behind a single tool

A tool need not be a small function. An entire sub-agent can sit behind a single tool call. To the calling model, the sub-agent remains one contract. Behind that contract, it may query a database, run code, or search a repository without exposing those internal tools to the main loop.

The cell below exposes a sub-agent that reads a small customer table through one natural-language tool. The rows are omitted from the main agent's initial context, but the sub-agent's returned answer can include row data. This separates context; it does not enforce data access control.

The outer model receives the sub-agent's answer, so errors or omissions in that answer become its evidence. Inspect both responses before deciding whether the result is supported by the table.
Need the MCP discovery and invocation flow?

Fetching tools from a separate server with MCP

Model Context Protocol (MCP) gives tool serving a standard shape. The agent retrieves a server's catalog with tools/list and invokes a selected entry with tools/call. Those tools live in a separate process that the agent connects to and queries when it starts up. Because the protocol is the same everywhere, the agent can connect to additional servers without learning a new interface for each one. Use MCP when tool discovery and transport need a shared protocol. Use a local function, a repo skill, or a direct API call when the harness already knows where the capability lives and how to invoke it.

Discovery is a trust boundary. Treat a tools/list response as untrusted input. Before connecting the server:
  • verify its identity,
  • show the requested capabilities to the user,
  • grant the smallest useful scope,
  • and bind each credential to that server's audience.
For remote connection and OAuth discovery, reject private and link-local destinations and validate every redirect. The MCP security guidance assigns consent, token handling, and server-side request forgery (SSRF) controls to the client.

The cell below fakes a tiny MCP server in pure JavaScript with the same JSON-RPC shape MCP defines (no transport). The agent fetches the tool list, hands the schemas to the model, then dispatches tool_calls back through the server's tools/call handler. The loop still requests a tool, executes it, and appends its result. Tool discovery and dispatch now go through the server interface.

Module 2 keeps this tool contract and changes the outer structure. A workflow can route calls through a fixed pipeline, fan work into branches, or delegate a focused task to another loop without exposing every internal tool to the caller.

Before you continue

Use your displayed tool calls and results as evidence. For the delegation and MCP questions, first open the optional sections Agents as tools and MCP; you can return to those extensions after the basic tool loop.

  1. What happens when the model calls a tool with arguments that fail your validation? The current loop crashes; how would you make it graceful without giving the model false confidence that the call succeeded?
  2. The agents-as-tools sub-agent is opaque to the main agent. What information would you want it to surface back (in addition to the answer) so the main agent can decide whether to trust it on the next turn?
  3. The tool_choice parameter can be set to "required" or to a specific tool name. When would forcing a tool call be the right move, and what risk does it create?
  4. Before you add a remote MCP server to this agent, what identity, capability scope, token audience, and network destinations would you verify? Which one becomes an SSRF path if you accept it without validation?
Review the tool-use and MCP sources?

References

Comprehensive list at Going Further · References.

Try it · an agent with two real tools

This artifact runs a LangChain createReactAgent wired to the two functions whose contracts you just read: calculate for arithmetic and glossary_search against the in-page NVIDIA glossary that runs in the browser without a key. Ask for a number it cannot work out in its head or a term to define, and watch the tool chip light up before the answer streams.

← Module 1b: The ReAct Loop