Tools + MCP

Anthropic provides

Tool use is a defined loop, not magic. You pass a set of tools, each with a name, a description, and an input schema. On a turn, Claude may stop with a tool_use block naming a tool and its arguments. Something executes it. A tool_result comes back — success or is_error — and the loop continues until Claude answers.

Where the tool runs is the whole governance question. Client tools run in your application — you receive the tool_use block and execute it. Server tools run on Anthropic's infrastructure and return results directly. Which side holds the code is which side must be trusted.

Two knobs steer the loop: the tools list itself (an agent can only call a tool that was passed to it) and tool_choice (auto, or forced). And the description on every tool is read by the model on each call — the channel Anthropic documents for standing consent.

Skoor adds

A tools list answers what the agent can do. Your clients and examiners ask what it may never do. Skoor attaches to the exact mechanics above — nothing new invented, each control landing on a primitive the loop already has.

The tools list is an allowlist, so scope is enforced by construction: an unlisted tool is not refused, it is unreachable. The description channel that carries standing consent carries standing refusals in the same breath — where a skoored agent's never-do list actually lives, read on every call. The tool_result round trip is the natural place the audit record forms: one entry per call, journaled to a store you control. And the client-vs-server split is the custody line — a tool holding your credentials should run on your side, never a third party's.

The connector registry carries the published scope per connector for the whole Claude ecosystem, and a permissions list without its refusals is treated as half a record. Our own MCP connector is the proof by example: it runs under the rules it serves — local, read-only, no network, no credentials.