13 tools with complete JSON schemas and descriptions, but quality is uneven. Naming is verb-forward and mostly clear (suggest_*, add_*, find_*, scan_*, extract_*, import_*, get_*, query_*, export_*, record_*). Descriptions range 50 - 180 chars, meeting the 10 - 1024 baseline but lacking LLM-optimized detail on WHEN to use each tool and dependencies between them. Parameter descriptions are sparse or absent, most params lack guidance on format, constraints, or valid ranges. No output schemas documented. Error handling is minimal; no recovery guidance visible. Security: userId is passed as a parameter in every tool, which is acceptable for a user-scoped service, but no evidence of permission gates, audit logging, or secret injection patterns. Composition is reasonable, tools chain logically (discover → watchlist → scan → extract → import), but missing batch operations and pagination guidance.

• Document output schemas for all tools. Specify field names, types, and whether results are paginated. Include example responses showing the structure LLMs will receive.
• Add parameter descriptions for every input. For each param, state: expected format (e.g., 'ISO 8601 date', 'comma-separated list'), constraints (min/max, enum values), and examples of valid input.
• Add WHEN-to-use guidance to tool descriptions. E.g., 'Call find_company_career_page first to locate the URL, then pass it to scan_company_career_page.' This prevents wasted calls and guides multi-step planning.
• Implement error handling with recovery paths. Return structured errors (not stack traces) that tell the LLM what to do next: 'Company not found. Try suggest_relevant_companies() to discover similar companies.'
• Add pagination support and result limits. Document max result counts (e.g., 'Returns up to 50 companies') and provide offset/limit or cursor parameters for large datasets.