…
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, a sub-agent, and finally a Model Context Protocol (MCP) server. These are different ways to supply capabilities to the same loop. A long flat tool list also consumes context and can make routing less reliable, which motivates the scoped workflows in Module 2.

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 LLM asks, your code answers, and the LLM concludes, but it never runs your function itself.
The server enforces the schema. Before structured function calling, applications often parsed custom XML or hand-written JSON from model text. A paraphrase could break that parser. The tools field carries the contract separately, so the serving engine can constrain arguments to the schema and return a consistent tool_calls field. Your dispatch code can then count on tc.function.name and tc.function.arguments being present and parseable.

How the model picks between several tools

Agents rarely have a single tool. With more than one, the model decides which to call based on the description field.

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 an exact term lookup 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.
Applied · BackendSwap 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.
Deep · DelegationHide 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 knows a small customer table as one natural-language tool. Its caller never sees the rows and can only ask questions.

The cognitive-load lever. Every additional tool, schema field, and description sentence consumes context the main agent could use for its task. A sprawling flat tool list tends to perform worse than a small set of tools backed by sub-agents, because each loop only sees the tools relevant to its level.

Fetching tools from a separate server with MCP

Applied · BuildNeed the MCP discovery and invocation flow?

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 agent loop is byte-for-byte identical to a normal tool call while only the source of the tool list changes.

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

  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?
Deep · SourcesReview 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