Get a single Jira issue by key (e.g. PROJ-123).

Args: issue_key: The issue key, e.g. PROJ-123. fields: Optional comma-separated list of fields to return (e.g. summary,status,assignee). Defaults to all fields.

Search issues with a JQL query.

Args: jql: A JQL query, e.g. project = PROJ AND status = "In Progress". limit: Maximum number of issues to return (default 50).

Add a comment to a Jira issue.

Args: issue_key: The issue key, e.g. PROJ-123. comment: The comment body (plain text / Jira wiki markup).

List the issue types available for create_issue.

Call this first when unsure what issue_type a project accepts — instances rename and translate types (Task/Задача, Story, Sub-task), so guessing produces a 400.

Args: project_key: Optional project key to restrict to the types actually enabled in that project's scheme. Without it, every type on the instance is returned.

Create a Jira issue — epic, task, story or sub-task.

CALL THIS TOOL STRICTLY ON THE USER'S EXPLICIT REQUEST. It writes a real issue into the project under the token owner's name and this server cannot delete it afterwards. Never create issues on your own initiative (not to "track" work you are doing, not as an inferred step of another request). When several issues are described at once, confirm the list with the user before creating them.

Args: project_key: Target project key, e.g. PROJ. summary: Single-line title of the issue. issue_type: Type name as it appears in Jira — Task (default), Epic, Story, Bug, Sub-task… Call get_issue_types when unsure; names are instance-specific and may be localised. description: Body text (plain text / Jira wiki markup). parent: Key of the parent issue. For a sub-task this is its parent task (required). For any other type this is the epic it belongs to — it is written to the Epic Link field. epic_name: Short board label for an epic. Epics only; defaults to summary when omitted. assignee: Username (Server/DC login) to assign the issue to. priority: Priority name, e.g. Major. labels: Labels to set. components: Component names to set. due_date: Due date, YYYY-MM-DD. extra_fields: Raw field overrides merged in last, for anything this signature does not cover — e.g. story points or a required custom field: {"customfield_10004": 3}.

