Connect Your AI Agent with Jira Service Desk for Slack

Creates a customer request (ticket) in a Jira Service Management service desk. This is the single tool for creating any kind of ticket (incident, service request, access request, hardware request, and so on). The kind of ticket is decided by requestTypeId, not by the wording of the summary, so always pick the request type deliberately. Use List Sites to get cloudId, List Service Desks to get serviceDeskId, and List Request Types to choose the requestTypeId whose name and description match the user's intent. Call List Request Type Fields to see which fields that request type accepts and requires; pass anything beyond summary and description in additionalFieldValues, keyed by Jira field ID. Only send the fields that request type lists: some request types hide Summary or Description behind a preset value and reject a create that supplies them, so omit summary and description when they are not listed. Worked example: on service desk 1, request type 4 ("Onboard new employees") requires summary and also accepts a duedate, so call with Summary Joseph Wilson starts on September 1, Description Needs a laptop and an email account, and Additional Field Values { "duedate": "2026-09-01" }. Optionally attach one or more files at creation time via attachments; to add, replace, or delete attachments on a request that already exists, use Manage Request Attachment instead. Returns the created request including its issueKey and issueId. If attachments is set, the response also includes either an attachments array (on success) or an attachmentError string (if the request was created but the attachment step failed) — the request itself is never rolled back because of an attachment failure. See the documentation

Lists the Atlassian sites you can raise requests on, as {label, value} options, to discover the cloudId every other Jira Service Desk tool needs. Takes no input beyond the account. Example: returns [{ "label": "acme", "value": "822faf0d-5427-420e-9016-999d3dc76918" }]. Use List Sites instead if you want the full site records. See the documentation

Updates fields on an existing Jira Service Desk request via the Jira platform API. Use this to change the summary, priority, description, or other fields after a request has been created. Use List Sites first to obtain the required cloudId. Use List My Requests or Get Request to find the issueKey (e.g. IT-42). fields is a JSON object of field name-value pairs. Example: {"summary": "Updated title", "priority": {"name": "High"}}. See the documentation

Transitions a Jira Service Desk request to a new workflow status. Use List Request Transitions first to get valid transitionId values for the request. Use List Sites to obtain the required cloudId. Use List My Requests or Get Request to find the issueKey (e.g. IT-42). Optionally include a comment to explain the transition. See the documentation

Adds, replaces, or deletes a single attachment on a customer request (ticket) that already exists. To attach file(s) while creating a brand-new request, use Create Request's attachments prop instead — use this tool only for requests that already exist. Set operation to add to attach a new file, update to replace an existing attachment with a different file (there's no in-place replace in the API, so this uploads the new file and only deletes the old one once the new one is confirmed attached), or delete to remove an attachment. add and update require serviceDeskId (the temp-file upload step is scoped by service desk, not by issue) — use List Service Desks to find it, or read it off the response of the request that created the ticket. update and delete require attachmentId, the numeric ID of the attachment being replaced or removed; the add/update response doesn't expose this as a plain field, so use List Issue Attachments on the same request to look it up. Worked example: to replace an attachment 10050 on request HD-12 with a new file, call with Operation update, Issue ID Or Key HD-12, Service Desk ID 1, Attachment ID 10050, and File /tmp/revised-report.pdf. For update, if the new file attaches successfully but removing the old attachment then fails, the response includes a deleteError string alongside the successful attachment data — the request ends up with both files rather than losing either one, and the error is never masked as a full failure. By default the attachment is visible to the customer who raised the request (public: true); set public to false to attach an internal-only file. See the documentation

Returns all Atlassian cloud sites accessible to the authenticated user. Call this tool first to obtain the cloudId (returned as id) required by every other Jira Service Desk tool. Each site includes its id (cloudId), name, and url. See the documentation

Lists every service desk on an Atlassian site, with the id and project details of each. Call this to discover the serviceDeskId required by Create Request, List Request Types, and List My Requests when you only know a project name or key. Use List Sites first to obtain the required cloudId. Results are paginated automatically up to maxResults. Returns { serviceDesks, truncated }, where truncated is true when more desks remained unfetched. Example: a site with one desk returns { "serviceDesks": [{ "id": "1", "projectName": "Support", "projectKey": "SUP" }], "truncated": false }. See the documentation

