Loading ToolBench
Automatically track job applications from Gmail to Notion using AI-powered email parsing with multiple MCP servers for Gmail, Notion, and weekly reporting
JobSyncd presents a collection of 14 tools across multiple servers (Gmail, Notion, Weekly Report). While tool names generally follow verb_noun conventions and basic schemas are present, the implementation suffers from critical gaps: many parameters lack descriptions, output schemas are not documented, error handling is minimal and non-actionable, and descriptions are often generic. The codebase shows tool registration with inputSchema, but parameter descriptions are sparse or missing entirely. For example, 'update_job_application' accepts an 'updates' object parameter with no type constraints or field documentation. Return types are not specified anywhere in the source. The implementation appears functional but does not meet production quality standards for agentic tool design.
Create a new job application entry in Notion
Create a weekly report entry in Notion
Create weekly report entry
Find application by ID to check for duplicates
Format deadlines for LLM processing
Format application entries for LLM processing
Get all recent job application entries for duplicate detection
Missing or underdocumented output schemas: No tool explicitly documents what it returns. LLMs cannot know which fields to expect in responses, making chaining and data extraction error-prone.
Vague or missing parameter descriptions: 'updates' in update_job_application has no description of what fields it accepts. Parameters like 'entry_id', 'email_id', and 'app_id' lack guidance on format or source.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 9 | - | v1 |
Get full content of a specific email
Fetch recent emails from Gmail
Fetch weekly application data from Notion database
Mark an email as processed
Search for similar job application entries in the database
Update an existing job application entry
Update an existing job application
Untyped or loosely-typed parameters: 'updates' in update_job_application is an object with no schema constraints. 'entries' and 'deadlines' in formatting tools are arrays with minimal item schema definition.
Duplicate tool 'create_weekly_report' defined in both notion_server.py and weekly_report_server.py with identical signatures. LLMs will be confused when selecting between them.
Minimal error handling and no recovery guidance: Error returns from gmail_server.py include only generic messages like 'Error fetching emails: {str(e)}'. No indication of what the LLM should try next (retry, lookup, ask user).
Returned TextContent is generic status text, not structured data: 'Marked email {email_id} as processed' and 'Fetched {len(emails)} emails' provide no actionable information about what was retrieved. Agents cannot extract email objects or IDs for downstream use.
No idempotency guidance: Tools like 'mark_email_processed' and 'create_job_application' do not document whether repeated calls are safe. Agents may retry on timeout, risking duplicate records.
Parameter naming inconsistencies: ID parameters use 'email_id', 'app_id', and 'entry_id' interchangeably. Tools that reference the same resource should use consistent parameter names to reduce agent confusion.
No pagination or result limits documented: 'get_recent_emails' and 'get_all_recent_entries' accept numeric parameters but do not specify min/max bounds or warn about large result sets exceeding context windows.