Single tool 'execute_skill_action' has a minimal description (89 chars, below 194-char baseline) that lacks WHEN to use it, prerequisites, or state-modification warnings. Input schema present but parameter 'query_payload' has only a generic description ('Input execution payload') with no format, length, or content constraints. No output schema documented, LLMs cannot predict response structure or chain to downstream tools. No error handling guidance. Tool name uses verb but is vague ('execute_skill_action' vs 'process_transaction', 'verify_payment', etc.). No parameter validation rules, no examples of valid payloads, no recovery guidance on failure.

• Document the output schema explicitly. Declare that the response is {status: 'SUCCESS'|'FAILURE'|'PENDING', message: string, transaction_id?: string, ...}. This lets LLMs know what fields to expect and chain to downstream tools.
• Expand parameter 'query_payload' description to specify format: 'A JSON string containing transaction details. Required fields: [list them]. Example structure: {"step": "AGE_VERIFICATION", "user_id": "...", ...}. Max length: 10KB.'
• Rewrite tool description to 150 - 250 chars covering: what it does (executes GenPark commerce steps), when to use it (after cart lock, before payment), what it modifies (transaction state), and what it returns (status + transaction ID). Example: 'Execute a single step in the GenPark checkout funnel (age verification, shipping selection, tax calculation, payment authorization). Returns transaction status and ID for audit trails.'
• Add error handling guidance: 'On failure, the response includes an error_code (INVALID_PAYLOAD, TIMEOUT, PERMISSION_DENIED, etc.) and a recovery hint. Retry transient errors; ask the user to fix validation errors.'
• Consider splitting into domain-specific tools: 'verify_age_requirement', 'select_shipping_address', 'calculate_tax', 'authorize_payment'. Each would have a clear name, focused description, and specific input/output schemas.