MCP Request Tracker CrunchTools
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| RT_URL | Yes | Base URL of your RT server | |
| RT_PASS | Yes | RT password | |
| RT_USER | Yes | RT username | |
| RT_HTTP_PASS | No | HTTP Basic Auth password | |
| RT_HTTP_USER | No | HTTP Basic Auth username |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tasks | {
"list": {},
"cancel": {},
"requests": {
"tools": {
"call": {}
},
"prompts": {
"get": {}
},
"resources": {
"read": {}
}
}
} |
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_tickets_toolB | Search for tickets using RT query syntax. Args: query: RT query string (e.g., "Status = 'new'", "Subject LIKE 'checklist'", "Owner = 'scott'", "Queue = 'Professional'") order_by: Field to order by, prefix with - for descending (default: -Created) Returns: List of matching tickets with ID and Subject |
| get_ticket_toolB | Get details of a specific ticket. Args: ticket_id: The ticket ID number Returns: Ticket details including status, owner, subject, times, etc. |
| get_ticket_history_toolB | Get the history/changelog of a ticket. Args: ticket_id: The ticket ID number Returns: Transaction history showing all changes made to the ticket |
| get_my_open_tickets_toolB | Get all open tickets assigned to a user. Args: owner: Username to search for Returns: List of open tickets owned by the user |
| get_new_tickets_toolA | Get all new (unassigned) tickets, optionally filtered by queue. Args: queue: Optional queue name to filter by Returns: List of new tickets |
| set_ticket_owner_toolB | Set the owner of a ticket (take/assign ticket). Args: ticket_id: The ticket ID number owner: Username of the new owner Returns: Confirmation message |
| set_ticket_status_toolB | Set the status of a ticket. Args: ticket_id: The ticket ID number status: New status (e.g., 'new', 'open', 'stalled', 'resolved', 'rejected', 'deleted') Returns: Confirmation message |
| update_ticket_toolB | Update ticket fields (subject, priority, queue). All fields are optional. Args: ticket_id: The ticket ID number subject: New subject/title for the ticket priority: New priority (0-99) queue: New queue name (e.g., 'General', 'Professional') Returns: Confirmation of updated fields |
| resolve_ticket_toolA | Resolve/close a ticket, optionally adding a comment. Args: ticket_id: The ticket ID number comment: Optional comment to add before resolving Returns: Confirmation message |
| open_ticket_toolA | Open a ticket (change status from new to open), optionally taking ownership. Args: ticket_id: The ticket ID number owner: Optional username to assign as owner Returns: Confirmation message |
| take_ticket_toolC | Take ownership of a ticket and open it. Args: ticket_id: The ticket ID number username: Your username Returns: Confirmation message |
| set_time_worked_toolB | Set the total time worked on a ticket. Args: ticket_id: The ticket ID number minutes: Total time worked in minutes Returns: Confirmation message |
| add_time_worked_toolA | Add time to the time worked on a ticket. Args: ticket_id: The ticket ID number minutes: Additional time to add in minutes Returns: Confirmation message with new total |
| add_ticket_comment_toolA | Add a private comment/note to a ticket (not visible to requestor). Args: ticket_id: The ticket ID number comment: The comment text Returns: Confirmation message |
| reply_to_ticket_toolA | Reply to a ticket (correspondence visible to requestor). Args: ticket_id: The ticket ID number message: The reply message Returns: Confirmation message |
| create_ticket_toolA | Create a new ticket. Args: queue: Queue name (e.g., 'General', 'Professional') subject: Ticket subject/title text: Initial ticket content/description requestor: Email of the requestor owner: Username to assign as owner priority: Ticket priority (0-99) Returns: Created ticket ID and confirmation |
| complete_weekly_checklist_toolA | Complete a weekly checklist ticket with results. This is a workflow shortcut that:
Args: ticket_id: The ticket ID number owner: Username taking the ticket checklist_results: The checklist completion results time_minutes: Time spent on checklist (optional) Returns: Confirmation of all actions taken |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 17 tools
Several tools have overlapping purposes: set_ticket_status_tool overlaps with open_ticket_tool and resolve_ticket_tool, while set_ticket_owner_tool overlaps with take_ticket_tool. get_my_open_tickets_tool and get_new_tickets_tool also largely duplicate functionality available through search_tickets_tool. The descriptions help somewhat, but the boundaries between general tools and workflow shortcuts are unclear.
Tool names consistently use snake_case with a verb-first pattern and a _tool suffix (e.g., get_ticket_tool, set_ticket_status_tool). Minor deviations like reply_to_ticket_tool and complete_weekly_checklist_tool introduce prepositions or workflow-specific phrasing, but the overall pattern remains predictable.
17 tools is on the heavy side for this domain, especially given the functional overlap between several tools. A ticketing system can reasonably support this many operations, but some tools (take_ticket_tool, open_ticket_tool, resolve_ticket_tool) could be consolidated without losing much capability.
The core ticket lifecycle is well covered: create, search, get details/history, update fields, manage owner/status, comment/reply, track time, and resolve. Minor gaps exist, such as no explicit attachment handling, queue management, or dedicated ticket deletion, but status can be set to deleted and most workflows are supported.