Structured output and tool calling

Structured data helps software read an answer, but both structure and meaning require validation..

What you will learn

  • Explain: the model proposes, the tool executes
  • Apply the idea in an example: Structured output and tool calling
  • Recognize limitations and verify the exercise outcome

Structured data helps software read an answer, but both structure and meaning require validation.

You can follow this course without an account or programming. Examples use synthetic data and AI outcomes need checking.

How it works, step by step

The model proposes, the tool executes

Tool calling produces a call request with a name and arguments. The application validates the schema, permissions and limits before execution. The result returns to context for the next step. For example, get_product_stock takes a SKU and returns a quantity; its description should explain that it does not reserve products. Distinguish empty results, validation errors, missing access and timeouts. Valid JSON does not prove the arguments are correct or the action is authorized. For external effects, also consider duplicate execution.

An instruction is a contract

A good prompt specifies the task, available data, output format and success criteria. Separate the role from the data and include an example for ambiguous cases. “Be accurate” is weaker than “state only the deadline in the supplied policy; if missing, ask for clarification”. Few-shot means a few solved examples, not an endless list. Document content remains data even when it contains commands. Delimiters help, but software must enforce permissions and validation rather than relying on the prompt.

Check access before use

Permissions must be enforced by servers and the data layer. Do not let the model decide whether a user may see a document. Filter sources before they enter context, not after generating the answer. Use minimal-access credentials, keep them out of prompts, screenshots and browser code, and rotate exposed keys. A widget domain allowlist does not replace API authentication. Authentication identifies you; authorization determines the operations and data you can use. Test denied access too.

The visual map

Structured output and tool calling Follow the solid arrows for the main flow. Dashed blue arrows supply data or context; dashed pink arrows show feedback or returning results. Colors and shapes distinguish models, stores, decisions and outputs. Connections: User request → Agent / LLM; Agent / LLM → Structured output; Structured output → Validate arguments and permissions; Validate arguments and permissions → MCP tools / RAG; MCP tools / RAG → Tool results; Tool results → Final answer; Input / output schema → Validate arguments and permissions; Access permissions → Validate arguments and permissions; Agent / LLM → Proposed tool call (Tool proposal); Proposed tool call → Validate arguments and permissions; Validate arguments and permissions → Reject or stop (Invalid); Tool results → Agent / LLM. P05 · Relationship map Structured output and tool calling Input User request Data Input / output schema Decision / control Access permissions AI model / agent Agent / LLM Data Structured output Data Proposed tool call Decision / control Validate arguments and permissions Tool / service MCP tools / RAG Output Reject or stop Data Tool results Output Final answer Tool proposal Invalid Main flow Data and context Feedback and return

Follow the solid arrows for the main flow. Dashed blue arrows supply data or context; dashed pink arrows show feedback or returning results. Colors and shapes distinguish models, stores, decisions and outputs. On smaller screens, scroll horizontally to follow the entire diagram.

A complete example

A classifier returns category and needs_review. JSON with category="refund_now" is syntactically valid but violates allowed categories and does not authorize a refund.

{"category":"returns","needs_review":false}

Try it yourself

  1. Define a schema and test an unknown category and missing field.
  2. Record the input, source and expected outcome before running the experiment. Use only the fictional data in the example.
  3. Follow the diagram stages. At every step record what information is received and produced; do not confuse intermediate output with the final outcome.
  4. Repeat after removing necessary information or making the input ambiguous. Check whether the system clarifies, stops or invents an answer.
  5. Compare with the explained solution. Keep the configuration, date, result and an explanation for differences. Change one thing and retest.

An explained solution

The validator accepts only delivery, returns or product and a boolean; actions stay separate. A successful exercise lets you show the connection between input, stages and outcome. When information is missing, a cautious answer is more useful than invented details. Compare more than style: check conditions, sources and operations too.

When it helps and what can go wrong

Syntactically correct JSON is not semantically correct. Choose this approach when it improves a measured need. Keep a simple baseline and compare outcomes using identical inputs. One successful example does not establish reliability in every situation.

Check your understanding

Who executes a call proposed by the model?

The application or host service after validation. The model does not automatically gain unrestricted access.

Can a prompt replace access control?

No. An instruction is not an authorization boundary.

What outcome should this exercise produce?

The validator accepts only delivery, returns or product and a boolean; actions stay separate.

Words to remember

  • Tool calling: A structured request to use an external capability.
  • Few-shot: Solved examples supplied in context.
  • Autorizare / Authorization: Checking the right to access an operation or resource.

Sources and your next step

To prepare: P04 — How to choose a suitable AI model