crawlforge has 8 well-named tools with clear verb-noun patterns (crawl_run, list_crawls, query_urls, etc.). All tools have descriptions (avg ~120 chars, within baseline 34-392 range). Input schemas are present and typed for all tools. However, output schemas are NOT documented, tools return JSON strings without declared field structures, forcing LLMs to parse unstructured text. Parameter descriptions are present but sparse (e.g., 'Path to the DuckDB crawl database' repeated 6 times). Error handling is minimal: query_urls has a basic keyword check but no actionable recovery guidance. No tool annotations (readOnlyHint/destructiveHint). crawl_run is a WRITE operation but lacks confirmation/dry-run pattern. Overall: solid naming and basic schemas, but missing output documentation and error guidance that would elevate this to 70+.

• Document output schemas for all tools. E.g., crawl_run returns {db_path: string, urls_crawled: int, issues_found: int, ...}. list_issues returns [{rule_id, severity, category, message, url, evidence}, ...]. This enables LLMs to plan downstream calls and extract data correctly.
• Add min/max bounds to numeric parameters: max_urls (1-10000), max_depth (1-20), concurrency (1-32), limit (1-500). Include these in parameter descriptions so LLMs understand valid ranges.
• Implement error recovery guidance. E.g., query_urls should return 'Invalid SQL: only SELECT queries allowed. Try: SELECT * FROM urls LIMIT 10' instead of a bare error. list_issues should say 'Database not found at {path}. Call list_crawls() to see available databases.'
• Add tool annotations via FastMCP: mark crawl_run with destructiveHint=true; mark all query/list tools with readOnlyHint=true. This signals to LLMs which tools are safe to retry and which require confirmation.
• Add a dry_run parameter to crawl_run (default false) or implement a separate preview_crawl tool that returns estimated URL count and depth without persisting. This prevents accidental expensive crawls.