Skip to content

[Enhancement] Make Jira Cloud ID discovery explicit in MCP tool guidance #21397

Description

@TheDanubian

Update: In Pipedream /v3 direct/full-config mode, retrieve_options is correctly exposed. The originally observed tool-availability problem was caused by Get BOB using the smaller Connect API action catalogue rather than MCP tools/list. The remaining Pipedream request is an integration-hardening improvement: explicitly direct agents to jira-get-cloud-id and distinguish Jira Cloud IDs from Pipedream identifiers.

Describe the bug

Several Jira MCP tools provide incorrect instructions for resolving required parameters such as cloudId.

For example, the jira-get-issue tool says to use a retrieve_options tool to obtain the Jira Cloud ID:

You can use the "retrieve_options" tool using these parameters to get the values. key: jira-get-issue, propName: cloudId.

However, no retrieve_options tool is available in the MCP. A working jira-get-cloud-id tool does exist, but the parameter instructions do not reference it.

This can cause agents to pass an unrelated internal identifier as cloudId. The Jira request then fails, and the agent may incorrectly conclude that the Jira connection or issue is unavailable. When the agent independently discovers and calls jira-get-cloud-id, the subsequent request succeeds.

The same incorrect retrieve_options guidance appears across multiple Jira tools.

To Reproduce

  1. Connect a Jira workspace through the Pipedream MCP.
  2. Inspect the parameter instructions for jira-get-issue.
  3. Note that the required cloudId parameter directs the agent to use retrieve_options.
  4. Confirm that no retrieve_options tool is exposed by the MCP.
  5. Call jira-get-issue using an internal connection or application identifier as cloudId.
  6. Observe that the request fails.
  7. Call jira-get-cloud-id to obtain the actual Jira Cloud ID.
  8. Retry jira-get-issue using the returned Cloud ID.
  9. Observe that the request succeeds.

Example, with identifiers redacted:

// Fails: unrelated internal identifier used as cloudId
{
  "cloudId": "<internal-id>",
  "issueIdOrKey": "SCRUM-2",
  "fields": "summary,status,labels,assignee,reporter,updated,created"
}

// Succeeds: actual Jira Cloud ID returned by jira-get-cloud-id
{
  "cloudId": "<jira-cloud-uuid>",
  "issueIdOrKey": "SCRUM-2",
  "fields": "summary,status,labels,assignee,reporter,updated,created"
}

Expected behavior

Jira tool parameter instructions should direct agents to call the existing jira-get-cloud-id tool whenever a Jira Cloud ID is required.

The instructions should not reference retrieve_options unless that tool is actually exposed and functional. Ideally, the guidance should also distinguish the Jira Cloud ID from internal Pipedream connection, account, or application identifiers.

Screenshots

Attached screenshot shows the jira-get-issue parameter documentation referencing the unavailable retrieve_options tool.

Image

Additional context

This issue causes inconsistent agent behavior:

  • If the agent happens to call jira-get-cloud-id, the Jira request succeeds.
  • If it follows the provided parameter instructions, it cannot call the referenced tool and may guess or reuse an invalid identifier.
  • The resulting error can be misreported to the user as a Jira connection, permission, or issue-availability problem.

We observed the incorrect guidance on multiple Jira tools, so the Jira integration’s parameter descriptions may need to be corrected centrally rather than only for jira-get-issue.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingtriagedFor maintainers: This issue has been triaged by a Pipedream employee

    Type

    Projects

    Status
    Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions