Skip to main content
Glama
msekoranja

RT MCP Server

by msekoranja
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

RT MCP Server

A TypeScript MCP server that provides read-only access to RT (Request Tracker) via the REST2 API. This Model Context Protocol (MCP) server allows Large Language Models to search for tickets, query ticket information, retrieve correspondence, download attachments, and explore ticket hierarchies.

Note: The maintained implementation is the TypeScript server in src/ (published to npm and packaged as MCPB). The python/ directory contains an earlier Python (FastMCP) prototype that is outdated and unmaintained — it lacks TicketSQL search, the get_ticketsql_grammar tool, and attachment-list pagination, and is excluded from the npm package.

Features

  • Read-only access to RT tickets, correspondence, and attachments

  • Token-based authentication via RT REST2 API

  • Command-line & environment variable configuration

  • Six main tools:

    • search_tickets - Search for tickets using RT's TicketSQL query language, with sorting and pagination

    • get_ticketsql_grammar - Get the TicketSQL field/operator reference for building queries

    • get_ticket - Retrieve complete ticket information

    • get_ticket_correspondence - Get ticket correspondence grouped by transaction with inline text and file metadata

    • get_attachment - Download any attachment by ID with base64-encoded content

    • get_ticket_hierarchy - Build ticket parent/child relationship trees

  • STDIO transport for seamless integration with MCP clients

  • TypeScript for type safety and better developer experience

  • Easy deployment with npm/npx

Related MCP server: jama-mcp-server

Installation

Requirements

  • Node.js ≥ v18.0.0

  • RT authentication token (create via Settings > Auth Tokens in RT web interface)

MCP Clients

Using the Plugin (Recommended)

The plugin/ directory of this repository is a self-contained Claude Code plugin: the MCP server is bundled into a single dependency-free script (plugin/rt-mcp.cjs) that runs directly with node — no npm/npx download at runtime. The repository also doubles as its own plugin marketplace:

/plugin marketplace add msekoranja/rt-mcp
/plugin install rt@rt-mcp

The plugin reads your RT authentication token from the RT_API_TOKEN environment variable; set it in your shell profile. The RT server URL is set via the --url argument in plugin/.claude-plugin/plugin.json — edit it to point at your RT instance.

If the plugin is distributed through another marketplace (e.g. an organization-internal one), install it from there instead: /plugin install rt@<marketplace-name>.

After changing the TypeScript sources, regenerate the plugin bundle with npm run bundle.

Using Command Line

macOS/Linux:

claude mcp add rt -- npx -y rt-mcp-server --api-token YOUR_RT_TOKEN --url https://rt.example.com/REST/2.0

Windows:

claude mcp add rt -- cmd /c npx -y rt-mcp-server --api-token YOUR_RT_TOKEN --url https://rt.example.com/REST/2.0

Manual Configuration

Edit your Claude Code MCP configuration file and add:

{
  "mcpServers": {
    "rt": {
      "command": "npx",
      "args": [
        "-y",
        "rt-mcp-server",
        "--api-token",
        "YOUR_RT_TOKEN",
        "--url",
        "https://rt.example.com/REST/2.0"
      ]
    }
  }
}

Option 1: UI Method

  1. Open Claude Desktop

  2. Navigate to Settings → Developer → Edit Config

  3. Add the RT MCP server configuration

Option 2: Configuration File

Edit claude_desktop_config.json (location varies by OS):

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

  • Linux: ~/.config/Claude/claude_desktop_config.json

macOS/Linux configuration:

{
  "mcpServers": {
    "rt": {
      "command": "npx",
      "args": [
        "-y",
        "rt-mcp-server",
        "--api-token",
        "YOUR_RT_TOKEN",
        "--url",
        "https://rt.example.com/REST/2.0"
      ]
    }
  }
}

Windows configuration:

{
  "mcpServers": {
    "rt": {
      "command": "cmd",
      "args": [
        "/c",
        "npx",
        "-y",
        "rt-mcp-server",
        "--api-token",
        "YOUR_RT_TOKEN",
        "--url",
        "https://rt.example.com/REST/2.0"
      ]
    }
  }
}

Restart Claude Desktop after saving.

Using Command Line (Recommended)

gemini mcp add rt npx -y rt-mcp-server --api-token YOUR_RT_TOKEN --url https://rt.example.com/REST/2.0

Manual Configuration

