The server demonstrates solid schema completeness with 5 well-defined tools. All tools have clear descriptions (74-225 chars) and explicit JSON schemas with proper type definitions and patterns for date parameters. Parameter descriptions are generally present and specific. However, there are notable gaps in output schema documentation, error handling guidance, and some missing descriptions for nested parameters. The tool naming is clear and action-oriented (get_*, post_*, delete_*, bulk_*), following proper verb_noun conventions. The server handles sensitive operations (WRITE, DESTRUCTIVE) appropriately but lacks explicit error recovery guidance and confirmation patterns for destructive operations.
Tools (5)
bulk_post_worklogswriteauth50/100
Create multiple worklog entries from a structured format. RECOMMENDED: Use get_schedule first to identify working days and avoid logging time on non-working days.
delete_worklogdestructiveauth50/100
Delete an existing worklog entry
get_scheduleread onlyauth50/100
Retrieve work schedule for authenticated user and date range
get_worklogsread onlyauth50/100
Retrieve worklogs for authenticated user and date range
post_worklogwriteauth50/100
Create a new worklog entry. For better results, consider using get_schedule first to verify working days and expected hours.
Output schemas not documented for any tool. LLMs cannot determine what fields to expect from responses, forcing them to guess at available data for chaining downstream calls. This violates pattern:tool and pattern:response-shaper.
delete_worklog lacks confirmation/dry-run capability. This is a destructive operation (stated as DESTRUCTIVE risk) but has no confirmation step, preventing agents from verifying intent before permanent deletion. Violates pattern:confirmation-request.
Error handling guidance absent. No tool description indicates what errors might occur, how to recover, or what the agent should do on failure. Violates pattern:recovery-guide and pattern:error-classification.
Document output schema for each tool. For get_worklogs, specify returned fields: worklogId, issueKey, hours, date, description, billable, etc. For post_worklog and bulk_post_worklogs, return confirmation with created worklogId(s). For delete_worklog, return success confirmation with deleted worklogId. For get_schedule, document schedule structure (e.g. days, workingHours, offDays). Use _meta.outputSchema in tool definitions or update tool descriptions to include 'Returns: {...}' with field types.
Add confirmation step for delete_worklog. Implement a two-phase pattern: 1) confirm_delete_worklog(worklogId) returning {worklogId, issueKey, hours, date} to let agent verify before proceeding, 2) delete_worklog(confirmationToken) to execute after user/agent confirmation. This prevents accidental data loss.
Enhance tool descriptions with error recovery guidance. E.g. post_worklog should state: 'Returns error if issueKey does not exist, use get_schedule first to verify working days.' get_schedule should explain: 'Retrieve expected working hours per day. Use before posting worklogs to avoid logging on non-working days.' delete_worklog should warn: 'Permanently removes worklog entry. No undo available, verify worklogId before calling.'
Clarify relationship between post_worklog and bulk_post_worklogs. Add to post_worklog description: 'For single entries. Use bulk_post_worklogs for multiple entries across different dates.' Add to bulk_post_worklogs: 'For batch operations. Each entry requires {issueKey, hours, date}, use get_schedule first to identify working days.'
bulk_post_worklogs array items lack complete parameter descriptions. The nested 'description' field in worklogs array items has no description text explaining its purpose or format.
post_worklog and bulk_post_worklogs both accept date ranges but differ subtly in parameter naming (post_worklog uses startDate/endDate, bulk uses date per item). Tool descriptions mention consulting get_schedule but do not explain the relationship or when each pattern applies.
get_schedule description (70 chars) is minimal and does not explain what 'work schedule' means (working hours per day? off-days? calendar events?) or how it differs from worklogs. Violates pattern:tool-description expectations for context.
get_schedule
Expand get_schedule description to explain output: 'Returns work schedule showing expected working hours per day and any scheduled off-days. Use before posting worklogs to identify available working days and avoid logging time on holidays or non-working days.'
Add validation rules to parameter descriptions. E.g. hours param: 'Decimal hours 0.1 - 24 per entry. Total hours per day should not exceed schedule hours (verify with get_schedule).' issueKey: 'Valid JIRA issue key format (e.g., PROJ-1234, JIRA-5678). Tool will validate existence, invalid keys return clear error.'
Document idempotency guarantees for post_worklog and bulk_post_worklogs. If they support deduplication by issueKey + date + hours, state this so agents understand retry safety. If not, note that retries may create duplicates.
Implement per-item error reporting in bulk_post_worklogs response. If 3 out of 5 entries fail, return {successful: [{...}], failed: [{worklogIndex: 1, issueKey: '...', error: '...', suggestion: '...'}]} rather than a blanket error. This allows agent to retry only failed items.