Loading ToolBench
AI-powered resume analysis and job recommendations from LinkedIn and Naukri with planning-agent loop and HITL approval
The Job Recommender Agent exposes three tools with minimal but present schemas and descriptions. However, multiple critical gaps prevent higher scores: (1) Tool names lack action verbs, 'fetchlinkedin' and 'fetchnaukri' omit the conventional 'get_' or 'fetch_' prefix, and 'run_job_agent' is vague about what it does; (2) Descriptions are present but brief (under 150 chars for two tools) and lack actionable context (no mention of prerequisites, error recovery, or when to use vs. alternatives); (3) Input schemas are minimal, only string and boolean types, no enums, no ranges, no validation hints; (4) Output schemas are completely undocumented, callers cannot see the shape of returned job listings or agent state; (5) Parameter descriptions lack dependency hints and format constraints. The tools function but do not follow production-grade definition patterns from the 54 Agentic Tool Patterns or the 549 production tool baselines.
Fetch LinkedIn jobs by comma-separated search keywords.
Fetch Naukri jobs by comma-separated search keywords.
Run the plan→analyze→(HITL)→fetch→revise agent. For unattended MCP use, auto_approve=True. Pass keywords to override derived search terms.
Tool names do not follow verb_noun convention. 'fetchlinkedin' and 'fetchnaukri' lack a leading verb (e.g., 'search_', 'get_', 'fetch_') and use non-standard camelCase. 'run_job_agent' uses a generic verb. LLMs rely on names to infer intent before reading descriptions.
Output schemas are completely undocumented. fetchlinkedin and fetchnaukri return job listings, but callers cannot see the structure (fields, types, pagination). run_job_agent returns a dict with 8 keys (status, awaiting_approval, summary, etc.), but this is inferred from code, not formally declared. LLMs cannot plan downstream calls without knowing output structure.
Parameter descriptions lack actionable constraints. 'listofkey' (fetchlinkedin, fetchnaukri) accepts a comma-separated string but does not specify format, length limits, allowed characters, or examples of valid input. 'resume_text' lacks length guidance. 'keywords' lacks hint about format or precedence over derived keywords.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 35 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 25 | - | v1 |
No error handling or recovery guidance. Tools do not document error cases (e.g., invalid keywords, API failures, timeout), categorization (retryable vs. fatal), or recovery steps. If a keyword search returns 0 results, should the agent retry with broader keywords, or escalate?
Pagination not addressed. fetchlinkedin and fetchnaukri may return large result sets, but no limit, offset, or next_cursor parameters are documented. Returning thousands of jobs into the LLM context wastes tokens and risks hallucination.
Tool descriptions are generic and do not distinguish when to use each tool. Both fetchlinkedin and fetchnaukri have nearly identical descriptions ('Fetch [Platform] jobs by comma-separated search keywords'). An LLM cannot infer the difference in job coverage, data freshness, or filtering capabilities. Descriptions should explain platform-specific strengths and use cases.