Tool whitelist & destructive actions

Pitchbar exposes tools to the LLM only when the workspace admin has explicitly enabled them for that agent. Discovery never auto-enables; a new tool is always disabled until acknowledged.

Why per-tool whitelist

• A visitor-facing chatbot must NEVER inherit a write-permission tool by accident.
• The same MCP server may expose tools that are safe (search) and unsafe (delete). The admin should be able to enable one without the other.
• Different agents may need different subsets — the marketing-site bot doesn't need the same write access as the internal support bot.

Destructive tools

MCP defines an optional annotation flag destructiveHint. Pitchbar mirrors that into a "Destructive" badge on the tool row. Enabling a destructive tool requires a confirmation modal that shows the input schema so the admin can inspect exactly what arguments the LLM will pass.

Schema drift behaviour

When a refresh discovers that an existing tool's input_schema has changed since the last sync, every active grant for that tool is automatically flipped to disabled. The admin must re-approve the tool with the new schema visible. Rationale: the LLM cannot guess the new parameter shape, and a parameter that has grown wider may carry new security implications.

Tombstoned tools

When a server stops reporting a tool, Pitchbar marks the row tombstoned (removed_at is set) rather than deleting it. Existing audit-log references survive; tombstoned tools never reach the LLM payload again until they reappear in a refresh.