Edit the Gemini settings file at ~/.gemini/settings.json and add the RT MCP server to the mcpServers object:

{
  "mcpServers": {
    "rt": {
      "command": "npx",
      "args": [
        "-y",
        "rt-mcp-server",
        "--api-token",
        "YOUR_RT_TOKEN",
        "--url",
        "https://rt.example.com/REST/2.0"
      ]
    }
  }
}

Using Command Line (Recommended)

codex mcp add rt npx -y rt-mcp-server --api-token YOUR_RT_TOKEN --url https://rt.example.com/REST/2.0

Manual Configuration

Add the RT MCP server to your OpenAI Codex configuration using TOML format:

[mcp_servers.rt]
command = "npx"
args = [
  "-y",
  "rt-mcp-server",
  "--api-token",
  "YOUR_RT_TOKEN",
  "--url",
  "https://rt.example.com/REST/2.0"
]

Use the MCP toolkit to integrate RT:

from langchain_mcp import MCPToolkit

rt_toolkit = MCPToolkit(
    server_params={
        "command": "npx",
        "args": [
            "-y",
            "rt-mcp-server",
            "--api-token",
            "YOUR_RT_TOKEN",
            "--url",
            "https://rt.example.com/REST/2.0"
        ]
    }
)

tools = rt_toolkit.get_tools()

Local Development Installation

If you want to develop or modify the server:

# Clone the repository
git clone <repository-url>
cd rt-mcp

# Install dependencies
npm install

# Build the project
npm run build

# Test it
node dist/index.js --api-token "YOUR_RT_TOKEN" --url "https://rt.example.com/REST/2.0"

Configuration

The server supports configuration via command-line arguments or environment variables.

Command-Line Arguments (Recommended)

  • --api-token - Your RT authentication token

  • --url - RT server base URL (required)

Environment Variables (Alternative)

  • RT_TOKEN - Your RT authentication token

  • RT_BASE_URL - RT server base URL

Priority: Command-line arguments override environment variables.

Usage with MCP Clients

After installing the RT MCP server in your preferred MCP client (see Installation section above), you can interact with RT tickets using natural language.

Usage Examples

Example 1: Searching for Tickets

Ask your MCP-enabled LLM:

"Show me my last 10 tickets"

The LLM will use search_tickets(query="Owner = '__CurrentUser__'", orderby="Created", order="DESC", per_page=10) to find your most recent tickets and display a summary of results. Queries use RT's TicketSQL language (e.g. Created > '2026-06-01' AND Owner = 'jsmith'); usernames follow the jsmith pattern, and __CurrentUser__ resolves to the authenticated token's user.

Example 2: Checking Ticket Status

Ask your MCP-enabled LLM:

"What is the status of RT ticket 12345?"

The LLM will use get_ticket(12345) to fetch the ticket details and report the status, owner, priority, and other relevant information.

Example 3: Reading Ticket Correspondence

Ask your MCP-enabled LLM:

"Show me all the comments and correspondence from RT ticket 67890"

The LLM will use get_ticket_correspondence(67890) to retrieve all correspondence grouped by transaction, including inline text messages and file attachment metadata.

Example 4: Downloading Attachments

Ask your MCP-enabled LLM:

"Download the PDF receipt from RT ticket 67890"

The LLM will use get_ticket_correspondence(67890) to find attachment IDs, then get_attachment(attachment_id) to download the specific file with base64-encoded content.

Example 5: Exploring Ticket Hierarchies

Ask your MCP-enabled LLM:

"Show me the parent and child tickets for RT ticket 54321"

The LLM will use get_ticket_hierarchy(54321, recursive=True) to build the complete relationship tree showing all related tickets.

Available Tools

search_tickets(query, orderby?, order?, per_page?, page?, fields?, subfields?)

Searches for tickets using RT's TicketSQL query language, with optional sorting and pagination.

Breaking change (since simple-search removal): query is now TicketSQL, not free-text. A keyword search like "database error" must be written as Subject LIKE 'database error' (or use Content LIKE '...'). Call get_ticketsql_grammar for the full syntax.

