linkFindingTicket
Associate an external ticket (Jira, Linear, GitHub, ServiceNow) with one or more Mallory findings, and manage those associations. Actions: link (register a ticket against findings), attach (add more findings to a ticket already registered here), unlink (remove one finding from a ticket), list (what is linked to a finding), connections (which ticketing systems this tenant has configured).
link, attach and unlink WRITE the caller's own organization's data and take effect immediately — call them only when the user has asked for it. list and connections are read-only; call them whenever you need to know what is linked or what is configured.
TWO STEPS, BOTH REQUIRED. This tool does NOT create the ticket. Create it with the ticketing system's own tools, then call this with action "link" to register the id it returned. A ticket you created and did not register is invisible to Mallory: the finding page shows nothing, and from the user's point of view the request silently did not happen.
A CONFIGURED MALLORY TICKETING INTEGRATION IS NOT A PRECONDITION. With provider + external_id, link is a plain database write inside Mallory — it does not contact the ticketing system. Register the id even when "connections" reports nothing ready; that action answers "which systems can I use?", it does not gate linking, and skipping the link because nothing looked ready is the one failure this tool exists to prevent.
NEVER INVENT external_id, url or title. Core stores all three without checking them, and nothing corrects them later on this path, so a guessed id produces a finding that links to a ticket which does not exist. Send exactly what the provider returned when the ticket was created; omit title or url if you were not given them. url must name the same ticket as external_id — if you are not sure they agree, send external_id alone.
A SUCCESSFUL LINK MEANS MALLORY RECORDED THE ID, nothing more. It does not mean the ticket was found, read or verified. Report what you linked; do not tell the user it was checked.
One ticket often covers several findings: pass every relevant finding_uuid in a single link call rather than linking one at a time. Finding uuids come from listFindings, getFinding, or a createFinding outcome. ticket_uuid (needed by attach and unlink) is Mallory's OWN uuid for a ticket already registered here — it comes from a link outcome or the list action, and is NOT the external id like "MAL-123". Re-linking the same ticket is safe: core upserts.
Unlinking removes only the association in Mallory; the ticket stays in its own system. PLAN_LIMIT means findings are not included in this tenant's plan — the request was fine, nothing is broken and nothing was written: say so and do not retry.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Link to the ticket in its own system (optional on link). Send it when you have it — it is what the finding page links to. It MUST name the same ticket as external_id: nothing checks that on this path, so a url and an id that disagree are both stored and the finding links somewhere its id does not match. If you are unsure they agree, send only external_id. | |
| title | No | The ticket's title (optional on link). Send the real title the provider gave you when you created the ticket. Do NOT invent one and do NOT guess: nothing enriches it later on this path, so whatever you send is what the finding page shows forever. Omit it if you do not have it. | |
| action | Yes | The operation to perform. Required fields depend on the action: link needs finding_uuids + provider + external_id; attach needs ticket_uuid + finding_uuids; unlink needs ticket_uuid + finding_uuid; list needs finding_uuid; connections takes no other fields. | |
| provider | No | Which ticketing system the ticket lives in (required for link): jira, linear, github or servicenow. | |
| external_id | No | The ticket's id in that system (required for link), e.g. 'MAL-123', 'PROJ-88', or 'owner/repo#42' for GitHub. Use the id the provider returned when the ticket was created. Never guess or construct one: core stores it without checking, so a wrong id produces a finding that links to a ticket which does not exist. | |
| ticket_uuid | No | Mallory's own uuid for a ticket already registered here (required for attach and unlink). This is NOT the external id — get it from a link outcome or from the list action. | |
| finding_uuid | No | A single finding (required for unlink and list). | |
| finding_uuids | No | Findings to associate with the ticket (required for link and attach). One ticket can cover several findings — pass them together rather than calling once each. |