feat(issue): Link external issues

[dcramer]

Add URL-based external issue linking to update_issue so agents can link an existing external ticket without knowing Sentry integration ids or provider form fields.

Minimal Link API

update_issue now links existing external issues with a single new input:

update_issue({
  organizationSlug: "my-org",
  issueId: "PROJECT-123",
  externalIssueUrl: "https://github.com/getsentry/sentry/issues/123",
})

The same field is used for Jira, GitHub, GitLab, Bitbucket, Azure DevOps, Linear, and Shortcut URLs. There is no provider field, integration id, installation UUID, or raw provider form payload in the public tool API.

Integration Resolution

Native issue integrations resolve through Sentry's group integration endpoints and validate parsed URL fields against Sentry link config. Sentry App links resolve installed app UUIDs internally for Linear and Shortcut URLs.

Verification

Covered with API client tests, resolver tests, update tool tests, generated definitions, and an end-to-end local stdio check linking a Sentry issue to a temporary GitHub issue.

Fixes #228

[sentry-warden]

Non-matching domain Jira/GitLab/Bitbucket/VSTS integration selected when bestDomainScore is zero

When an organization has exactly one native integration (e.g., Jira) whose domainName is set but does not match the URL being linked, bestDomainScore is 0 and the domain-filter branch is skipped entirely, so the wrong-domain integration is selected and linkNativeExternalIssue is called against a different instance than the one the URL belongs to — producing a confusing backend error or, if the issue key coincidentally exists in the wrong instance, a silently incorrect external-issue link. The GitHub Enterprise guard exists for the same class of problem but only covers non-github.com GitHub URLs; no equivalent guard rejects a mismatched Jira/GitLab/VSTS/Bitbucket domain.

Evidence

• resolveNativeTarget in issue-linking.ts computes bestDomainScore = Math.max(0, ...candidates.map(domainMatchScore)). When the only Jira integration has domainName = 'other.atlassian.net' and the URL is acme.atlassian.net, every domainMatchScore call returns 0, so bestDomainScore = 0.
• The GitHub-Enterprise guard (parsed.provider === 'github' && parsed.host !== 'github.com' && bestDomainScore === 0) does not fire for jira/gitlab/bitbucket/vsts providers.
• if (bestDomainScore > 0) is false, so the candidate list is never filtered — the wrong-domain integration remains.
• Jira's linkIssueConfig typically contains only an externalIssue field with no choices, so configMatchesParsedUrl returns true for the wrong integration, making it the sole matchingCandidate.
• buildNativeLinkPayload sets payload.externalIssue = parsed.issueId and the PUT is dispatched to the wrong Jira integration, causing a backend error or a link to an unrelated ticket.

_{Identified by Warden code-review}

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit d005fa2. Configure here.}

[cursor]

Partial success returns isError: true contradicting reviewer guidance

Medium Severity

The partial-success response (issue update succeeded but link write failed) sets isError: true, which causes MCP clients to treat the entire operation as failed and potentially retry it. Since the Sentry issue update already succeeded, a retry would redundantly re-apply the status/assignment change. The PR discussion explicitly states this was addressed by removing isError: true so clients don't treat the already-applied update as retryable, but that fix isn't reflected in the final code.

Additional Locations (1)

• packages/mcp-core/src/tools/update-issue.test.ts#L1139-L1158

 

^{Reviewed by Cursor Bugbot for commit d005fa2. Configure here.}

[cursor]

Unused getTextToolResult helper function never called

Low Severity

getTextToolResult is defined but never called anywhere in the codebase. The PR discussion mentions this was "fixed in a43ddea by removing the unused helper" but it remains in the final diff. Only getErrorToolResult is actually used by the partial-success tests.

 

^{Reviewed by Cursor Bugbot for commit d005fa2. Configure here.}