Parameters:

  • query - TicketSQL query string (e.g., "Created > '2026-06-01' AND Owner = 'jsmith'"). Use "id > 0" to match all tickets.

  • orderby - Field to sort by. One of: id, Created, LastUpdated, Started, Resolved, Due, Told, Priority, Subject, Status, Queue, Owner.

  • order - ASC or DESC (defaults to DESC when orderby is set).

  • per_page - Results per page (default 20, max 100).

  • page - Page number (default 1).

  • fields - Comma-separated list of extra fields to include (e.g., "Priority,Requestor").

  • subfields - Expand nested objects inline, e.g. {"Owner":"Name,EmailAddress","Queue":"Name"}.

Example (my last 10 tickets):

{
  "query": "Owner = '__CurrentUser__'",
  "orderby": "Created",
  "order": "DESC",
  "per_page": 10
}

Returns:

{
  "total": 45,
  "count": 10,
  "per_page": 10,
  "page": 1,
  "tickets": [
    {
      "id": 261687,
      "subject": "Database connection error on production",
      "status": "open",
      "queue": "Engineering",
      "owner": "jsmith",
      "created": "2026-06-29T10:30:00Z"
    }
  ]
}

get_ticketsql_grammar()

Returns the TicketSQL query language reference (fields, operators, date literals, and examples) for building search_tickets queries. Takes no parameters.

get_ticket(ticket_id: number)

Retrieves complete ticket information including:

  • Basic info: ID, type, subject, status, queue

  • People: owner, creator, requestors, CC, AdminCC

  • Dates: created, started, resolved, last updated

  • Time tracking: worked, estimated, left

Example:

{
  "ticket_id": 12345
}

Returns:

{
  "id": 12345,
  "subject": "Example ticket",
  "status": "open",
  "queue": "General",
  "owner": "username",
  "creator": "requester@example.com",
  "created": "2024-01-15T10:30:00Z"
}

get_ticket_correspondence(ticket_id: number)

