@projectpac/tool-google-calendar

Two tools a run may call, over the principal's own calendar. The smallest honest tool adapter.

It is the operator's own capability, so it is configured beside the executors rather than installed as an extension a peer could distribute -- which is also why the token is read from a file this process can see. What a flow still decides is which of these names a run may use; what the operator decides is that this adapter exists at all.

• The token never reaches the model. It goes into an authorization header and nowhere else -- never into a tool result, never into a prompt.
• An answer says no more than was asked. A run asked when the principal is busy, so it is told when, and not what they are doing.
• The two tools are declared differently on purpose. Reading free/busy is a question; holding a slot changes the principal's calendar and cannot be undone from here, so it says hasOutsideEffects and the loop can gate it as the action it is. An adapter that lied about that would be deciding on the policy's behalf.