Loading ToolBench
MCP server for job search, CV analysis, and career coaching with MongoDB integration
This MCP server has moderate structural problems. Tool names are action-verb compliant (analyze-, search-, save-, get-), but several tools lack proper parameter descriptions and schema completeness. Of 7 tools, most have descriptions, but parameter documentation is inconsistent, some parameters lack explicit descriptions or type hints in observable code. The MongoDB tools (save-pdf-to-mongo, save-session-data) accept base64 and object parameters but lack clear guidance on schema structure. Error handling is minimal: tools return plain text or throw without recovery guidance. The codebase shows Zod schema definitions for some tools (analyze-cv-for-skill, search-jobs) but others (get-pdf-from-mongo, get-session-data) are defined via TypeScript interfaces without visible validation. Output schemas are not documented, callers must infer structure from tool names and source code. Tool composition is reasonable (single responsibility), but tool chaining lacks explicit ID contracts (e.g., does search-jobs return job IDs that other tools accept?). Overall, definitions are present but under-specified for LLM-driven discovery and error recovery.
Analyze the CV for a user in order to return a profession
Retrieve all sessions for a user from MongoDB
Retrieve a PDF from MongoDB by ID and return it as base64
Retrieve session data including Q&A entries from MongoDB
Save an uploaded PDF file to MongoDB
Save or update session data with Q&A entries to MongoDB
Output schemas completely undocumented. Tools return generic ToolResponse interface with only {type: string; text: string}[]. LLMs cannot plan downstream calls or extract structured data. E.g., search-jobs returns plain text JSON; analyze-cv-for-skill returns a profession string. No typed response contracts.
Parameter descriptions missing or trivial for MongoDB operations. save-session-data accepts 'q_and_a' (object type) and 'path' (string) with minimal guidance on expected structure. get-session-data, get-all-user-sessions return no documentation of response structure. LLMs cannot predict or validate field contents.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 33 | - | v1 |
Search for jobs based on user preferences
Error handling non-existent or unguided. analyze-cv-for-skill catches PDF parse failures with 'CV not readable' plain text; search-jobs throws raw Error('ADZUNA_APP_ID or ADZUNA_APP_KEY not set') without recovery guidance. No error classification (retryable vs. fatal), no actionable next steps for LLM.
Tool composition fragmented: MongoDB tools (save-pdf-to-mongo, get-pdf-from-mongo, save-session-data, get-session-data) accept 'id' and 'session' parameters, but no tool returns these IDs for chaining. LLM must already possess user IDs and session numbers, or multi-step discovery fails.
Parameter type ambiguity in MongoDB tools. save-session-data's 'q_and_a' is declared as object with description 'Question and answer entries array', is it an array of objects, or a single object? No schema clarification. get-session-data and get-all-user-sessions lack return type documentation entirely (inferred from TypeScript interfaces not visible in tool definitions).
search-jobs openWorldHint=true but no pagination parameters (page, limit, offset). Adzuna API returns results_per_page=10 hardcoded. Large result sets not trimmed or paginated, risking context overflow.
Tool descriptions overly brief. 'Analyze the CV for a user in order to return a profession' (10 words, ~60 chars) lacks context on expected input format (base64 PDF), output structure (profession name only), or when to use it vs. alternatives. Minimum recommendation: 50-200 chars per arcade baseline.