A developer is building a Foundry-hosted travel assistant that needs to check real seat availability from the airline's reservation system before confirming a booking to a customer. Instead of asking the model to guess or describe availability in prose, which approach should the developer use so the model reliably invokes the airline's API with correctly structured parameters?
Select an answer to reveal the explanation.
Short Explanation
Picture asking a smart but ungrounded assistant to check if a flight has open seats. If you only tell it the rules in plain language, it can talk about availability convincingly, but it has no real way to look anything up, so it's essentially guessing in fluent sentences. Training it on lots of old booking examples doesn't fix that either, it just gets better at sounding like past answers, which may no longer be true today. And cranking up its creativity setting makes things worse, not better, since you want one reliable number, not several inventive ones. What actually solves the problem is giving the assistant a well-defined action it can take, with clearly labeled inputs, so that when a seat-availability question comes up, it fills in those inputs and hands them off to the airline's real system, then reports back the real answer. That's the difference between an assistant that talks about checking availability and one that actually checks it.
Full Explanation
The correct answer is C. Defining a function or tool with a strict parameter schema lets the Foundry-hosted model recognize when a request requires live seat data and invoke the airline's API with correctly typed, structured parameters instead of generating an answer from its own text patterns. Option A is incorrect because a system message can only set static instructions and phrasing rules; it cannot connect to a live reservation system or guarantee the model produces machine-readable, correctly structured request parameters. Option B is incorrect because fine-tuning teaches the model to reproduce patterns from past examples, which means it would generate plausible-sounding but potentially stale or fabricated availability rather than checking the live system at booking time. Option D is incorrect because raising temperature increases the randomness and variety of generated text, which works against the goal of reliably invoking an external system with precise, consistent parameters, and can make outputs less predictable rather than more accurate. Since the travel assistant must retrieve real, current seat availability and act on it correctly, structured function calling is the mechanism designed specifically to let a model trigger an external system with validated inputs rather than describe an answer in prose.