Retrieves all correspondence from a ticket, grouped by transaction. Each transaction may contain:

  • Inline text messages (user's typed message)

  • File attachments (with metadata only)

Example:

{
  "ticket_id": 12345
}

Returns:

{
  "ticket_id": 12345,
  "total_attachments": 5,
  "correspondence": [
    {
      "transaction_id": "100",
      "creator": "jsmith",
      "created": "2024-01-15T10:35:00Z",
      "message": "This is the user's typed message...",
      "attachments": [
        {
          "id": 67890,
          "filename": "document.pdf",
          "content_type": "application/pdf",
          "size": "42.0 KB"
        }
      ]
    }
  ]
}

get_attachment(attachment_id: number)

Downloads a specific attachment by ID, returning base64-encoded content for any file type.

Example:

{
  "attachment_id": 67890
}

Returns:

{
  "attachment_id": 67890,
  "filename": "document.pdf",
  "content_type": "application/pdf",
  "size": "42.0 KB",
  "content_base64": "JVBERi0xLjQK...",
  "created": "2024-01-15T10:35:00Z",
  "creator": "jsmith"
}

get_ticket_hierarchy(ticket_id: number, recursive?: boolean)

Retrieves the parent/child relationship tree for a ticket.

Parameters:

  • ticket_id - The RT ticket ID

  • recursive - If true, fetches complete tree; if false, only immediate relationships (default: true)

Example:

{
  "ticket_id": 12345,
  "recursive": true
}

Returns:

{
  "ticket_id": 12345,
  "recursive": true,
  "tickets_fetched": 10,
  "hierarchy": {
    "id": 12345,
    "subject": "Main ticket",
    "status": "open",
    "parents": {
      "12340": {
        "id": 12340,
        "subject": "Parent ticket"
      }
    },
    "children": {
      "12350": {
        "id": 12350,
        "subject": "Child ticket"
      }
    }
  }
}

How It Works

  1. Configuration: Parses command-line arguments (or reads environment variables) for RT URL and authentication token

  2. Authentication: Uses token-based auth with RT REST2 API for all requests

  3. HTTP Client: Uses native fetch API for async HTTP requests to RT REST2 API

  4. Error Handling: Returns error information as objects rather than throwing exceptions

  5. MCP Protocol: Implements MCP server using @modelcontextprotocol/sdk with STDIO transport

  6. Type Safety: Full TypeScript type checking for reliability

API Endpoints Used

The server interacts with these RT REST2 endpoints:

  • GET /tickets?query={ticketsql}&orderby={field}&order={ASC|DESC}&per_page={n}&page={n}&fields={...} - Search tickets using TicketSQL

  • GET /ticket/{id} - Retrieve ticket information

  • GET /ticket/{id}/attachments - List all attachments for a ticket

  • GET /attachment/{id} - Retrieve individual attachment content (base64-encoded)

Documentation

Development

Building

# Install dependencies
npm install

# Build TypeScript to JavaScript
npm run build

# Watch mode (auto-rebuild on changes)
npm run dev

Project Structure

rt-mcp/
├── src/
│   └── index.ts          # Main MCP server implementation
├── dist/                 # Compiled JavaScript (generated)
├── .claude-plugin/
│   └── marketplace.json  # Plugin marketplace catalog (repo is its own marketplace)
├── plugin/               # Claude Code plugin (self-contained)
│   ├── .claude-plugin/
│   │   └── plugin.json   # Plugin manifest
│   ├── rt-mcp.cjs        # Bundled MCP server (generated by `npm run bundle`, intentionally committed)
│   └── README.md         # Plugin documentation
├── package.json          # Node.js dependencies and scripts
├── tsconfig.json         # TypeScript configuration
├── .gitignore            # Git ignore rules
├── README.md             # This file
└── CLAUDE.md             # Guide for Claude Code

Running Tests

# Run the built server with test credentials
node dist/index.js --api-token "test-token" --url "https://rt.example.com/REST/2.0"

Common Workflows

Reading Ticket Information

Simply ask Claude in natural language:

  • "What's the status of RT ticket 12345?"

  • "Who is assigned to ticket 67890?"

  • "When was ticket 11111 created and last updated?"

  • "Show me the custom fields for ticket 22222"

Analyzing Ticket Discussions

Ask Claude to summarize or analyze:

  • "Read all comments from RT ticket 33333 and summarize the issue"

  • "What are the main discussion points in ticket 44444?"

  • "Extract action items from the conversation in ticket 55555"

  • "Translate the technical discussion in ticket 66666 to non-technical language"

Batch Operations

Ask Claude to process multiple tickets:

  • "Compare the status of tickets 100, 101, and 102"

  • "Show me a table of ticket 200, 201, 202 with status, owner, and priority"

  • "Check if any of tickets 300-305 mention the word 'urgent' in their attachments"

Limitations

  • Read-only: No ticket creation, updates, or deletion capabilities

  • TicketSQL only: Search uses RT's TicketSQL language (no free-text keyword mode); use get_ticketsql_grammar for syntax

  • Single sort field: orderby accepts one field at a time (no multi-field sorting)

  • No transaction history: Does not expose complete ticket history/transactions (only correspondence)

  • Single ticket at a time: Each tool call fetches one ticket (LLM can call multiple times for batch operations)

  • File size: Large attachments may take time to download depending on RT server performance

  • Search result limit: Maximum 100 tickets per page (RT API limitation); use page to paginate

Troubleshooting

Module Not Found Error

If you see module errors during build:

# Make sure dependencies are installed
npm install
# Rebuild the project
npm run build

Authentication Errors

If you see HTTP 401 or 403 errors:

  • Verify your RT token is correct

  • Check the token hasn't expired

  • Ensure your RT user has permissions to access tickets

  • Verify the RT server URL is correct

Connection Errors

If you see connection timeout or refused errors:

  • Check the RT server URL (should include /REST/2.0)

  • Verify the server is accessible from your network

  • Ensure HTTPS is being used

TypeScript Build Errors

If you encounter TypeScript compilation errors:

  • Check that you're using Node.js ≥18.0.0

  • Ensure all dependencies are installed: npm install

  • Try cleaning and rebuilding: npm run clean && npm run build

Security Notes

  • Store RT_TOKEN securely (environment variables, secrets manager, etc.)

  • Never commit tokens to version control (.gitignore excludes token.txt and .env files)

  • The server will fail fast if RT_TOKEN is not provided

  • All communication with RT should use HTTPS

  • Command-line tokens may be visible in process lists - prefer environment variables in production

Contributing

When extending this server:

  • Follow TypeScript best practices

  • Use async/await pattern consistently

  • Return error objects instead of throwing exceptions

  • Update tool schemas for new functionality

  • Test with actual RT instance before committing

  • Run npm run build after making changes

Available Tools

6 tools
get_attachmentA

Download a specific attachment by ID. Returns base64-encoded content with metadata for any file type.

ParametersJSON Schema
NameRequiredDescriptionDefault
attachment_idYesThe RT attachment ID number

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries the full burden. It discloses the return format (base64-encoded content with metadata) and that it works for any file type, but does not mention side effects, error handling, or safety profile. The download verb implies read-only, but this is not explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with the main purpose, then the return behavior. No redundant words or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description adequately communicates purpose and return format. It omits error details, but these are not critical for a straightforward download tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the parameter `attachment_id` is clearly described as 'The RT attachment ID number'. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Download a specific attachment by ID', using a specific verb and resource. This distinguishes it from sibling tools which focus on tickets, not attachments.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (when you have an attachment ID) but does not explicitly mention alternatives or exclusions. Siblings are clearly different, but no direct guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_ticketA

Get complete ticket information by ticket ID, including subject, status, queue, owner, dates, priority, and custom fields.

ParametersJSON Schema
NameRequiredDescriptionDefault
ticket_idYesThe RT ticket ID number

TDQS

A3.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses a read-only operation by nature ('Get') and lists returned fields, but does not mention edge cases such as errors, authentication requirements, rate limits, or response format. This is minimal for a read tool, but lacks explicit behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that states the action, resource, and a summary of contents. It is concise, well-structured, and contains no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With one required parameter and no output schema, the description sufficiently outlines the return value fields. It uses 'including' to signal the list may not be exhaustive, but for a focused tool it provides adequate context without needing more.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers the single parameter 'ticket_id' with a clear description ('The RT ticket ID number'), achieving 100% coverage. The tool description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and resource ('complete ticket information') with a clear parameter ('by ticket ID'). It lists key attributes (subject, status, queue, owner, dates, priority, custom fields), which differentiates it from sibling tools like search_tickets or get_ticket_correspondence.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when a specific ticket ID is known and full details are needed, but it does not explicitly compare against alternatives or state when not to use it. There are no exclusions or alternative tool references.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_ticket_correspondenceA

Get ticket correspondence (comments and replies with attachments). Retrieves all correspondence entries grouped by transaction, showing inline text messages and file attachment metadata.

ParametersJSON Schema
NameRequiredDescriptionDefault
ticket_idYesThe RT ticket ID number

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses behavioral details: retrieves all correspondence entries, groups by transaction, shows inline text messages and file attachment metadata. This goes beyond a generic 'get' verb, though it does not cover edge cases like empty results or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core purpose, and no wasted words. The parenthetical and follow-up sentence clarify scope and contents efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter read-only tool with no output schema, the description sufficiently conveys what is returned and how it is organized. It could mention pagination/ordering, but is not incomplete for the tool's apparent simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides 100% description coverage for the single ticked_id parameter ('The RT ticket ID number'). The description does not add detail beyond what the schema already states, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves ticket correspondence including comments, replies, and attachment metadata. It distinguishes itself from sibling tools like get_ticket and get_attachment by specifying grouped-by-transaction structure and inline text vs. attachment metadata.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. While it is clear the tool retrieves correspondence, there is no mention of when-not-to-use it or comparison to siblings like get_attachment for individual files, or get_ticket for the main ticket record.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_ticket_hierarchyA

Get ticket hierarchy (parent/child relationships). Builds the complete hierarchy tree if recursive=true, or only immediate relationships if recursive=false.

ParametersJSON Schema
NameRequiredDescriptionDefault
recursiveNoWhether to recursively fetch the entire hierarchy tree (default: true)
ticket_idYesThe RT ticket ID number

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of exposing behavior. It discloses the key behavioral trait of recursive versus immediate relationships, which is valuable. However, it does not describe the output format or structure, error conditions, or any side effects, leaving gaps in transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the primary purpose, and every word earns its place. It is concise and well-structured, with no redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with two parameters and no output schema, the description is mostly complete. It explains the core behavior and the recursive flag. However, it could be more complete by describing the expected return structure (e.g., a tree representation) to fully set agent expectations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond what the schema already provides for the recursive and ticket_id parameters. It does not clarify types, defaults, or constraints beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets ticket hierarchy, explicitly mentioning parent/child relationships, and differentiates it from sibling tools like get_ticket or get_ticket_correspondence. The verb 'Get' and resource 'ticket hierarchy' are specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the recursive parameter behavior but does not explicitly state when to use this tool versus alternatives or provide exclusions. Usage is implied (when you need hierarchy), but no explicit guidance or sibling distinctions are given beyond the tool's own description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_ticketsql_grammarA

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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description correctly conveys a read-only operation that returns a reference. It doesn't disclose any side effects or unexpected behaviors, but the tool is inherently simple and the description covers its main function. A slight extra detail on return format would elevate it, but it's adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, with the first stating the tool's function and content, and the second providing usage guidance. Every word earns its place; no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given it's a simple reference-lookup tool with no parameters, no output schema, and no annotations, the description fully covers what an agent needs to know: what it returns, how it relates to search_tickets, and when to call it. There are no gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the schema imposes no burden. The description focuses on the purpose rather than parameter details, which is appropriate. The baseline for zero parameters is 4, and nothing here reduces that.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns the TicketSQL query language reference, specifying the content (fields, operators, date literals, and examples) and its relationship to the search_tickets query parameter. This isolates it from sibling tools like get_ticket or search_tickets, making its purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly instructs when to use this tool ('Call this when constructing non-trivial searches'), tying it to the search_tickets parameter. While it doesn't discuss when not to use it or name alternatives, the context is clear enough for an agent to decide.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_ticketsA

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)

  • 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNoPage number to fetch (default 1).
