Single tool with reasonable structure but significant gaps. The query_route tool has a clear name starting with a verb (query_), explicit input schema with type definitions and parameter descriptions, and proper tool annotations (readOnlyHint, openWorldHint). However, the tool description lacks depth, it states WHAT the tool does but not WHEN to use it, WHY, or what the expected output structure is. Output schema is not documented (returns dict without field specification). Parameter descriptions are minimal (2 - 8 words each, below the 72-char baseline). No error handling guidance for LLMs (what if appKey is invalid? what if the tracking number doesn't exist?). Security concern: appKey and appSecret are exposed as tool parameters, violating secret-injection pattern despite being credentials for a third-party API.

• Remove appKey and appSecret from tool parameters. Inject them server-side via environment variables (SF_APP_KEY, SF_APP_SECRET) or a configuration object. Update tool signature to accept only sfCode, phone, and requestUrl (or move requestUrl to config too).
• Expand tool description to 80 - 150 characters. Example: 'Query SF (顺丰) logistics status by tracking number and recipient phone. Returns tracking events, current location, and delivery status. Use when user provides an SF tracking code to check delivery progress.'
• Document each parameter with format hints and constraints. Example for appSecret: 'SF app secret (obtain from 云枢 platform dashboard; 32-character alphanumeric)'. Example for sfCode: 'SF tracking number (e.g., SF0267637989800; required)'. Example for phone: 'Recipient phone last 4 digits (e.g., 0851; required for verification)'.
• Document return schema explicitly in main.py docstring or a separate schema definition. Example: 'Returns dict with fields: tracking_events (list of {timestamp, location, status}), current_status (string: in_transit|delivered|exception), delivery_date (ISO date or null), error (string or null if failed). Typical response: {"tracking_events": [{"time": "2024-01-15T10:30Z", "location": "Beijing", "status": "in_transit"}], "current_status": "in_transit", "delivery_date": null, "error": null}'.
• Add error handling and recovery hints. Document what LLMs should do on common failures: 'If error is "Invalid phone number", ask user to provide the recipient's correct phone number or try without phone verification. If error is "Tracking not found", confirm the SF code is correct and ask user to check the receipt. If error is "API rate limit exceeded", retry after 60 seconds.'