A workflow automation platform implements an MCP server that exposes tools to Claude for managing production infrastructure. The MCP tool schema for restart_service is: {"name": "restart_service", "description": "Restarts a production service", "inputSchema": {"service_name": {"type": "string"}}}. During an incident response, an operator prompts Claude to 'restart the payment service.' Claude calls restart_service({"service_name": "payment-service"}) correctly. Later, a different operator asks Claude to 'fix the slow database.' Claude calls restart_service({"service_name": "database"}) — a dangerous action that causes a production outage. What MCP schema design would have constrained Claude's tool use to safer choices?

Schema-level constraints are the most reliable safety control in MCP tool design. By restricting service_name to an enum of valid values — ["payment-service", "auth-service", "notification-service"] — the database is structurally excluded from the tool's possible inputs. Claude cannot call the tool with 'database' because the schema will reject it during tool use generation. This implements capability minimization at the schema level. Option A (confirmation boolean) can be gamed — Claude may set it to true based on its interpretation of the request, not based on human confirmation. Option C (warning in description) is the described failure mode: Claude interpreted 'fix the slow database' as a restart problem and ignored or overrode the warning. Description-based constraints are advisory, not enforced. Option D (two-step) adds friction but doesn't prevent the wrong service from being specified in validate_restart — Claude would still name 'database' in the validation call.