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
- Connect a Jira workspace through the Pipedream MCP.
- Inspect the parameter instructions for
jira-get-issue.
- Note that the required
cloudId parameter directs the agent to use retrieve_options.
- Confirm that no
retrieve_options tool is exposed by the MCP.
- Call
jira-get-issue using an internal connection or application identifier as cloudId.
- Observe that the request fails.
- Call
jira-get-cloud-id to obtain the actual Jira Cloud ID.
- Retry
jira-get-issue using the returned Cloud ID.
- 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.
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.
Update: In Pipedream
/v3direct/full-config mode,retrieve_optionsis correctly exposed. The originally observed tool-availability problem was caused by Get BOB using the smaller Connect API action catalogue rather than MCPtools/list. The remaining Pipedream request is an integration-hardening improvement: explicitly direct agents tojira-get-cloud-idand 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-issuetool says to use aretrieve_optionstool to obtain the Jira Cloud ID:However, no
retrieve_optionstool is available in the MCP. A workingjira-get-cloud-idtool 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 callsjira-get-cloud-id, the subsequent request succeeds.The same incorrect
retrieve_optionsguidance appears across multiple Jira tools.To Reproduce
jira-get-issue.cloudIdparameter directs the agent to useretrieve_options.retrieve_optionstool is exposed by the MCP.jira-get-issueusing an internal connection or application identifier ascloudId.jira-get-cloud-idto obtain the actual Jira Cloud ID.jira-get-issueusing the returned Cloud ID.Example, with identifiers redacted:
Expected behavior
Jira tool parameter instructions should direct agents to call the existing
jira-get-cloud-idtool whenever a Jira Cloud ID is required.The instructions should not reference
retrieve_optionsunless 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-issueparameter documentation referencing the unavailableretrieve_optionstool.Additional context
This issue causes inconsistent agent behavior:
jira-get-cloud-id, the Jira request succeeds.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.