Single tool 'execute_skill_action' has a minimal description (95 chars) that lacks actionable context. Input schema is present but parameter 'query_payload' has only a generic description ('Input execution payload for this skill'). No output schema is documented, the tool returns a hardcoded JSON string with no structure definition. No error handling guidance, no parameter constraints, and no indication of what the tool actually does beyond vague 'skill operations'. The tool name does not follow verb_noun convention (should be something like 'run_skill' or 'execute_skill'). No evidence of idempotency, side effects, or recovery paths.

• Document the output schema explicitly. Define what fields the response contains (e.g., status, message, result_data, execution_id) with types and descriptions so the LLM knows what to extract.
• Expand the tool description to 100-200 chars explaining: What domain does this skill operate in? What is the expected input format? What does success look like? Example: 'Execute a GenPark AI skill for hybrid search ranking. Input: JSON payload with dense_results and sparse_bm25_results arrays. Returns: fused ranking with reciprocal rank scores.'
• Add constraints to 'query_payload': specify the expected JSON structure (e.g., 'JSON object with keys: dense_results (array of strings), sparse_bm25_results (array of strings), rrf_constant_k (integer, default 60)') or provide an enum of valid payload templates.
• Add error handling guidance: document what errors can occur (invalid payload format, missing required fields, timeout) and what the LLM should do (retry, ask user for clarification, fall back to alternative).
• Rename tool to 'run_skill' or 'invoke_skill' and add a domain-specific suffix if multiple skills exist (e.g., 'run_rerank_skill'). This makes the tool's purpose immediately clear to the LLM.