Lists the customer request types a service desk offers, with the id, name, and description of each. Call this before Create Request to choose the requestTypeId that matches what the user is asking for: the request type, not the summary wording, decides what kind of ticket gets created. Names vary by desk, so match on meaning rather than assuming a type called "Incident" exists (an IT desk may instead offer "Report a system problem"). Use List Sites for cloudId and List Service Desks for serviceDeskId. Results are paginated automatically up to maxResults. Returns { requestTypes, truncated }, where truncated is true when more types remained unfetched. Example: service desk 1 returns entries such as { "id": "8", "name": "Report a system problem", "description": "Let us know if something isn't working properly", "canCreateRequest": true }. Types with canCreateRequest: false cannot be used to raise a request. Then call List Request Type Fields to see what the chosen type requires. See the documentation

Lists the fields a given request type accepts, so you can build the additionalFieldValues argument for Create Request in a single pass. Each entry gives the fieldId to use as the key, whether it is required, its jiraSchema (the value format), and any validValues for select-style fields. Use List Sites for cloudId, List Service Desks for serviceDeskId, and List Request Types for requestTypeId. Example: request type 4 ("Onboard new employees") on service desk 1 returns a required summary plus optional duedate (jiraSchema.type date, so pass "2026-09-01"), description, and attachment. Also returns canRaiseOnBehalfOf and canAddRequestParticipants, which tell you whether the raiseOnBehalfOf and requestParticipants arguments of Create Request are usable with this account. Hidden fields are only visible to service desk administrators. See the documentation

Lists the available workflow transitions for a Jira Service Desk request, returning each transition's id and name. Transitions are paginated automatically up to maxResults. Returns { transitions, truncated }, where truncated is true when more transitions remained unfetched. Call this before Transition Request to obtain valid transitionId values. Use List Sites first to obtain the required cloudId. Use List My Requests or Get Request to find the issueKey (e.g. IT-42). See the documentation

Lists Jira Service Desk requests owned or participated in by the current user. Defaults to open requests owned by the current user. Results are paginated automatically up to maxResults. Returns { requests, truncated }, where truncated is true when more requests remained unfetched. Use List Sites first to obtain the required cloudId. Each result includes issueKey, issueId, and request field values (summary, status). requestStatus: OPEN_REQUESTS (default), CLOSED_REQUESTS, or ALL_REQUESTS. requestOwnership: OWNED_REQUESTS (default) or PARTICIPATED_REQUESTS. See the documentation

