Switchboard demonstrates solid fundamentals: all 4 tools have clear verb-noun names (list_, get_, set_, deploy), explicit JSON schemas with required fields and descriptions, and thoughtful error handling with recovery guidance. Descriptions are concise (20-80 chars) and state what each tool does. However, parameter descriptions lack detail on constraints (e.g., 'service' and 'flag' accept any string with no validation hints), output schemas are not formally documented, and approval-gated tools lack explicit dry-run or confirmation patterns in the schema itself. The code shows strong intent (NeedsInput pattern, approval gates, literal action display) but the tool definitions alone do not fully capture these safeguards.

• Add validation constraints to parameter descriptions: 'service: Service name (alphanumeric, 1-64 chars). Call list_services to see valid options.' This guides LLMs and prevents invalid calls.
• Document output schemas explicitly in tool definitions or in a separate schema registry. For list_services, declare: returns {services: [{name, version, flags: {[key]: boolean}}]}.
• Add tool annotations to ToolDefinition: readOnlyHint=true for list_services and get_flag; destructiveHint=true for set_flag and deploy. This enables LLM safety reasoning.
• Enhance set_flag and deploy descriptions to mention approval requirement: 'Requires human approval via NeedsInput. First call returns a token; retry with approval answer to proceed.'
• Add error guidance to descriptions: 'If service or flag not found, call list_services to verify names. Returns NotFound with suggestions for available options.'