How would you design a tool contract for a model?

Defines a narrow capability with a clear name, decision-oriented description, typed inputs, and safe result semantics.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I give the tool a specific name, explain what it does and when to use it, and define a narrow input schema with meaningful descriptions and enums. The tool should expose a product capability rather than raw database or HTTP access. Its result should clearly report success, expected business failures, and the identifiers needed for the next step.

Full answer below

Practice focus

API and capability design applied to model tools without exposing broad internal operations.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Overview
A good tool contract makes one useful capability easy to choose correctly and difficult to misuse accidentally.
I give the tool a specific name, explain what it does and when to use it, and define a narrow input schema with meaningful descriptions and enums. The tool should expose a product capability rather than raw database or HTTP access. Its result should clearly report success, expected business failures, and the identifiers needed for the next step.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
Instead of a generic executeRequest tool, I might expose getOrderStatus with an order reference. I avoid asking the model for tenant IDs or permission flags that the application already knows; those come from trusted session context. For a side effect, I separate preview or confirmation from execution when users need to understand the action.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Exposing a generic arbitrary HTTP or SQL tool.
Using vague descriptions such as “handles orders.”
Asking the model to supply trusted tenant or user identity.
Returning raw stack traces or entire internal objects.

How would you design a tool contract for a model?

Practice focus

Answer path

Overview

Review signals

Follow-up prompts

Continue practice

Next interviewer turn

Tech stacks

Skill areas

Human editorial direction

Was this drill useful?

Found this answer useful?