Request Tracker (RT)

@rt list all open tickets in the Infrastructure queue assigned to me and summarize them by priority

Querying the Infrastructure queue returned 7 open tickets assigned to your RT user. High priority: 2 tickets (network outage in DC2, expired SSL cert on api.example.com). Normal priority: 4 tickets (routine patching requests, backup verification). Low priority: 1 ticket (documentation update for firewall rules). All tickets are within SLA windows. The network outage ticket (#47293) was created 3 hours ago and has 4 comments from the ops team.

This example combines list-and-filter with AI synthesis. The MCP fetches ticket metadata; the AI groups by priority and highlights urgency. Requires read permission on the Infrastructure queue. RT's search syntax and field visibility depend on your instance's custom-field configuration and user rights.

@rt create a ticket in the Security queue: 'Rotate API keys for payment gateway' with priority High and requestor ops@example.com

Created ticket #48012 in the Security queue. Subject: 'Rotate API keys for payment gateway'. Priority: High. Requestor: ops@example.com. Status: new. Owner: Nobody. RT scrips ran on creation: the Security team's auto-watch rule added three staff members as AdminCc, and ops@example.com received a confirmation email. The ticket is now visible in the Security queue dashboard.

Demonstrates ticket creation with side-effects. RT scrips (server-side automation rules) may send email, set owners, or add watchers immediately. These side-effects are durable and cannot be undone via REST2. Confirm your RT instance's scrip behavior before bulk creation. Requires CreateTicket right in the Security queue.

@rt pull the full history for ticket #47293 and draft a status update email for the requestor explaining what we've done so far

Ticket #47293 history shows 6 transactions: initial report (network timeout in DC2), ops team comment confirming the affected subnet, a priority bump to High, two internal comments detailing failover steps, and a correspondence sent to the network vendor. Draft email: 'We've isolated the issue to a routing loop in DC2's core switch. Our team failed over traffic to the backup path within 20 minutes. We've escalated to the vendor and expect a firmware patch by EOD. Will update you when connectivity is fully restored.' This draft references the internal failover comments without exposing private notes.

Showcases history retrieval paired with AI summarization. The MCP returns raw transaction data (comments, correspondence, field changes); the AI synthesizes a customer-facing update. Be aware that RT history can include private comments—review the draft before sending. Requires ShowTicket right and possibly SeeQueue for full context.

When RT beats modern ticketing for internal support teams

A 20-person company runs Request Tracker for IT helpdesk and facilities requests. The ops team uses Switchy to triage the morning queue: an agent pulls tickets with Get Queue and List Queues, reads history with Get Ticket History to see what the last tech tried, then adds internal notes with Add Ticket Comment before reassigning. RT's strength here is the durable transaction log—every comment and field change persists even if someone fat-fingers a bulk edit. The API_KEY auth means the whole team shares one service account, so you lose individual attribution in Switchy's activity feed. If your team needs per-user audit trails or you're fielding external customer support at scale, RT's 2000s-era threading will frustrate you. But for small internal ops teams who value append-only history over modern UX, this MCP gives you read-write ticket control without leaving the AI workspace.

RT for academic support teams with complex routing

A university research computing group handles 40 tickets a week across three queues: account requests, cluster issues, and software installs. The support lead uses Switchy to scan queues each morning with List Queues, then drills into high-priority tickets with Get Ticket and Get Ticket History to understand context before replying. RT's lifecycle and scrip system—visible through Get Queue—lets the team enforce approval workflows that modern SaaS tools charge enterprise money for. The MCP's Reply to Ticket tool respects RT's email notification rules, so replies trigger the right faculty or grad student without manual CC lists. The catch: RT's search is weak, so if you need to find 'all tickets mentioning CUDA in the last six months,' you'll script that outside Switchy. This setup works when your ticket volume stays under 200/month and your routing logic lives in RT scrips, not a separate automation layer.

When RT's multi-queue model fits managed service providers

A 12-person managed service provider tracks client incidents in Request Tracker, one queue per client. The on-call engineer uses Switchy to check overnight tickets: List Queues shows the 8 active client queues, Get Ticket pulls the new incidents, and Add Ticket Comment logs the initial diagnosis before escalating. RT's queue-per-client model keeps data isolated without paying per-seat SaaS fees, and the durable transaction history satisfies compliance audits. The MCP's List Ticket Attachments tool lets the engineer confirm a client uploaded logs before downloading them outside Switchy. The boundary: if you're coordinating across 30+ clients or need real-time SLA dashboards, RT's reporting is too manual and the single API_KEY means you can't track which engineer touched which ticket in Switchy's logs. But for small MSPs with under 15 clients and predictable ticket flow, this MCP turns RT into a usable AI-assisted triage surface.