Skip to main content

Letting the Model Act

On its own, a model can’t act on anything outside itself. It can’t check today’s calendar, look up an order or add up a spreadsheet. Ask it anyway and it may guess. There are two places you’ll want to give a model more reach: in the app you’re shipping, so it can act on live data, and in the editor you’re building with, so it stops guessing about APIs. This lesson covers both:
  • Part 1: Tools in your app. With tool use (also called function calling), you describe functions your app can run. When the model needs one, it asks your app to run it, your app sends back the result, and the model uses that result in its answer. The model decides what to do; your code does it.
  • Part 2: MCP in your editor. MCP is an open standard for connecting AI tools to outside sources. You’ll use it to give your coding assistant Gloo’s docs, so its answers about the API stay current.

Core Concepts

Part 1: Tools in Your App

The Tool Loop

In its simplest form, the loop has five steps and two requests:
  1. You send the question and your tool definitions. Each tool has a name, a description and parameters, a JSON Schema for its inputs (the same kind of schema as in Lesson 3).
  2. The model replies with a tool call instead of an answer: the tool’s name and the arguments it wants to use.
  3. Your app runs the function with those arguments.
  4. You send a second request with the conversation so far, the model’s tool call and your result.
  5. The model writes its answer using the result.
The model can also ask for several tools at once, or for another tool after it sees a result. Run every call it asks for, and repeat steps 3 and 4 until it answers. The model never runs anything itself: your app acts, so you decide what’s allowed.

Writing Good Tool Definitions

The model chooses tools by reading your descriptions, so write them for the model:
  • Name says what it does: get_service_times, not tool1.
  • Description says when to use it, in a sentence or two.
  • Parameters are as specific as you can make them: use enum for a fixed set of values, and mark what’s required.

Choosing When Tools Are Used

tool_choice controls whether the model must use a tool. Leave it out and the model decides. Set it to "required" to make the model call one, which is how Lesson 3 got structured output.

Part 2: MCP in Your Editor

What MCP Is

The Model Context Protocol (MCP) is an open standard that lets AI tools, such as Claude, Cursor, VS Code and ChatGPT, connect to outside data sources and search them directly. Gloo hosts an MCP server for its documentation at https://docs.gloo.com/mcp. Connect your coding assistant to it, and when you ask how to call a Gloo endpoint, it looks up the current docs instead of relying on what it learned in training. So its answers about model IDs, fields and URLs come from the docs as they are today.

Get Started

Part 1: Run the Tool Loop

This example gives the model one tool, runs each function it asks for, and sends back the results until the model answers. It uses the guarded Responses endpoint (with Gloo’s guardrails, priced at the model’s rate plus 6.5%), as in the Tool Use guide.
Python
The first response contains a function_call item like this:
The call_id ties your function_call_output to the call it answers, so both items need the same one.

Part 2: Connect Your Coding Assistant to Gloo’s Docs

In Claude Code, one command adds the docs server:
In Cursor, add it to mcp.json:
Then ask your assistant something like “What models does Gloo AI support?” and it searches the docs to answer. The MCP Integration guide has steps for VS Code and Claude too, plus one-click setup from the menu at the top of any docs page.

Good to Know

  • Use the nested tool schema. Define tools as {"type": "function", "function": { ... }} on both the Responses and Chat Completions endpoints. The flat Responses tool schema isn’t reliably accepted across providers. In TypeScript, the SDK’s types expect the flat schema, so the Tool Use guide adds // @ts-ignore.
  • Pin the model. Tool calls behave most consistently when the same model handles every call. Avoid auto-routing for tool workflows.
  • Check the model supports tools. The catalog’s supports_tools flag tells you. See Supported Models.
  • Validate arguments before acting. Treat the arguments like any user input. Check them before you query a database or send a message.
  • Don’t repeat side effects. If a request is retried after a tool already ran, a tool that sends an email could send it twice. Give each tool run an ID so a repeat can be spotted and skipped. Handling Streaming Failures covers this.

Key Takeaway

Tool use lets the model ask your app to do things it can’t do alone: fetch live data, look things up, run exact calculations. You define the tools, the model asks for them, your code runs them and sends back the result. In your editor, MCP lets your coding assistant search Gloo’s docs, so its answers about the API stay current.
Try it on Gloo: the Tool Use guide shows tool calls on both the Responses and Completions endpoints, and MCP Integration connects Gloo’s docs to Claude, Cursor or VS Code in a minute.

Learn more


What’s next

Next, you’ll see how a coding agent runs this tool loop again and again to finish a whole task, and where a person approves what it does.

Lesson 5: Coding Agents

How an agent plans, acts and checks its work.