Server has 9 tools with basic structure. All tools have descriptions (10-60 chars, mostly short) and input schemas. Tool naming follows verb_noun pattern (get_*, submit_*, subscribe_*, unsubscribe_*). However, descriptions are terse and lack context for LLM selection. Parameters lack descriptions in most tools (6 of 9 tools have zero-description params). Output schemas are not documented. Error handling and recovery guidance are absent. No evidence of pagination, result limits, or chaining IDs in responses. Tool annotations present but incomplete coverage.

• Expand descriptions for all get_* tools to 100-200 chars. Include what data is returned, when to call it, and how it differs from related tools. Example: 'Retrieve yueyu's 5 core service lines (consulting, training, research, advisory, implementation). Call this first to understand service offerings before discussing specific needs with a lead.'
• Document output schemas for all tools. For get_company_info, specify: {company_name, founded_year, headquarters, service_count, contact_email}. For submit_lead, specify: {lead_id, status, created_at}. This enables LLMs to chain calls and extract required fields.
• Add descriptions to all parameters. For subscribe_reports.channel, expand to: 'Delivery channel: email (sends to address as email), wechat (sends to address as WeChat ID), webhook (POSTs JSON to address as HTTP endpoint).'
• Define error handling for write tools. For submit_lead, document: 'Returns 400 if name is empty or phone/wechat both missing. Returns 409 if contact already exists (try update_lead instead). Returns 500 on server error (safe to retry).'
• Add tool dependency hints. For submit_lead, note: 'Optional: call get_service_lines first to reference specific services in the lead context. Returns lead_id for use in follow-up tools.'

Inferred effective spec: <=2025-11-25.

• Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained