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.