Jira Service Desk ACTION
Find Service Desk Customers
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 john@acme.com", "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- Action
- Read only
- OAuth
- SDK
- MCP
IMPLEMENTATION
Call this tool
Connect a user's Jira Service Desk account once, then configure and run Find Service Desk Customers from your backend or agent.
import { PipedreamClient } from "@pipedream/sdk"
const pd = new PipedreamClient({
projectId: process.env.PIPEDREAM_PROJECT_ID!,
clientId: process.env.PIPEDREAM_CLIENT_ID!,
clientSecret: process.env.PIPEDREAM_CLIENT_SECRET!,
projectEnvironment: "production",
})
const result = await pd.actions.run({
id: "jira_service_desk-find-service-desk-customers",
externalUserId: "{external_user_id}", // any stable ID for this user in your system
configuredProps: {
jira_service_desk: { authProvisionId: "apn_xxxxxxx" },
cloudId: "Cloud ID",
serviceDeskId: "Service Desk ID",
},
})
console.log(result)curl -X POST https://api.pipedream.com/v1/connect/{project_id}/actions/run \
-H "Content-Type: application/json" \
-H "X-PD-Environment: production" \
-H "Authorization: Bearer {access_token}" \
-d '{
"external_user_id": "{external_user_id}",
"id": "jira_service_desk-find-service-desk-customers",
"configured_props": {
"jira_service_desk": { "authProvisionId": "apn_xxxxxxx" },
"cloudId": "Cloud ID",
"serviceDeskId": "Service Desk ID"
}
}'// accessToken: mint a short-lived token with the Connect SDK — see the MCP guide
const transport = new StreamableHTTPClientTransport(
new URL("https://remote.mcp.pipedream.net/v3"),
{
requestInit: {
headers: {
Authorization: `Bearer ${accessToken}`,
"x-pd-project-id": "{project_id}",
"x-pd-environment": "production",
"x-pd-external-user-id": "{external_user_id}", // any stable ID for this user in your system
"x-pd-app-slug": "jira_service_desk",
},
},
},
)
const mcp = new Client({ name: "my-agent", version: "1.0.0" })
await mcp.connect(transport)
const { tools } = await mcp.listTools()
// listTools() hands your model this tool's input schema, so it can
// fill the arguments itself:
const result = await mcp.callTool({
name: "jira_service_desk-find-service-desk-customers",
arguments: {
cloudId: "Cloud ID",
serviceDeskId: "Service Desk ID",
},
})SCHEMA
Inputs
Pipedream supplies the connected account. Your application provides the operation-specific values below. Dynamic inputs are resolved against that user's account.
| Property | Type | Description |
|---|---|---|
cloudId Cloud ID | string | The Atlassian site (cloud) ID, e.g. 822faf0d-5427-420e-9016-999d3dc76918. Run List Sites to get the id of every site you can access. Required |
serviceDeskId Service Desk ID | string | The service desk whose customers to search, e.g. 1. Run List Service Desks to map a project name or key to its ID. Use the same ID you will pass to Create Request, so the match is checked against the desk the ticket will actually be raised on. Required |
query Query | string | Name or email address to search for, e.g. Joseph Wilson or joseph@example.com. Matched against displayName and emailAddress. Omit to list every customer of the desk. Optional |
maxResults Max Results | integer | Maximum number of customers to return across all pages (1-1000). Optional |
REFERENCE
Tool details
Behavior hints are published with the component in the Pipedream registry and surface as MCP tool annotations, so an agent can reason about a tool before it calls it.
- Registry key
- jira_service_desk-find-service-desk-customers
- Version
- 0.0.1
- App
- Jira Service Desk
- Authentication
- OAuth
- Read-only
- Yes
- Destructive
- No
- Open world
- Yes
- Source
- View on GitHub ↗