What information should the orchestrator validate before executing a tool call?
Instruction: Describe what should be checked before a tool request is allowed to run.
Updated
Example Answer
I'd validate the proposed request at several boundaries. First check tool identity, schema, and argument completeness. Then derive the user and tenant from trusted authentication, check object access and business rules, and verify any required approval still covers this action.
For a customer-address update, valid JSON is insufficient if the record belongs to another tenant or changed after preview. I'd check the expected version and bind approval to the target and patch. Credentials should stay out of model arguments and logs. The tool server must enforce its own checks even if the host approves. A denial should stop the mutation and return an actionable reason, rather than invite the model to find a more powerful tool.
Why this works
Shows validation on a concrete write and preserves independent server authorization.
Practice follow-up
Which validation failures should the assistant repair automatically, and which need user input?
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