Tool use and the Model Context Protocol

Tools are how models reach beyond text. This module shows exactly how tool calls flow — and how to design tools models use correctly.

2.1 How tool use works

The model never runs code itself. Instead:

1. You describe available tools — each with a name, a description and a JSON schema for its inputs.
2. The model, seeing the user's request, decides to call a tool and outputs a structured request: tool name plus arguments.
3. Your code runs the tool and sends the result back.
4. The model uses the result to continue — calling more tools or answering.

This is often called function calling. Your code stays in control of what actually happens.

2.2 Defining a tool

Python · a tool definition (Anthropic format)tools = [{
    "name": "get_order_status",
    "description": ("Look up the delivery status of a customer order. "
                    "Use when the customer asks where their order is."),
    "input_schema": {
        "type": "object",
        "properties": {
            "order_id": {"type": "string", "description": "Order number, e.g. GFY-10422"}
        },
        "required": ["order_id"],
    },
}]

Tool descriptions are prompts. Say clearly what the tool does, when to use it and what inputs mean. Vague descriptions are a top cause of agents picking the wrong tool.

2.3 One round of tool use

Python · call the model, run the tool it asks for, send back the result# !pip install anthropic
import anthropic, json
client = anthropic.Anthropic()          # reads ANTHROPIC_API_KEY
MODEL = "YOUR-MODEL-NAME"

def get_order_status(order_id):         # your real system would query a database
    return {"order_id": order_id, "status": "dispatched", "eta": "Thursday"}

messages = [{"role": "user", "content": "Where's my order GFY-10422?"}]
response = client.messages.create(model=MODEL, max_tokens=500, tools=tools, messages=messages)

if response.stop_reason == "tool_use":
    call = next(b for b in response.content if b.type == "tool_use")
    result = get_order_status(**call.input)                 # YOUR code runs the tool
    messages += [
        {"role": "assistant", "content": response.content},
        {"role": "user", "content": [{"type": "tool_result", "tool_use_id": call.id,
                                      "content": json.dumps(result)}]},
    ]
    final = client.messages.create(model=MODEL, max_tokens=500, tools=tools, messages=messages)
    print(final.content[0].text)    # e.g. "Your order was dispatched and should arrive Thursday."

2.4 Designing good tools

• Few, clear tools beat many overlapping ones
• Meaningful names and descriptions, with examples of when to use each
• Strict input schemas — enums, formats, required fields
• Helpful results — return what the model needs, with clear error messages it can act on ("Order not found — check the format GFY-#####")
• Least privilege — read-only where possible; separate tools for risky actions so they can require approval
• Validate inputs in your code — never trust the model's arguments blindly

2.5 The Model Context Protocol (MCP)

Writing custom integrations for every app and every model doesn't scale. The Model Context Protocol, an open standard introduced by Anthropic in 2024 and now supported across many AI tools, defines a common way for AI applications (clients) to connect to servers that expose tools, resources (data) and prompts. Build an MCP server for your system once, and any MCP-compatible assistant or agent can use it.

Key takeaways

• The model requests tool calls; your code executes them and returns results.
• Tool names, descriptions and schemas are prompts — make them clear.
• Return helpful results and actionable errors.
• Validate arguments in code; keep risky actions in separate tools.
• MCP standardises how AI applications connect to tools, data and prompts.