orderNoSort direction. Defaults to DESC when orderby is set (newest/highest first).
queryYesTicketSQL query string (e.g., "Created > '2026-06-01' AND Owner = 'jsmith'"). Use "id > 0" to match all tickets.
fieldsNoComma-separated list of extra ticket fields to include (e.g., "Priority,Requestor").
orderbyNoField to sort results by.
per_pageNoResults per page (default 20, max 100).
subfieldsNoExpand nested object fields inline, e.g. {"Owner":"Name,EmailAddress","Queue":"Name"}.

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates that results are summary information, not full ticket details, and that special TicketSQL syntax like '__CurrentUser__' and relative date expressions are supported. It does not mention permissions, rate limits, or response structure, but for a search tool it provides meaningful context beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear purpose statement, a critical usage warning, illustrative examples, and a pointer to the grammar tool. The examples are numerous but each serves a distinct use case, and there is no filler. It is longer than minimal, but the length is justified by the complexity of TicketSQL.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex TicketSQL-based search tool with no output schema, the description covers the query language, sorting, pagination, and the not-free-text constraint, and links to the full grammar reference. The main gap is that it does not specify exactly which fields are included in the 'summary information' results, leaving the return format somewhat under-specified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description significantly enhances the query parameter by providing multiple TicketSQL examples that illustrate syntax, operators, and field names. It also clarifies through examples how orderby, order, and per_page interact, adding value beyond the raw schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches for tickets using RT's TicketSQL query language and returns summary information with sorting and pagination. This specific verb+resource+mechanism combination distinguishes it from sibling tools like get_ticket, which fetches individual ticket details, and get_ticketsql_grammar, which only provides grammar reference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly warns that the query is TicketSQL and NOT free-text keyword search, and provides multiple concrete examples covering common use cases. It also directs users to get_ticketsql_grammar for the full grammar reference. However, it doesn't explicitly state when to prefer this tool over get_ticket or get_ticket_correspondence for retrieving detailed ticket data.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 6 tool updatesv0.2.0
    • First observedget_attachment
    • First observedget_ticket
    • First observedget_ticket_correspondence
    • First observedget_ticket_hierarchy
    • First observedget_ticketsql_grammar
    • First observedsearch_tickets
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: grammar reference, single ticket retrieval, search, correspondence, attachment download, and hierarchy. There is no overlap between tools, and an agent can easily select the right one.

Naming Consistency5/5

Tool names follow a consistent verb_noun pattern, mostly using 'get_' (get_ticket, get_correspondence, get_attachment, get_hierarchy) plus 'search_tickets' which appropriately uses 'search' for the query capability. All names are snake_case and readable.

Tool Count5/5

Six tools is well-scoped for an RT ticket system. The set covers core read operations without being bloated, and each tool serves a distinct and necessary function.

Completeness3/5

The tool set provides solid read coverage: retrieval, search, correspondence, attachments, and hierarchy. However, it lacks any write operations such as creating or updating tickets, replying, or changing status, which are fundamental to a ticketing system and would likely be expected by agents.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/msekoranja/rt-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server