Returns the created issue: key, id, url and the resolved type/parent, so the key can be reused directly (e.g. as parent for the epic's children).

List all Jira projects visible to the authenticated user.

Args: include_archived: Include archived projects in the result. expand: Optional comma-separated list of fields to expand (e.g. description,lead,url).

Get a single Jira project by its key or id.

Args: project_key: The project key or id, e.g. PROJ or 10001. expand: Optional comma-separated list of fields to expand (e.g. description,lead,url).

List all Jira users (union of the groups that grant Jira access).

Jira Server/DC has no single "all users" endpoint — users are enumerated through group membership. By default this reads every group that grants Jira Software access on this instance and de-duplicates the members. Pass groups to target specific group(s) instead.

Args: groups: Group names to read. Defaults to the instance's Jira Software license groups. status: Which users to return by account state — active (default, enabled users only), inactive (deactivated / blocked / former employees, active=false), or all.

Find Jira groups by name — use it to discover the license group name.

Handy when you don't know which group holds all users. Search e.g. users to find candidates like jira-users / jira-software-users, then pass the right one to get_all_users.

Args: query: Substring to match against group names (default users). limit: Maximum number of groups to return (default 20).

Search Jira users by name, username or email fragment.

Args: query: Substring to match against username, display name or email. limit: Maximum number of users to return (default 50). include_inactive: Include deactivated users in the result.

Total hours a user logged in a date range, optionally broken down.

Uses the Tempo Timesheets API: one search returns all of the user's worklogs in [date_from, date_to] (both inclusive), filtered server-side.

Args: username: Tempo worker (Jira username / key). date_from: Start date, inclusive, YYYY-MM-DD. date_to: End date, inclusive, YYYY-MM-DD. project: Optional project key to restrict to (e.g. PROJ). breakdown: Optional grouping — day, project, issue, account, both (=project+issue), all, or a comma-separated combo like day,project. When day is combined with project/issue the project/issue hours are nested inside each day; otherwise they are flat for the period. exclude_absence: Drop vacation / sick-leave worklogs (Tempo's Absence account). Off by default so totals match Tempo.

Total hours a group of users logged in a date range, per user.

Uses the Tempo Timesheets API: one search covers every user in usernames for [date_from, date_to] (both inclusive) — a single request, regardless of team size or breakdown. by_user always lists each worker's total; breakdown nests that worker's own day/project/ issue split inside their entry (still one request — never call this once per user).

Args: usernames: Tempo workers (Jira usernames / keys). date_from: Start date, inclusive, YYYY-MM-DD. date_to: End date, inclusive, YYYY-MM-DD. project: Optional project key to restrict to (e.g. PROJ). breakdown: Optional per-worker grouping — day, project, issue, both (=project+issue), all, or a comma combo like day,project. Each requested dimension appears as by_day / by_project / by_issue inside every user's entry (e.g. day → hours-per-day per worker in one call).

Hours every member of a Tempo team logged in a date range, per worker.

Reproduces Tempo's "Logged Time" report grouped by worker (the Tempo.jspa#/reports/logged-time?teamId=…&groupBy=worker view): one worklog search filtered by teamId covers the whole team for [date_from, date_to] (both inclusive). The team roster is fetched separately so members who logged nothing still appear with 0 hours.

Args: team_id: Tempo team id (the teamId from the report URL, e.g. 79). date_from: Start date, inclusive, YYYY-MM-DD. date_to: End date, inclusive, YYYY-MM-DD. include_subtasks: Include worklogs on subtasks (the report's includeSubtasks toggle). Defaults to Tempo's own default. breakdown: Optional per-worker grouping — day, project, issue, both (=project+issue), all, or a comma combo like day,project. Each requested dimension appears as by_day / by_project / by_issue inside every worker's entry (e.g. day → hours-per-day per worker, the whole timesheet matrix, in ONE call — never call this once per user). only_active: Keep only current employees on an open team membership (default). Set False to include people who left the company or moved off the team — a team's roster accumulates them for years, so the default keeps the report to the people working now. exclude_absence: Drop vacation / sick-leave worklogs, which Tempo logs against a dedicated Absence account. Off by default so totals match Tempo's own report; turn it on to read the numbers as actual workload — otherwise a week of vacation looks identical to a week of work (8h/day either way).

Log time on a Jira issue, as the user who owns the API token.

CALL THIS TOOL STRICTLY ON THE USER'S EXPLICIT REQUEST. It is the only tool here that writes: it creates a real worklog under the user's name and cannot be undone from this server. Never call it on your own initiative — not after finishing a task, not to "correct" hours seen in a report, not as a step inferred from some other request. If the user has not asked to log time, ask them first.

Args: issue_key: The issue to log against, e.g. PROJ-123. time_spent: Duration in Jira syntax — 2h, 90m, 2h 30m, 1d 4h (w/d/h/m). Jira converts it using the instance's working day/week, so 1d is usually 8h, not 24h. started: When the work happened. YYYY-MM-DD (anchored at 09:00 local time), YYYY-MM-DDTHH:MM, or a timestamp with an offset. Defaults to now — pass the date explicitly when logging for a past day. comment: Optional worklog comment (plain text / Jira wiki markup).

Returns the created worklog: id, time_spent, started, author and a browse link to the issue.

List every Tempo team (id, name, lead, …).

Use this to discover a team's numeric teamId for get_team_worklog. To look one up by name, prefer find_team.

Args: expand: Optional comma-separated Tempo expand fields (e.g. lead,program).

Find Tempo teams whose name contains query (case-insensitive).

Tempo has no server-side team search, so this lists every team and filters locally. Handy to turn a team name into the teamId that get_team_worklog needs.

Args: query: Substring to match against the team name. expand: Optional comma-separated Tempo expand fields (e.g. lead,program).

List all members of a Tempo team.

Reads rest/tempo-teams/2/team/{team_id}/member/. Each member's key is the same value the Tempo worklog worker field carries — so it's what you pass on to per-user worklog tools. Note this is the Tempo team roster, not a Jira user group (see get_all_users for groups).

Args: team_id: Tempo team id (e.g. 79). raw: Return Tempo's untouched membership objects instead of the flattened key / display_name / role / membership-window shape. Use when you need fields not surfaced by default.

What a user is planned for in Tempo Planner over a date range.

Answers "which projects is this person allocated to, for how many hours per day": fetches the user's plan allocations and expands them into planned hours within [date_from, date_to] (both inclusive), using the user's Tempo working-day calendar so weekends and public holidays are excluded exactly as Tempo itself does.

Args: username: Jira username / login (Tempo assignee key). date_from: Start date, inclusive, YYYY-MM-DD. date_to: End date, inclusive, YYYY-MM-DD. breakdown: Pass day to add by_day — planned hours for each date in the range, split by project inside each day. Omit for the compact view (plans + per-project totals only).

Returns plans (each allocation with its hours_per_day, period and target project/issue), by_project totals for the range, and optionally by_day.

What a group of users is planned for in Tempo Planner, per user.

One allocation request covers every user in usernames for [date_from, date_to] (both inclusive) — never call this once per user. Each user's plans are then expanded against their own working-day calendar (calendars differ: part-time, regional holidays), so weekends and public holidays are excluded exactly as Tempo does.

Args: usernames: Jira usernames / logins (Tempo assignee keys). date_from: Start date, inclusive, YYYY-MM-DD. date_to: End date, inclusive, YYYY-MM-DD. breakdown: Pass day to add by_day inside every user's entry — planned hours for each date, split by project within each day. Omit for the compact view.

Returns by_user (each user's plans, by_project totals and optionally by_day, users sorted by planned hours desc; users with no plans appear with 0) and cross-user by_project totals.