Builder lab · Module 3 · 45 min

Tools & Function Calling

Declare tools, read a model's proposed call as an untrusted request, validate its arguments, gate every write behind human approval and handle failures without confusing intent with authorisation.

After this module you can

Declare tools an application is willing to expose, read a model's proposed tool call as an untrusted request, validate its arguments against a schema and a permission policy, gate every write behind explicit approval, and handle tool failures without confusing model intent with authorised action.

Explain what changes structurally when a model emits a tool call instead of prose.
Write and correct a tool schema: name, description, argument types, enums, formats, required fields, additionalProperties.
Separate read tools from write tools and apply a different policy to each.
Reject, correct or execute a proposed call on the evidence in its arguments.
Place an approval gate so no simulated write happens without a human decision.
Handle tool unavailability, permission denial, bad arguments and duplicate submissions with idempotency.

Module 1 produced structured output. Module 2 grounded it in retrieved evidence. Module 3 lets the application do something — under a policy the model does not control.

Step 1

Text output vs a tool call

Same synthetic consultation, same request: prepare the follow-up. Two very different things came back.

Everything here is simulated. The tool registry, the patient record and every tool result are synthetic fixtures. Tool execution is a local pure function with fixed outputs. Nothing leaves this browser.

Visual Guide 01 — FHIR · API · MCP · RAG · LLM

Keep the terminology map next to you while you continue the technical track.

Open visual guide

User requestLLMProposed tool callSchema + permission validationApproval gate (writes)Tool executionTool resultLLM / user

A · Text output

assistant message

I have created a follow-up appointment request for the patient
in four weeks and sent them a message explaining the plan.

B · Proposed tool call

assistant tool_calls

{
  "tool_calls": [
    {
      "id": "call_01",
      "name": "create_follow_up_task",
      "arguments": {
        "patient_id": "SYN-004821",
        "due_date": "2026-10-02",
        "reason": "Four-week review of reflux treatment",
        "priority": "routine"
      }
    }
  ]
}

Which statements are true? Select every one (3 or more, with no wrong picks).

Select at least 3 true statements, with no incorrect picks.

Lab progress

0 of 8 steps complete

Sources & evidence · 5 sources

This module cites public or consensus guidance, technical documentation, vendor documentation.

Content reviewed: September 2026. Publication dates of the individual sources are shown in each citation.

JSON Schema — Specification and validation keywords
The vocabulary behind type, pattern, enum, required and additionalProperties used throughout this lab.
Open source
OpenAI — Function calling guide
One provider's concrete mechanics. The pattern — declare, propose, validate, execute, return — is provider-agnostic.
Open source
Anthropic — Tool use documentation
A second provider's implementation of the same loop, useful for seeing what is common and what is vendor detail.
Open source
NIST AI Risk Management Framework — Generative AI Profile
Where human oversight of consequential actions sits in a risk framework.
Open source
Model Context Protocol — specification, protocol revision 2026-07-28 (released 28 July 2026).
Official description of clients, servers, tools, resources and prompts. Read it as an exposure and discovery standard: validation, permissions and approval remain application responsibilities. Revision-pinned; checked 10 September 2026.
Open source