The `parameters` block is the piece teams mistake for a guard. In the sample declaration it types `city` as a string, marks it required, and leaves `maxNightlyPriceUsd` as an optional number [4]. It says nothing about whether the city string is between 2 and 120 characters after trimming, or whether the price is positive and at most 10,000; in the post those bounds live in a Zod schema applied on arrival [5]. Raju Dandigam's reason for the split is the right one: model-generated arguments cross the same trust boundary as an HTTP request [6], and the declaration exists to help the model produce better arguments rather than to validate them on your side of the wire [7].
After shape, the questions change character. The returned object is a name and structured arguments [3], carrying no user identity and no evidence that the same call already succeeded. Authorization has to come from your context: in the sample it is a set membership test that throws unless the execution context's permissions contain `hotel:read` [10]. Policy answers what a permission set cannot, which is whether this operation should happen in this workflow at this moment [9]. Same well-formed call, same authorized user, different answer depending on which agent is running.
The tool registry is the part I would copy. Each entry carries a risk tag of read, write or irreversible alongside a timeout, a parser and an executor [13], which puts the blast radius of a tool in the same object as its code. The sample values are a 3,000 ms timeout for `search_hotels` and 8,000 ms for `book_hotel` [14], roughly 2.7 times the budget for the call you cannot take back [15]. Those two numbers are claims about someone else's inventory and booking providers. They transfer if your booking API's tail latency sits inside eight seconds and your read path is an index or a cache; otherwise keep the tag and re-measure the milliseconds.
"The model proposes. The runtime disposes," as Dandigam puts it [20]. The disposal step is where the code gets tedious, and the post's `executeOnce` is cut off in the text I was given, which is a shame, because where the dedupe key is stored is the whole question. A process-local map does not survive the worker-restart case the post itself names [17].
In my context, write tools sitting behind a payments provider, I would build that store before the policy layer, because a duplicated charge costs more than an over-permissive read. If every tool you expose is a read, invert the order and spend the week on argument validation instead.
