Skip to main content
Glama
bestpractical

mcp-server-rt

Official

create_ticket

Destructive

Log a new issue in Request Tracker by creating a ticket with queue, subject, priority, attachments, and custom fields.

Instructions

Create a new ticket in RT

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
CcNoCc username(s) (string or array of strings)
DueNoDue datetime (format: "YYYY-MM-DD HH:MM:SS" in local time)
ToldNoLast Contact datetime (format: "YYYY-MM-DD HH:MM:SS" in local time)
TypeNoTicket type (e.g. "ticket", "reminder")
ChildNoChild links (ticket ID, URL, or array)
OwnerNoOwner username
QueueYesQueue name or ID
ParentNoParent links (ticket ID, URL, or array)
StartsNoStarts datetime (format: "YYYY-MM-DD HH:MM:SS" in local time)
StatusNoInitial status
AdminCcNoAdminCc username(s) (string or array of strings)
ContentNoTicket body content
StartedNoStarted datetime (format: "YYYY-MM-DD HH:MM:SS" in local time)
SubjectYesTicket subject
PriorityNoTicket priority, as a number or as one of the labels this RT displays (e.g. Low, Medium, High). Labels are configured per queue and are case-sensitive, so use the exact label RT shows; when in doubt pass a number. RT does not reject a label it does not recognize, and does not reject a label at all on an installation with priority labels turned off: it sets the priority to 0, the lowest, and reports success. So read the PrioritySet message in the response, which names the label RT actually applied, and tell the user if it is not the one you asked for. A label is applied in a follow-up update because RT cannot resolve one while creating a ticket; if that step fails the response carries PriorityNotSet instead and the ticket is created without the priority.
RefersToNoRefersTo links (ticket ID, URL, or array)
DependsOnNoDependsOn links (ticket ID, URL, or array)
RequestorNoRequestor username(s) (string or array of strings)
AttachmentsNoFiles to attach. Provide either FilePath (local file path, server reads and encodes it) or FileContent (pre-encoded MIME Base64). FileName and FileType are optional with FilePath and are inferred from the path.
ContentTypeNoContent MIME type (default text/plain)
CustomRolesNoCustom role assignments as {role_name: username_or_array}
DescriptionNoTicket description. This field is HTML: use <p> for paragraphs and <br /> for single line breaks, because a bare newline renders as nothing. Plain text with no markup is sent with its angle brackets escaped for you, and gains paragraphs if it has line breaks. If you send markup, write any angle bracket that is not part of it as &lt; and &gt; yourself — RT silently deletes any tag it does not allow along with the text inside it, so an address left as <bob@example.com> inside HTML is lost. A bare & is safe as typed.
CustomFieldsNoCustom field values as {CF_name: value}. How a value is displayed depends on the field: call get_queue_fields and check each field's ContentFormat before writing a multi-line or formatted value.
DependedOnByNoDependedOnBy links (ticket ID, URL, or array)
ReferredToByNoReferredToBy links (ticket ID, URL, or array)

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed4 schema fields changedv0.3.0
    • changedInput schema / properties / CustomFields / description
      Previous value: -"Custom field values as {CF_name: value}"New value: +"Custom field values as {CF_name: value}. How a value is displayed depends on the field: call get_queue_fields and check each field's ContentFormat before writing a multi-line or formatted value."
    • changedInput schema / properties / Description / description
      Previous value: -"Ticket description"New value: +"Ticket description. This field is HTML: use <p> for paragraphs and <br /> for single line breaks, because a bare newline renders as nothing. Plain text with no markup is sent with its angle brackets escaped for you, and gains paragraphs if it has line breaks. If you send markup, write any angle bracket that is not part of it as &lt; and &gt; yourself — RT silently deletes any tag it does not allow along with the text inside it, so an address left as <bob@example.com> inside HTML is lost. A bare & is safe as typed."
    • changedInput schema / properties / Priority / description
      Previous value: -"Ticket priority"New value: +"Ticket priority, as a number or as one of the labels this RT displays (e.g. Low, Medium, High). Labels are configured per queue and are case-sensitive, so use the exact label RT shows; when in doubt pass a number. RT does not reject a label it does not recognize, and does not reject a label at all on an installation with priority labels turned off: it sets the priority to 0, the lowest, and reports success. So read the PrioritySet message in the response, which names the label RT actually applied, and tell the user if it is not the one you asked for. A label is applied in a follow-up update because RT cannot resolve one while creating a ticket; if that step fails the response carries PriorityNotSet instead and the ticket is created without the priority."
    • changedInput schema / properties / Priority / type
      Previous value: -"integer"New value: +[
      +  "integer",
      +  "string"
      +]
  2. First observedv0.2.1

TDQS

A3.5/5.0
Behavior3/5

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

The annotation destructiveHint=true already indicates this operation changes system state, and the description does not contradict it. The description adds no additional behavioral context such as side effects, permissions, or response behavior, but with annotations covering the safety profile, a neutral score is appropriate.

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 with zero filler. Given the enormous amount of parameter detail already in the schema, keeping the tool-level description minimal is appropriate and efficient.

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

Completeness3/5

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

The tool is complex (25 params, nested objects, no output schema), and the description provides no return-value guidance or explicit note about response messages. The rich schema and annotations cover most invocation needs, but the absence of any output behavior disclosure leaves a notable gap for an agent handling the result.

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%, and the schema provides extensive detail for all 25 parameters, including formats, defaults, enums, nested structures, and special caveats (e.g., Priority labels, Description HTML rules). The tool description itself contributes nothing about parameters, so it relies fully on the schema, matching the baseline for high schema coverage.

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

Purpose4/5

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

The description states a specific action ('Create') and resource ('a new ticket in RT'), which clearly identifies the tool's purpose and distinguishes it from siblings like update_ticket or search_tickets. However, it is largely a restatement of the tool name and does not elaborate on scope or explicitly differentiate from other create tools (e.g., create_queue).

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 intended usage is implied: use this when you need to create a new ticket. The description does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or conditions, but the verb-resource pair makes the primary use case obvious.

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

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/bestpractical/mcp-server-rt'

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