Loading ToolBench
Manage the user's private job-application tracker with SQLite database backend
14 tools with complete schemas and descriptions. Naming follows verb_noun pattern consistently (create_, list_, get_, update_, search_, schedule_, complete_). Descriptions are clear and action-oriented (avg ~100 chars, within 50-200 baseline). All parameters have types and descriptions. Tool annotations present for read/write hints. Key gaps: no pagination support on list tools (list_applications, list_interviews, list_follow_ups return unbounded results), no error recovery guidance in descriptions, and no confirmation pattern for destructive operations (update_application_status, complete_follow_up). Output schemas not explicitly documented in source.
Mark a follow-up reminder as completed. Use this tool when the user has completed a follow-up action.
Create and permanently store a new job application. Use this tool when the user wants to record a job application.
Create a follow-up reminder for a job application. Use this tool when the user wants to schedule a follow-up action.
Retrieve one job application by its application ID. Use this tool when the user wants details about a specific application.
Get a summary dashboard of job application statistics. Use this tool when the user wants an overview of their job search progress.
Retrieve details of a follow-up reminder. Use this tool when the user wants to view follow-up information.
Retrieve details of a scheduled interview. Use this tool when the user wants to view interview information.
List tools (list_applications, list_interviews, list_follow_ups) lack pagination parameters (limit, offset, page_size). Unbounded results risk context window exhaustion and violate pattern:paginated-result baseline.
Destructive/state-changing tools (update_application_status, update_interview_status, complete_follow_up) lack confirmation or dry-run patterns. Agents may inadvertently change status without user approval.
Error responses in code (e.g., validation_errors in create_application) return raw error lists without recovery guidance. Per pattern:recovery-guide, errors should suggest next steps (e.g., 'Try search_applications() first').
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2025-06-18+ | v2 |
List all job applications stored in the database. Use this tool when the user wants to view their applications.
List all follow-ups for a specific application. Use this tool when the user wants to view all follow-ups for an application.
List all interviews for a specific application. Use this tool when the user wants to view all interviews for an application.
Schedule an interview for a job application. Use this tool when the user wants to record an upcoming interview.
Search for job applications by company name or job title. Use this tool to find applications when the user provides a company or role instead of an application ID.
Update the status of a job application. Use this tool when the user wants to change the workflow status of an application.
Update the status of a scheduled interview. Use this tool when the user wants to mark an interview as completed or cancelled.
Output schemas not documented in tool descriptions. LLMs cannot infer response structure (e.g., what fields does get_application return?). Per pattern:tool, all tools must document return types.
Tool descriptions lack dependency hints. E.g., update_application_status should note 'Call get_application first to verify current status and allowed transitions.' This prevents invalid state transitions.