Single tool with minimal definition quality. lookup_clause_review_hints has a basic description (47 chars) and a simple input schema with one string parameter. The parameter lacks a description entirely, violating the requirement that every parameter must explain what it controls. Output schema is not documented in the source code. No error handling guidance, no examples of what 'clause_type' values are valid, and no indication of what the response structure contains beyond the implementation detail visible in format_clause_review_hints_response(). The tool name is clear (verb_noun pattern), but the overall definition falls short of production standards.

• Add a description to the 'clause_type' parameter: 'The type of contract clause to look up (e.g., Non-Compete, Change of Control, Confidentiality). Must match a known clause type in the catalog.'
• Document the output schema in the tool description or as a structured response type: 'Returns {found: bool, clause_type: str, risk_lens: str, common_unknowns: [str], question_categories: [str], review_hints: [str]}'
• Expand the tool description to 100-150 chars: 'Look up clause review hints by clause type. Returns risk assessment lens, common unknowns, question categories, and specific review hints for the given clause type. Returns found=false if the clause type is not in the catalog.'
• Add an enum constraint or list of valid clause_type values in the parameter description or as a separate discovery tool (e.g., list_clause_types).
• Document error behavior: 'If clause_type is not found, returns found=false with empty arrays. Consider calling list_clause_types() first to discover available clause types.'

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

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