FindIt provides two well-structured tools with complete input schemas and reasonable descriptions. Both tools follow verb_noun naming convention (findIt_google, findIt_scrap) and include comprehensive parameter documentation. However, the server has several issues that prevent a higher score: (1) tool names use camelCase with domain prefix ('findIt_') rather than pure verb_noun format, which is unconventional; (2) output schemas are documented in code but responses are returned as untyped 'dict | str' which undermines type safety for downstream tools; (3) error handling returns plain strings rather than structured error objects that could guide agent recovery; (4) no input validation with actionable error messages; (5) parameter descriptions lack some specificity around constraints and expected formats.

• Rename tools to pure action verbs: 'search_google' and 'extract_content' (or 'scrape_webpage'). Remove 'findIt_' prefix, it's redundant with the server name and violates verb_noun convention.
• Define and return a typed response schema. For findIt_google: {"query": str, "results": [{"title": str, "link": str, "snippet": str, "domain": str, "raw_content"?: str}], "total_results": int, "estimated_total_results"?: str}. For findIt_scrap: {"urls_processed": int, "content": [{"url": str, "text": str, "images"?: [str]}]}. Return union type only for valid response, errors should be separate.
• Implement structured error responses: {"error": true, "code": "<error_code>", "message": "<human-readable>", "recovery": "<suggested next step>"}. For example: {"error": true, "code": "invalid_time_range", "message": "Invalid time_range: got 'invalid', must be one of: day, week, month, year", "recovery": "Try again with a valid time_range or omit the parameter to disable time filtering."}
• Add input validation with early returns. Before calling APIs, validate that time_range is in [day, week, month, year], max_results is 1-10, and URLs are properly formatted. Return actionable errors on validation failure.
• Clarify parameter descriptions: 'search_depth': 'basic (default, fast) makes 1 API request; advanced makes multiple requests for comprehensive coverage, ~2x slower. Recommended for exhaustive searches.' Similarly for extract_depth.
• Document the 3-result limit for include_raw_content in the parameter description: 'Include cleaned text content from URLs. Limited to first 3 results to avoid timeouts (each extraction may take 5-10 seconds).'

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

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