List metadata for every attachment on a Jira Service Desk request. issueIdOrKey accepts either a Jira issue key (e.g. IT-42) or a numeric Jira issue ID (e.g. 10001). Results are paginated automatically up to maxResults. Returns { attachments, truncated }, where each attachment includes id, filename, size (bytes), mimeType, and content (an opaque reference URL whose exact shape varies by account access level and is not directly fetchable through this connection's authentication), and truncated is true when more attachments remained unfetched. Use Download Issue Attachment with an attachment id and the same issueIdOrKey to fetch the binary content — do not call content directly. If this connection has customer-level access rather than agent access, only public attachments are returned; internal attachments exist but won't appear here. Returns { attachments: [], truncated: false } (no error) when the request exists but has no visible attachments. Example: issue IT-42 with one attachment returns { "attachments": [{ "id": "10042", "filename": "screenshot.png", "size": 84213, "mimeType": "image/png", "content": "<opaque reference URL>" }], "truncated": false }. See the documentation

Fetches the full details of a Jira Service Desk request including its field values and comment thread in a single response. Comments are paginated automatically up to maxResults; the summary says so when the thread was truncated. Use this to summarize a ticket without needing follow-up calls. Use List Sites first to obtain the required cloudId. Use List My Requests to find the issueKey of a request (e.g. IT-42). See the documentation

Returns the status history of a Jira Service Desk request: the current status plus previous states with timestamps. The history is paginated automatically up to maxResults. Returns { statuses, truncated }, newest first, where truncated is true when more entries remained unfetched. Use this to understand how a request has progressed through the workflow. Use List Sites first to obtain the required cloudId. Use List My Requests to find the issueKey (e.g. IT-42). See the documentation

Returns the authenticated user's account_id, display_name, and email from Atlassian. Use this to identify who is logged in, or to filter requests by the current user's account_id. No cloudId required — this uses the Atlassian Identity API directly. See the documentation

Finds any active user on an Atlassian site by name or email address and returns the accountId of each match. Pick this tool when the person does not have to be a customer of one particular service desk, i.e. to fill requestParticipants on Create Request with an approver, manager, watcher, or agent, or when the user names somebody but no service desk is known yet. Natural-language cues: "add my manager Dana as a participant", "cc the security lead on this ticket", "loop in [email protected]", "what is the account ID for Jean?". Pick Find Service Desk Customers instead when you already know the service desk and the person is the one the ticket is being raised for (raiseOnBehalfOf). That tool is more precise, confirms the person can actually raise a request on that desk, and excludes bots. Use List Sites first to obtain the required cloudId. Worked example: for "open a laptop request and add Dana Lee as a participant", call this with Query Dana Lee, read accountId 5b10a2844c20165700ede21g off the match whose accountType is atlassian, then pass ["5b10a2844c20165700ede21g"] as requestParticipants on Create Request. Most users on a Jira site are bots, not people. Integrations come back as ordinary matches carrying accountType app, so read accountType and use only atlassian accounts as raiseOnBehalfOf or requestParticipants. Query is matched against displayName and emailAddress, and matches more than just the start of them. Pass a full name or a full email address to keep the result set tight. Results are paginated automatically up to maxResults. Returns { users, truncated }. truncated is true when the result set may be incomplete, either because more matches remained unfetched or because collection stopped at Atlassian's 1000-match limit, which looks the same whether or not further matches exist. Once you have 1000 matches, narrow the query rather than raising maxResults, which cannot go higher. accountId is the only field guaranteed present: Atlassian's profile visibility rules hide emailAddress on users who have not made it public, so match on displayName and never require an email to be returned. An empty users list means either nobody matched or the connected account lacks the "Browse users and groups" global permission, which Atlassian reports as zero results rather than as an error. See the documentation

Finds the customers of one service desk by name or email address and returns the accountId of each match. Pick this tool when the person is the one the ticket is being raised for on a service desk you can identify, i.e. to fill raiseOnBehalfOf on Create Request. Natural-language cues: "raise a ticket for Jean on the IT desk", "open a request on behalf of [email protected]", "file this for my colleague Dana", "submit a hardware request for the new starter". Pick Find Users instead when the person does not have to be a customer of this desk, such as an approver, manager, or agent you are adding to requestParticipants, or when you cannot tell which service desk applies. Prefer this tool wherever both would work: it searches only this desk's customer list, so a match proves the person can actually raise a request here, and bot accounts are excluded (a site-wide search on a live site returned 17 users of which 16 were integrations). Use List Sites for cloudId and List Service Desks for serviceDeskId first. Worked example: for "open a laptop request for Joseph Wilson on the IT desk", call this with Service Desk ID 1 and Query Joseph Wilson, read accountId 5b10a2844c20165700ede21g off the single match, then call Create Request with Service Desk ID 1 and that accountId as raiseOnBehalfOf. Omit Query to list every customer of the desk, which answers "who can raise requests on this desk?". Query is matched against displayName and emailAddress, and matches more than just the start of them. Pass a full name or a full email address to keep the result set tight. If nobody matches, the person may exist on the site without being a customer of this desk, retry with Find Users. Results are paginated automatically up to maxResults. Returns { users, truncated }, where truncated is true when more matches remained unfetched. accountId is the only field guaranteed present: Atlassian's profile visibility rules hide emailAddress on users who have not made it public, so match on displayName and never require an email to be returned. An unknown or inaccessible Service Desk ID fails with a 404 rather than returning an empty list, so an empty list really does mean nobody matched. See the documentation

Download the binary content of a Jira Service Desk attachment to the file-stash directory, returning the saved path plus the attachment metadata (filename, mimeType, size). Run List Issue Attachments first to obtain the attachment id, then pass both it and the same issueIdOrKey here. Example: passing issueIdOrKey IT-42 and attachmentId 10042 downloads screenshot.png to /tmp/10042-screenshot.png and returns { "filedata": ["10042-screenshot.png", "/tmp/10042-screenshot.png"], "attachment": { "id": "10042", "filename": "screenshot.png", "mimeType": "image/png", "size": 84213 } }. See the documentation

Create a comment on a customer request. See the documentation