NVIDIANVIDIA-Certified Professional: Agentic AI2026-100 Prerequisites
Distinguish tool requests from structured answers
Completed by the knowledge check
Learning objective
Explain tool calling with JSON Schema function definitions and structured outputs.
Core idea
Tool calling asks a model to select a named operation and propose its arguments. Structured output constrains the shape of generated data. Both can use JSON Schema, but they serve different purposes: one requests an action from an executor; the other returns data to a consumer.
A schema-valid object establishes structural validity. It does not establish that the proposed operation is authorized, that its arguments refer to a real record, or that the generated facts are correct.
How it works
In the OpenAI-compatible Chat Completions shape used by NVIDIA NIM, the request’s tools array describes available functions. Each function has a name, a description, and a parameters schema. Here is an illustrative definition for a read-only shipment lookup:
{
"type": "function",
"function": {
"name": "lookup_shipment",
"description": "Read the status of one shipment by its identifier.",
"parameters": {
"type": "object",
"properties": {
"shipment_id": { "type": "string" }
},
"required": ["shipment_id"],
"additionalProperties": false
}
}
}JSON Schema’s properties defines the permitted named fields and their schemas; it does not itself make those fields mandatory. required supplies that requirement. additionalProperties: false rejects fields outside this object’s declarations. The example checks a string’s presence and type, not whether that shipment exists or belongs to the caller.
The model can return tool_calls instead of a final answer. The application parses the proposed arguments, validates them, invokes the selected implementation if permitted, and returns the execution result for the model’s next step. The model’s proposal alone is not evidence that a lookup ran. See 2.3.1 for complete tool definitions and 2.3.2 for execution-time controls.
The model only proposes the call; the application validates it and, if permitted, invokes the implementation.
NIM’s tool-calling page documents --enable-auto-tool-choice and a model-matching --tool-call-parser for its vLLM serving path. Some packaged model profiles configure parsers, so read that model’s deployment page before applying generic launch instructions. Supplying a schema to an arbitrary model or parser does not establish tool-calling support.
For a structured answer, vLLM documents response_format with type: "json_schema" and a json_schema containing name and schema. That schema describes the answer rather than an operation to dispatch. NIM publishes the running container’s request schema at /docs; verify the deployed interface instead of assuming every backend accepts identical fields. See 2.1.2 for schema-constrained output validation and repair.
Key distinctions and trade-offs
Valid JSON versus valid schema: An object can parse successfully while missing a required field. A schema can accept a string while the business system rejects the identifier it contains.
Parser versus executor: A parser extracts tool-call structure from model output. The executor performs the operation. Neither role can substitute for the other.
Output shape versus meaning: Constraining the response makes downstream parsing more predictable. It does not independently verify the response’s factual content.
Architecture / decision scenario
A freight assistant handles 3,000 status requests daily. Its customer-facing response needs two fields: shipment status and an explanatory sentence. The tempting shortcut asks the model to emit those fields directly because the response already parses as JSON. In an illustrative test of that shortcut, all 100 responses parse, but eight cite nonexistent shipments: a semantic failure despite perfect parsing.
The integration owner rejects that shortcut: the answer needs a live shipment lookup. The application exposes lookup_shipment, validates the proposed identifier, and executes the read before requesting the structured answer. Acceptance of the adopted design requires unknown identifiers to produce an explicit not-found outcome rather than a generated shipment status. The tool result supplies business data, while the answer schema supplies the downstream shape.
Common exam traps
- Assuming
propertiesmakes every field required. - Treating valid JSON as schema validation.
- Treating a tool call as proof of successful execution.
- Assuming schema conformance proves authorization or factual correctness.
What to remember
Use function schemas to describe callable operations and answer schemas to describe returned data. Validate at the receiving boundary, verify the deployed model and parser interface, and keep structural correctness separate from business correctness.
Knowledge check
A tool’s parameters schema declares "type": "object" and lists order_id and customer_id under properties, with no other keywords. A proposed call that contains only customer_id passes validation, and the refund lookup then fails. Which schema change makes the validator reject such calls?
requiredadditionalProperties to false"type": "string"order_id in the tool’s descriptionproperties declares the permitted fields and their schemas, but leaving a declared property out is still valid; required makes a field mandatory. additionalProperties: false rejects undeclared fields, a different failure, and neither a type nor a description makes a field present.A support dashboard counts a refund as issued whenever a model response contains a tool_calls entry for issue_refund. Finance finds refunds on the dashboard that were never paid. Which signal should the dashboard count instead?
tool_calls entries whose arguments pass the tool’s schema validationtool_calls entries extracted by a parser that matches the modeltool_calls entry is the model’s proposal: the application parses it, validates it and, if permitted, executes it. Schema-valid arguments and a correctly parsed call are still proposals, and a model’s statement is generated text, so only an executed operation whose recorded result reports success shows that a refund was issued.The running NIM container’s /docs confirms that it supports schema-constrained answers. A reporting job sends support transcripts to this model and needs back a JSON object with sentiment and topic fields for a dashboard, and the request should constrain the reply to that shape. No operation should be dispatched. Which request feature fits the requirement?
tools entry that the application executes to store both fieldsresponse_format of type json_schema describing both fields--tool-call-parser that extracts both fields from the reply/docs schema before relying on the field.A team serves a new model through NIM’s vLLM path and adds a tools array to its requests, allowing the model to choose whether to call a tool. The model replies with call-like JSON inside content, and tool_calls stays empty. Which check comes first?
parameters schema sets additionalProperties to falseresponse_format of type json_schema--enable-auto-tool-choice and a --tool-call-parser that matches the model. The parser extracts tool calls from model output; some packaged profiles already configure a parser, so read that model’s deployment page. A schema keyword governs validation, and execution can only follow a parsed call.References
- NVIDIA, Tool Calling and MCP Integration
- NVIDIA, Get Started with GLM-5.2
- NVIDIA, API Reference
- JSON Schema, object
- vLLM, Tool Calling
- vLLM, Structured Outputs