Five tools with explicit schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. Tool names follow verb_noun convention (list_, check_, register_, create_, get_) which is good. However, most parameters lack descriptions, e.g., location_id, service_ids, requested_date in check_availability have no descriptions explaining format, constraints, or when they're optional. Output schemas are not documented anywhere; responses are returned as raw JSON text without structure hints. Error handling is minimal, no recovery guidance or actionable error messages. The register_agent tool exposes a critical security concern: the returned api_key is shown only once but the description doesn't warn agents to store it securely or explain the irreversible nature of this operation.

• Add descriptions to all parameters. For check_availability: 'location_id (optional): Location code, e.g. "tukwila" or "monroe". Omit to check all locations.' For requested_date: 'ISO 8601 date string, e.g. "2025-01-15". Must be a future date.'
• Document output schemas in tool descriptions. E.g., 'Returns: {services: [{id, name, base_price, agent_price}, ...]}' or add a 'returns' field to the tool definition.
• Convert locationPreference and agent_id to enums in the schema. E.g., locationPreference: {type: 'string', enum: ['tukwila', 'monroe']}. This prevents hallucinated values.
• Add error recovery guidance. E.g., 'If you receive "Tool requires APC_API_KEY", call register_agent first to obtain a key, then retry.' Include this in tool descriptions or error messages.
• Enhance register_agent description: 'Self-register an API key (shown only once, STORE IT IMMEDIATELY). Returns {api_key, agent_id, created_at}. This key is required for create_lead and get_booking. If lost, re-register with a new agent_id.'