Loading ToolBench
A single-user job tracker MCP server. AI Jobs Found contains New, Snoozed, and Deleted review lists. Allows listing jobs, adding researched roles, and updating job details or status.
Three tools with reasonable naming and descriptions, but significant gaps in parameter documentation and output schema clarity. Tool names follow verb_noun convention (list_jobs, add_job_found, update_job). Descriptions are present (avg 150-200 chars) and explain WHEN to use each tool. However, parameter descriptions are largely absent, most input fields lack explanations of their purpose, constraints, or format. Output schemas are not documented. Error handling is minimal. The server uses HTTP transport with Supabase backend, but MCP protocol integration details are unclear from the provided code snippet.
Add one researched role to the New AI jobs feed. First list all jobs, including Deleted, and provide the canonical posting URL whenever available.
List New AI jobs, Snoozed AI jobs, Deleted AI jobs, To Apply, Applied, Rejected, or every job. Use all before adding jobs so deleted roles are also deduplicated. Applied includes applied, interviewing, offered, and accepted.
Update job fields or move it between lists with status. Use jobs_found, jobs_snoozed, or jobs_deleted for AI review lists; to_apply moves it to Applications. Added Date cannot be changed.
Parameter descriptions missing or minimal. Input schemas define types and enums but lack descriptions explaining what each field controls, valid ranges, or format constraints. E.g., 'posted_date' has format:date but no description of expected format or timezone handling.
Output schemas not documented. No specification of what list_jobs, add_job_found, or update_job return. LLMs cannot plan downstream calls or extract required fields (e.g., job IDs for chaining) without documented response structures.
Error handling lacks recovery guidance. No indication of what errors are retryable, user-fixable, or fatal. No examples of error messages or how LLMs should respond to validation failures (e.g., invalid UUID, duplicate job).
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2025-06-18+ | v2 |
update_job description mentions 'Added Date cannot be changed' but does not explain what happens if an LLM attempts to change it. Should clarify: is it silently ignored, or does the tool return an error?
No pagination or result limits documented for list_jobs. If the 'all' enum returns hundreds of jobs, context window could be exhausted. Should specify max results and offer pagination (limit, offset, or cursor).