Scoring was not performed

• Rename the tool to follow verb_noun conventions with a clear action: 'evaluate_tool_calls', 'assess_tool_behavior', or 'grade_tool_execution' to signal what the LLM should expect.
• Expand the description to 100 - 200 characters covering: (1) what judgment criteria are supported, (2) what the return value represents (score, pass/fail, grades), (3) when to call this vs manual testing, and (4) what model versions are available.
• Add parameter descriptions for each field: (a) 'tools' → 'Optional array of tool names to filter evaluation scope. If omitted, evaluates all provided tool calls.'; (b) 'criteria' → 'Evaluation criteria as a string. Common examples: correctness, efficiency, safety. Free-text or list supported criteria clearly.'; (c) 'rubric' → 'Optional detailed scoring guidelines. If provided, the judge uses this to override default assessment rules.'; (d) 'model' → 'LLM model for judging (e.g., claude-opus, gpt-4). If omitted, uses server default.'; (e) 'min_score' → 'Numeric score threshold (0 - 100 scale). Returns failure if result falls below this.'
• Document the output schema explicitly in the tool definition or inline comments. Example: '{"score": <number 0-100>, "passed": <boolean>, "feedback": <string>, "criteria_breakdown": {<key: score>}}'
• Add error handling patterns: (a) if LLM judgment fails, return actionable error like 'Judge call failed: rate limit exceeded. Retry after 60 seconds.' (b) if criteria are invalid, return 'Invalid criteria: got "xyz". Supported: correctness, efficiency, safety.' (c) if tool names don't match, return suggestions like 'Tool "send_email_v2" not found in context. Available: send_email, create_draft.'