Function Calling

The important detail is that the model never executes anything. It emits a structured intent; your code decides whether to honour it. Providers constrain decoding so the emitted arguments conform to the supplied schema, which removes the brittle parse-the-prose step that early integrations relied on. The application then runs the function, appends the result to the conversation and calls the model again so it can use the outcome.

Because the schema and the descriptions are the entire interface the model sees, they are prompt engineering in a structured costume. A parameter named `q` with no description will be filled inconsistently; the same parameter named `search_query` with a one-line explanation of what belongs in it will not. Narrow enumerated types beat free-form strings, required fields beat optional ones, and a small set of well-named functions beats a large set of overlapping ones.

The misconception is that a validated schema means a safe call. Schema validation proves the arguments are well-formed, not that they are correct or authorised. A model can produce a perfectly valid request to delete the wrong record. Authorisation, rate limiting, idempotency and confirmation for destructive operations belong in the executing code, exactly as they would if the arguments had come from an untrusted client.