Loading ToolBench
MCP server for RT (Request Tracker) REST2 API - provides read-only access to tickets, correspondence, and attachments
RT MCP Server provides read-only access to Request Tracker tickets with 6 well-defined tools. All tools have names following the verb_noun pattern (search_, get_), detailed descriptions, and proper JSON Schema input definitions. However, several tools lack comprehensive parameter descriptions, and output schemas are not formally documented. Parameter descriptions vary significantly in quality and completeness. The server is well-structured for its READ_ONLY scope but has gaps in description depth and output documentation that would be expected of A-grade production tools.
Download a specific attachment by ID. Returns base64-encoded content with metadata for any file type.
Get complete ticket information by ticket ID, including subject, status, queue, owner, dates, priority, and custom fields.
Get ticket correspondence (comments and replies with attachments). Retrieves all correspondence entries grouped by transaction, showing inline text messages and file attachment metadata.
Get ticket hierarchy (parent/child relationships). Builds the complete hierarchy tree if recursive=true, or only immediate relationships if recursive=false.
Get the TicketSQL query language reference (fields, operators, date literals, and examples) used by the search_tickets `query` parameter. Call this when constructing non-trivial searches.
Output schemas not documented: No formal JSON Schema definitions provided for tool return types. LLMs cannot plan downstream operations without knowing what fields each tool returns (e.g., does search_tickets return ticket_id, subject, status for each result? What is the pagination structure?). Current code lacks explicit return type documentation.
Inconsistent parameter description quality: 'get_attachment' has minimal parameter docs ('The RT attachment ID number'), while 'search_tickets' has extensive multi-line examples in the description. Some tools lack clear guidance on valid value ranges, formats, or dependencies (e.g., does 'subfields' parameter have constraints on nesting depth?).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Search for tickets using RT's TicketSQL query language. Returns summary information for matching tickets, with optional sorting and pagination. The `query` is TicketSQL (NOT free-text keyword search). Examples: - My last 10 tickets: query="Owner = '__CurrentUser__'", orderby="Created", order="DESC", per_page=10 - Last 10 tickets created: query="id > 0", orderby="id", order="DESC", per_page=10 - Created after a date: query="Created > '2026-06-01'" - By requestor: query="Requestor = 'jsmith'" (also Cc, AdminCc, Watcher, Owner). User fields match RT usernames, NOT email addresses — use e.g. Requestor.EmailAddress = '[email protected]' to filter by email. - ID range: query="id > 261000 AND id < 261700" - Combined: query="Queue = 'Support' AND Status = 'open' AND LastUpdated > '7 days ago'" Call the get_ticketsql_grammar tool for the full TicketSQL field/operator reference.
No error handling guidance in tool descriptions: Tools lack statements about what errors can occur and how to recover. E.g., 'get_ticket' does not document 'Ticket not found' scenarios or suggest remediation (try search_tickets). Pattern:recovery-guide missing.
Missing constraint documentation on numeric parameters: 'page' and 'per_page' in search_tickets have defaults and a stated max (per_page=100) but no minimum documented. 'page' number boundaries are unclear (is page 0 valid? What if page > total_pages?).
No pagination limit enforcement guidance: search_tickets returns potentially unbounded results. Rubric baseline requires cap at 20-50 items and explicit statement in tool description. Current description does not warn about context explosion or recommend breaking large searches into paginated calls.