Loading ToolBench
Enterprise AI assistant platform with job search, resume generation, RAG, and custom model training capabilities
The server defines 5 tools with partial but inconsistent quality. Tool schemas are present and mostly well-formed with appropriate parameter types and descriptions. However, descriptions lack depth and guidance for LLM selection. No output schemas are documented. Error handling is minimal, most tools return bare error strings without recovery guidance. The search_jobs and get_job_market_insights tools have reasonable parameter descriptions but are missing critical constraints (enums for job_type, format guidance for location). The calculator and search tools are stubs with placeholder implementations, reducing their practical utility. No tool annotations (readOnlyHint, idempotentHint) are present. Overall structure is competent but falls short of production-grade tooling, typical of a D/C-range community server.
Evaluates a mathematical expression. Safe evaluation of basic math operations.
Get insights about the job market for a specific role including salary ranges, demand, and required skills. Use this when users ask about job market trends, salary expectations, or career prospects.
Retrieve information from the internal knowledge base
Simulates a web search since we don't have a real search API key configured yet.
Search for job openings and opportunities. Use this when users ask about jobs, careers, hiring, or want to find job listings.
No output schemas documented. Tools return structured data (job listings, market insights) but LLMs cannot plan downstream calls without knowing the response field structure. Pattern requires documenting what fields are returned and their types.
search_jobs and get_job_market_insights lack enum constraints for job_type parameter. Accepts free-form strings like 'full-time' but does not explicitly restrict values. LLMs will hallucinate invalid options.
Error handling returns bare strings with no recovery guidance. Example: 'Error searching jobs: HTTP 400' gives the LLM no actionable next step. Should return structured error with classification (retryable/user-fixable/fatal) and suggested recovery action.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Tool descriptions are too brief and lack 'WHEN to use' context. Example: search description ('Simulates a web search...') does not explain when LLM should choose this over rag_retrieve. Descriptions should be 50-200 chars, explicit about tool selection criteria.
No tool annotations. Tools are marked READ_ONLY in the metadata but schema/descriptions lack readOnlyHint annotations. Modern MCP servers should include idempotentHint for safe-to-retry operations.
search and calculator are placeholder implementations ('Simulated search results...' and no real network calls). These reduce the server's practical value and signal incomplete development.
No pagination guidance in search_jobs description. Tool returns max 5 results hardcoded but does not mention limits or how to fetch additional results. Should document result cap and offer pagination parameters.
get_job_market_insights uses a hardcoded lookup table with only 3 roles. Description claims 'Get insights about the job market for a specific role' but implementation cannot handle arbitrary roles, will return None silently or error. Should either document supported roles or integrate a real data source.