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 clarity. Input schema present but parameter 'query_payload' has only a generic description ('Input execution payload'). No output schema documented, LLMs cannot infer what fields to expect from the response. Tool name uses verb but is vague ('execute_skill_action' vs 'score_pull_request_risk'). No error handling guidance, no pagination, no structured output specification. The client.py shows the actual capability (PR risk scoring) but is not exposed via MCP tool definition.

• Rename tool to 'score_pull_request_risk' to match the actual capability shown in client.py. This immediately clarifies intent and enables LLM selection.
• Document the output schema explicitly: {risk_assessment_id, overall_risk_score, risk_level, flagged_blast_radius_components, suggested_mitigations, pr_risk_report_markdown_url}. Include field types and descriptions.
• Expand tool description to 150-200 chars: 'Analyze a pull request diff to assess semantic risk and blast radius. Returns risk score (0-1), risk level (LOW/MEDIUM/HIGH_RISK_BREAKING_CHANGE), affected components, and mitigation suggestions. Call this before merging database or schema changes.'
• Replace generic 'query_payload' parameter with explicit fields: pr_diff (string, unified diff format), changed_files_count (integer, 1-1000), modified_database_schemas (boolean). Add format constraints and examples in descriptions.
• Add error handling: return structured errors with actionable guidance. E.g., 'Invalid diff format: expected unified diff. Example: diff --git a/file.py b/file.py\n-old\n+new'. Categorize errors as retryable vs user-fixable.