Server has 5 tools with schemas and descriptions present, but quality is inconsistent. Tool names follow verb_noun pattern (searchProducts, getMyBug, getMyBugs, getBugDetail, markBugResolved) which is good. Descriptions are present but vary in clarity, some are domain-specific Chinese text that may not guide LLM selection optimally. Schemas use Zod with proper types, but parameter descriptions are minimal (10-30 chars), below the 72-char baseline. Critical gap: no output schema documentation, LLMs cannot predict response structure. Error handling is basic (UserError wrapping only). Tool annotations present (readOnlyHint, openWorldHint) but destructiveHint missing on markBugResolved. getMyBugs description mentions 'productId (必需)' but searchProducts returns product names, not IDs, chaining requires manual ID lookup, violating tool-chain pattern.

• Document output schema for each tool. Example: searchProducts returns {products: [{id, name, description}], count: number, keyword: string}. Include field types and meanings.
• Extend getMyBugs to accept productName (string) in addition to productId (number). Internally resolve name→ID. This eliminates the manual lookup step and enables direct chaining from searchProducts.
• Expand parameter descriptions to 50-100 chars with context. E.g., 'keyword: Product name substring to filter results. Leave empty to return all products. Useful for narrowing down when many products exist.'
• Add destructiveHint: true to markBugResolved annotation. Implement optional dry_run parameter or require explicit confirmation comment to prevent accidental state changes.
• Enhance error responses with recovery guidance. E.g., 'Product not found: "XYZ". Try searchProducts() to see available products.' Include error category (retryable, user-fixable, fatal).

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

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry