Single-tool server with a well-designed, modern tool definition. The idea_check tool has a clear verb-noun name, comprehensive description with trigger phrases, properly typed parameters with enums and defaults, and structured output. However, output schema documentation is incomplete (no explicit return type schema in the visible code), and there are minor gaps in parameter descriptions. The description length (368 chars) and param annotation quality are solid. No critical naming or structural issues detected.

• Add explicit return type schema to idea_check definition: { 'signal': number, 'meta': {...}, 'evidence': [...], 'similar_projects': [...], 'pivot_hints': [...], 'next_step': {...} } with descriptions for each field so downstream tools and LLMs understand the response structure.
• Expand 'depth' parameter description to include expected latency (e.g. 'quick: ~2-5s, deep: ~15-30s depending on source availability') and decision guidance ('Use quick for interactive loops, deep for thorough validation').
• Add 'lang' parameter description: 'Language code for response text. Supported: en (English), zh (Simplified Chinese). Unsupported codes default to en.'
• Document error scenarios in the tool description or add an error_handling note: 'May fail due to network errors (retryable after 5s), rate limiting (retry with exponential backoff), or source unavailability (returns partial results). If all sources fail, returns high_uncertainty flag.'
• Consider adding a 'confidence_threshold' parameter (default 0.5, range 0.0-1.0) to let agents control signal scoring stringency, and document its effect on the returned signal score.
• Add a structured 'sources_queried' field to the return dict listing which sources were actually searched (github, hn, npm, etc.) so agents know what coverage was achieved.