Loading ToolBench
MCP server that fetches job listings from LinkedIn and Naukri based on search queries, integrated with resume analysis and AI-powered job recommendations
This server has critical definition quality issues that prevent it from being production-ready. Both tools lack proper parameter descriptions (only field name 'listofkey' with a generic string description), the parameter naming is non-standard and ambiguous, there are no output schemas documented, and error handling is completely absent. The tool names are acceptable but do not follow strong verb-noun conventions. Input schemas exist but are minimally descriptive. No parameter validation, enum constraints, or error guidance is present. The codebase shows async tool definitions with FastMCP but the underlying implementation (src/jobs_api.py) reveals external API calls (Apify) with no error handling, timeout management, or recovery guidance. These are read-only tools but still require better documentation and error classification.
Fetches LinkedIn job listings based on a list of keywords
Fetches Naukri job listings based on a list of keywords
Parameter 'listofkey' is non-standard, ambiguous naming. Should be 'search_keywords' or 'job_titles' with type suffix. LLMs cannot infer whether this accepts a comma-separated string, JSON array, or single keyword.
Parameter description 'Search query for LinkedIn jobs' is generic and does not specify format constraints (single keyword vs comma-separated vs array), character limits, or special character handling. Description is 34 characters, below the 50-200 char optimal range for LLM instructions.
No output schema documented. The src/jobs_api.py implementation returns lists from Apify datasets with unpredictable field names (Job Title vs jobTitle vs positionName, Company Name vs company). LLMs cannot know what fields to extract or how to chain these results to downstream tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 35 | 2026-07-28+ | v2 |
No error handling or recovery guidance. The Apify API calls in src/jobs_api.py (lines with apify_client.actor().call()) can timeout, return empty datasets, or fail with API key issues. No try-catch, no timeout parameters set, no error classification (retryable vs fatal), no guidance to the LLM on what to do if the call fails.
No pagination parameters documented or implemented in tool definitions. src/jobs_api.py accepts 'row' parameter for limiting results, but the tool signatures do not expose this. If results exceed 50 items, they could blow the context window. No limit enforcement, no 'next_cursor' or 'total_count' in documented output.
Tool descriptions are too short (36-38 characters) and lack WHEN/WHY guidance. 'Fetches LinkedIn job listings based on a list of keywords' does not explain when to call this vs the Naukri tool, what format 'keywords' expects, or what results to expect. Descriptions should be 50-200 characters with actionable context.
Inconsistent field naming in underlying API responses (app.py shows fallback chains like job.get('Job Title') or job.get('title') or job.get('jobTitle')). This signals that the output schema is undocumented and unpredictable. LLMs cannot plan downstream operations without knowing which fields are guaranteed to be present.
No input validation or constraint documentation. Parameter 'listofkey' accepts any string. No regex pattern, length limit, character restrictions, or enum values documented. Undocumented constraints invite LLM-generated invalid input.
API credentials (APIFY_API_KEY, GROQ_API_KEY) are loaded via environment variables in src/helper.py and src/jobs_api.py, which is correct. However, no audit logging is present in the tool implementations. No logging of who called the tools, with which parameters, or what results were returned. This violates audit-trail requirements.