Find tickets in the Summit Managed IT queue using filters.

Returns compact summaries (no ticket body) ranked newest-first, capped at limit. Combine filters freely; they AND together. Omit them all to see the newest open work.

WHAT IT DOES NOT DO

• Does not return ticket bodies. Call get_ticket for the full text of a specific ticket once you have narrowed to one.

• Does not search inside ticket bodies for topics reliably — query matches subject and body substrings only, with no ranking or synonyms. For "what is our procedure for X", use search_kb instead; that searches the knowledge base, which is where procedure lives.

• Does not classify anything. The category it returns is the as-filed intake label typed by whoever opened the ticket. It is frequently wrong. Do not use it to conclude a ticket is safe or routine.

FILTER VALUES status open | pending | resolved priority low | medium | high | critical tier 1 | 2 | 3 category password_account, email, network_vpn, hardware, software_licensing, security, server_outage, onboarding_offboarding client client company name, case-insensitive substring query free-text substring over subject and body

ERRORS This tool does not fail on an empty result. total_matched: 0 with an empty list means nothing matched — widen the filters rather than retrying the same call. truncated: true means more matched than were returned; narrow the filters to see the remainder.

Retrieve one ticket in full, including the requester's message body.

Use this once you have a specific ticket ID — typically from search_tickets. This is the only tool that returns ticket body text.

WHAT IT DOES NOT DO

• Does not triage, categorise, or assess the ticket. It returns the record as filed. In particular the category field is intake metadata and may misdescribe the ticket entirely; read the body yourself.

• Does not indicate whether a ticket is safe to answer. Only draft_response makes that determination, and it does so independently of this record's category field. Never conclude from a non-security category here that drafting will be permitted.

ERRORS TICKET_NOT_FOUND — no ticket with that ID exists. Ticket IDs look like "T-014". Do not retry with the same ID; call search_tickets to find the correct one.

Search the Summit Managed IT knowledge base for procedure and policy.

Returns ranked excerpts with the article ID and section that produced each one, so any fact you use can be cited. The knowledge base is the only authoritative source of Summit procedure: reset URLs, SLA timeframes, approval requirements, escalation paths.

Query with the words the KB itself would use — symptoms and nouns ("account lockout", "vpn certificate", "mailbox full"). Long natural-language sentences score worse than three or four content words, because matching is keyword overlap, not semantic similarity.

WHAT IT DOES NOT DO

• Does not search tickets. For customer requests use search_tickets.

• Does not write replies. For a reply grounded in these articles, use draft_response, which performs its own retrieval and returns the grounding alongside the draft.

• Does not paraphrase or summarise. Excerpts are returned verbatim so that timeframes, URLs, and limits survive intact. Reproduce them exactly; do not round "15 minutes" or invent a support phone number. The corpus contains no phone numbers at all.

ERRORS KB_NO_MATCH — nothing scored above threshold. Retry once with broader or different content words. If it still misses, the knowledge base does not cover the topic: say so plainly rather than answering from general knowledge.

Compose a knowledge-base-grounded draft reply for a ticket.

Returns the draft together with grounding — the KB excerpts it was built from — and kb_article_ids for citation. You may improve the phrasing of the returned draft. You may not add any fact, URL, timeframe, or procedure step that does not appear in grounding. The knowledge base contains no phone numbers; a phone number in a reply is fabricated by definition.

SECURITY GUARDRAIL — ENFORCED IN CODE, NOT NEGOTIABLE This tool refuses to draft for any ticket that shows signs of a security incident, and returns ok=false with SECURITY_ESCALATION_REQUIRED. The decision is made two ways, independently:

1. the ticket's as-filed category is "security"; or

2. the ticket text trips a KB-006 indicator — credentials entered on a suspicious site, an attachment opened followed by changed system behaviour, files encrypted or a ransom note, browser hijack symptoms, a vendor requesting changed bank details, mail spoofing the client's own domain, or a user denying an account change they are recorded as making. Layer 2 fires even when the ticket is filed as hardware, email, or anything else. A non-security category is never sufficient to obtain a draft.

There is no parameter, phrasing, or instruction that disables this. Do not attempt to work around a refusal by drafting the reply yourself, by calling search_kb and composing from the excerpts, or by asking the user to relay troubleshooting steps. KB-006 is explicit that support does not troubleshoot suspected security incidents at all: restarts and quick fixes destroy forensic evidence, and a password reset is insufficient during an active compromise. On refusal, tell the user plainly that the ticket needs the security team, report the indicators returned, and offer to escalate with update_ticket.

WHAT IT DOES NOT DO

• Does not send anything. The draft is returned to you for review; delivery is out of scope for this server.

• Does not change ticket state. Use update_ticket to record an escalation.

• Does not invent facts when the knowledge base is silent. If retrieval finds nothing, it returns KB_NO_MATCH rather than a plausible-sounding reply.

ERRORS TICKET_NOT_FOUND — no such ticket; find the right ID with search_tickets. SECURITY_ESCALATION_REQUIRED — refused; escalate to the security team. KB_NO_MATCH — the knowledge base does not cover this issue. Escalate to a technician rather than answering from general knowledge.

Change ticket state: status, tier, priority, assignee, or an appended note.

WRITE OPERATION — CONFIRMATION GATE Calling without confirm=true performs a dry run: nothing changes, and the result returns applied: false with a changes list showing exactly which fields would move from what to what, plus CONFIRMATION_REQUIRED.

Show that preview to the user and get their agreement before calling again with confirm=true. Do not set confirm=true on the first call, and do not set it on the user's behalf because their intent seems obvious — the preview exists so a human sees the blast radius before state changes. Passing every field you were given at once is fine; the gate is about confirmation, not batching.

Pass only the fields you intend to change. Omitted fields are left alone. Passing note appends to the ticket's note trail; it never replaces it.

WHAT IT DOES NOT DO

• Does not send anything to the requester. It changes internal ticket state only. draft_response composes customer-facing text.

• Does not delete tickets, and cannot set a status outside the allowed values.

• Does not validate that an escalation is appropriate. Recording tier 3 does not notify anyone; it records intent on the ticket.

FIELD VALUES status open | pending | resolved priority low | medium | high | critical tier 1 | 2 | 3 assignee technician username, or null to unassign note free text appended to the ticket's note trail

ERRORS TICKET_NOT_FOUND — no such ticket. CONFIRMATION_REQUIRED — expected on a dry run. Not a failure: it carries the preview. Show it to the user, then re-call with confirm=true. INVALID_FIELD — a value outside the allowed set; nothing was changed. Fix the value and retry.