<\/p>\n
Function calling lets a model select a predefined operation and produce structured arguments for it. The application, not the model, should decide whether that operation is allowed and actually execute it.<\/p>\n
A tool may represent a database lookup, search request, calculator, ticket action, or business API. Define a clear name, purpose, argument schema, and expected result.<\/p>\n
Tool and function calling extends generative AI from producing text to invoking application behavior; the AI-900 learning path<\/a> provides the foundational workload map behind that transition.<\/p>\n Treat the model’s tool request as untrusted structured input. Validate types, ranges, identifiers, and authorization before execution.<\/p>\n This separation is one of the most important design rules in tool-enabled AI.<\/p>\n A tool schema can require fields, restrict enumerated values, and distinguish optional from mandatory arguments. Good schemas make invalid actions easier to reject.<\/p>\n Do not expose one giant \u201cdo anything\u201d tool when several narrow interfaces would create clearer control.<\/p>\n The model needs enough description to choose the right tool and understand when not to use it. Overlapping descriptions can make selection unpredictable.<\/p>\n Test realistic requests and inspect which tool was chosen, not only whether the final answer sounded reasonable.<\/p>\n Return concise status, data, and error information that the application and model can interpret. Avoid dumping enormous raw payloads into context when a smaller structured result is sufficient.<\/p>\n Combining models with application services requires explicit interfaces, schemas, and error handling; Azure AI solution design<\/a> treats those integrations as part of AI solution design.<\/p>\n A prompt saying \u201conly update records the user owns\u201d is not a sufficient security boundary. The tool should enforce the user’s identity and allowed scope.<\/p>\n Authorization should be enforced at the tool or service boundary rather than inferred from model context; zero trust security<\/a> follows the same explicit-verification principle.<\/p>\n Deletion, financial changes, production configuration, or external communication may need human confirmation even if the tool call is valid.<\/p>\n Approval should occur after the intended action is visible and before the irreversible step.<\/p>\n Search results, retrieved documents, and API responses may contain text that tries to influence the model. Keep the distinction between data and privileged instructions.<\/p>\n Tool outputs may expose sensitive information if permissions are too broad; AWS data protection guidance<\/a> separates identity and data-protection controls around that risk.<\/p>\n Distinguish validation errors, permission denials, not-found results, timeouts, and transient service failures. The agent can then choose an appropriate next step.<\/p>\n Do not return every failure as a generic string that encourages the model to guess.<\/p>\n If a tool changes state, repeated calls should be safe where possible. Use request identifiers, deduplication, or explicit status checks for operations that may retry.<\/p>\n Automated actions need idempotency, retries, validation, and rollback just like other delivery automation; Azure DevOps engineering<\/a> supplies that operational discipline.<\/p>\n Record which tool was requested, validated arguments, authorization decision, execution result, duration, and correlation ID. Protect secrets and sensitive payloads in logs.<\/p>\n These traces are essential when a final answer depends on several hidden operations.<\/p>\n A deterministic test suite should confirm schemas, permission checks, errors, and side effects independently. Then evaluate whether the model chooses and uses the tools correctly.<\/p>\n AI applications remain software systems with ordinary reliability and security obligations; the Azure AI Engineer course<\/a> makes that engineering boundary clear.<\/p>\nThe model proposes; the application executes<\/h2>\n
Schemas reduce ambiguity<\/h2>\n
Tool descriptions affect selection<\/h2>\n
Results should be structured<\/h2>\n
Authorization belongs outside the prompt<\/h2>\n
Sensitive actions may require approval<\/h2>\n
Tool output can be untrusted<\/h2>\n
Failures need typed responses<\/h2>\n
Idempotency protects retries<\/h2>\n
Observability should trace each call<\/h2>\n
Tools should be testable without the model<\/h2>\n
Tool use creates a distributed application<\/h2>\n