An API integration uses the tool_choice parameter set to {"type": "tool", "name": "generate_report"} to force the model to always call a specific tool. During production, engineers discover that when users ask conversational questions unrelated to report generation, the model still calls generate_report with semantically null arguments. What is the correct architectural fix?

The correct architectural fix is replacing tool_choice: {type: 'tool', name: 'generate_report'} with tool_choice: {type: 'auto'} so the model can decide whether to call the tool or respond in text based on the query. Forcing a specific tool instructs the model to always call that tool regardless of query appropriateness, so conversational questions still trigger generate_report with semantically null arguments. Automatic mode is the intended mechanism for letting the model use reasoning to decide when the tool is relevant and when a plain text response is more appropriate. The pre-processing classifier approach is wrong because it adds latency and a new failure mode: classifier error can lead to incorrect routing, while the simpler fix is changing tool_choice to auto and relying on the model's built-in routing judgment. The default none with keyword switching approach is wrong because keyword-based routing is brittle and misses paraphrases such as 'show me the report' or 'generate the analysis'; automatic mode is more robust. The input validation required-fields approach is wrong because adding required schema fields changes the tool's data requirements but not the forcing behavior; the model will still attempt to call the tool, potentially fabricating required field values.