When should a model call a tool instead of answering from context?
Instruction: Explain how you decide whether the model should use a tool or answer directly.
Updated
Example Answer
I'd call a tool when the task needs current or private state, verification, or an authorized action. “What is a ticket?” can be answered from context; “Is my ticket still open?” needs the relevant system's current record.
I'd choose the narrowest capability that satisfies the request. A status lookup should not become a status update. Before execution, the application checks access and arguments; after execution, the answer reflects the returned state. If the tool is unavailable, I'd explain that I cannot verify the live status rather than guess from an old message. Tool use adds latency and failure paths, so it needs a concrete correctness or workflow benefit, not merely an available button.
Why this works
Distinguishes conceptual answers, live verification, and mutations with one clear intent contrast.
Practice follow-up
When could a dated cached ticket status still be useful?
Your preparation path
Work through these questions in order. Read the answer aloud, then explain it in your own words.
1. Start with the foundations
Build the vocabulary and explain the core decisions.
2. Apply it to a real workflow
Practice diagnosis, validation, and everyday tradeoffs.
3. Prepare for senior discussions
Explain failure boundaries, recovery, and production choices.
- Design a fallback strategy when tools are unavailable, degraded, or unauthorized. Member answer
- How do you implement MCP step-up authorization without losing scopes or retrying forever? Member answer
- An MCP request resumes after user confirmation. How would you validate its requestState? Member answer
Related Questions
-
easy
-
easy
-
easy
-
easy
-
easy
-
easy