When Language Becomes Machinery: Tools, Permissions, and Verification

The system-prompt captures in asgeirtj/system_prompts_leaks become most operational when they describe tools. This chapter follows the control loop behind those descriptions, from a user’s intent to tool routing, permission, execution, result handling, and the report that returns to the user, so readers can see where prompt instructions guide action and where the host runtime must enforce the boundary.

A tool list looks deceptively simple. It might name a shell, a file editor, web search, a calendar connector, or a memory operation. But a useful agent needs more than access. It needs a rule for deciding when the capability fits, a way to pass structured input, a boundary around authorization and data, and a way to interpret what comes back. Without those parts, a tool is an exposed possibility rather than a reliable product behavior.

A tool has a trigger, not just a name

The captured prompts treat tools as part of a routing architecture. Claude Code presents an agent with file operations, shell execution, delegation, scheduled work, web access, and connected services. Codex describes workspace and connector tools alongside permissions, skills, plugins, and automation. Claude’s general prompt includes rules for connected Model Context Protocol services, past-conversation search, memory operations, web search, and visual output. Gemini specifies search, image retrieval, image generation, file generation, and web-code capabilities. These inventories matter, but their routing rules matter more.

A trigger answers a practical question: what feature of the user’s request makes this tool appropriate? A request to edit a file can trigger an edit operation, while a request to explain an error may need only prose. A question about a current event can trigger web search, while a stable definition may not. A request involving a named connector can justify calling that connector directly, while a vague request for an external service may require presenting a choice first. The prompt turns a broad tool surface into conditional behavior.

This is why tool schemas belong next to policy. A schema defines the shape of an invocation, but the prompt can define the decision that precedes it. The assistant may need to select the right tool, fill the required fields from the user’s request, avoid unsupported combinations, and decide whether to ask for missing information. The tool server then receives a structured action rather than a loose paragraph. The more consequential the tool, the more important the routing logic becomes.

Connector opt-in is a useful example. The Claude capture distinguishes connected services that are already available from third-party services that require a person’s choice. It directs the assistant to search a connector directory for a named service, suggest an available option, and avoid choosing a partner on the person’s behalf when the request does not name one. This rule protects user choice while still allowing the assistant to be proactive. It is a product decision expressed as a sequence of tool calls.

The same pattern appears in visual output.