9 tools with complete schemas and Chinese descriptions, but significant quality gaps. All tools are READ_ONLY (good for safety), but descriptions are minimal (10-20 chars), parameter descriptions lack depth, and no output schemas are documented. Tool names follow verb_noun pattern (search_, query_, get_) which is correct. However, descriptions are too terse to guide LLM selection effectively. No error handling guidance, no pagination info for list-like tools, and no chaining IDs documented in responses. Schemas present but sparse, most parameters lack constraints (enums, ranges, formats). This is typical of a domain-specific tool set that prioritizes functionality over LLM usability.

• Expand tool descriptions to 50-200 chars. Example: 'search_reports: Search financial research reports, policy documents, and knowledge snippets by keyword. Returns doc_id, title, date, and snippet. Use doc_type filter to narrow by report type (e.g. "equity_research", "macro_analysis"). Returns up to top_k results sorted by relevance.'
• Document output schemas for all tools. Create a schema reference showing: search_reports returns [{doc_id, title, date, snippet, doc_type}], query_interest_rate returns {rate_type, data: [{date, value}]}, etc.
• Add enums and constraints to parameters. Example: rate_type should list valid values (e.g. 'LPR', 'DR007', 'R007'); frequency should be enum ['daily', 'weekly', 'monthly']; top_k should have range [1, 100].
• Add parameter descriptions for all fields. Example: 'doc_type (optional): Filter by document category. Valid values: equity_research, macro_analysis, policy_brief, market_report. Omit to search all types.'
• Include error recovery hints in descriptions. Example: 'If rate_type is invalid, call query_interest_rate with no arguments to list available rate types. If date range is invalid, use YYYY-MM-DD format and ensure start_date <= end_date.'