Single tool 'execute_skill_action' has a generic, vague description (97 chars) that fails to explain WHAT the tool does, WHEN to use it, or what it returns. Parameter 'query_payload' is a free-form string with minimal guidance, no format, constraints, or examples. No output schema is documented. The tool name uses 'execute' (generic verb) + 'skill_action' (vague noun), violating verb_noun clarity. No error handling, no recovery guidance, no structured output specification. Tool definition is visible in code but lacks rigor expected of production tools.

• Rename tool to a specific verb_noun pair. Examples: 'match_firmographic_icp', 'evaluate_account_fit', 'score_lead_qualification'. This makes the tool's purpose clear from the name alone.
• Expand tool description to 100-200 chars explaining: (1) What it does: 'Evaluates B2B accounts against Ideal Customer Profile (ICP) criteria and returns qualification tier (Tier 1/2/3 or Disqualified).' (2) When to use it: 'Call this after retrieving account data to determine sales priority.' (3) What it returns: 'Structured result with tier, ICP fit score, and disqualification reasons.'
• Document the 'query_payload' parameter format. Specify: Is it JSON? Plain text? What fields does it expect? Example: 'JSON object with keys: name (string), country (string, ISO 3166-1 alpha-2), industry (string), headcount (integer), arr_usd (integer), technologies (array of strings).'
• Add explicit output schema to tool definition. Document the response structure: { status: string, tier: string, icp_fit_score: integer, is_qualified: boolean, disqualifications: array, scoring_notes: array }. Include field descriptions.
• Implement error handling with actionable messages. Return structured errors: { error: 'Invalid payload format', details: 'Missing required field: country', suggestion: 'Provide country as ISO 3166-1 alpha-2 code (e.g., US, CA, UK)' }. Classify errors as retryable vs. user-fixable.