This server has critical definition quality gaps that would prevent confident production use. Both tools have verb-starting names (get_latest_news, get_latest_articles) which is correct, but the schemas contain only input parameters without documented return types. Tool descriptions are present but generic, they lack guidance on when to use each tool vs. the other, what distinguishes them in practical terms, and what the LLM should expect in the response. Parameters have type definitions (integer, string) and default values, but lack constraints (enums for type/lang, min/max for size/max_pages). Most critically, there is no documented output schema, forcing LLMs to guess what fields they receive back. Error handling is minimal, the tools return raw error strings rather than actionable recovery guidance. The descriptions repeat parameter documentation in the docstring rather than explaining intent and use cases.

• Define formal output schemas for both tools. E.g., return a JSON array of article objects: {id: string, title: string, content: string, link: string, created_at: ISO8601}. Document this in the tool description or via a return type annotation.
• Convert 'type' and 'lang' to enum parameters with explicit allowed values: type: enum[push, normal] (or actual BlockBeats API values) and lang: enum[en, cn, cht].
• Add min/max constraints to numeric parameters: size (min=1, max=50, default=5), max_pages (min=1, max=10, default=1). State these in parameter descriptions.
• Rewrite tool descriptions to explain use cases and differentiation: 'Fetch latest blockchain breaking news (rapid-fire updates). Use for real-time market alerts.' vs 'Fetch in-depth blockchain analysis articles (longer reads). Use for technical research and background context.' Include a line like 'Returns up to size*max_pages articles; typical response ~5KB per article.'
• Implement structured error responses with actionable guidance. E.g., if API returns 404: 'BlockBeats API returned 404, check if the service is available or try a different language parameter.' If no results: 'No articles found with current filters. Try reducing max_pages or changing the type filter.'
• Cap result limits and document them. E.g., 'This tool returns a maximum of 50 articles per call (5 articles × 10 pages). For larger result sets, use pagination with page parameters or increase size.'
• Return structured JSON instead of formatted strings. Have the tool return a dict/list that the MCP server serializes, so downstream can reference fields by name.