Skip to main content
Glama
bestpractical

mcp-server-rt

Official

get_queue_fields

Read-only

Fetch a queue's custom fields and lifecycle, including types, allowed values, and rendering format. See three separate groups to apply fields correctly to tickets, queues, or transactions.

Instructions

Get custom fields (with types and allowed values) and lifecycle name for a queue. Returns three separate groups, because RT applies custom fields to three different things: CustomFields are set on tickets in the queue (this is what you want when creating or updating a ticket), QueueCustomFields are set on the queue itself and include the queue's CurrentValues (RTIR uses these for RTIR Constituency and RTIR default WHOIS server), and TransactionCustomFields are set on individual comments and replies. When the user asks what custom fields a queue has, report all three groups and say which is which. Each field carries a ContentFormat saying how its value is rendered: "html" (send markup; a bare newline shows nothing), "plain-text-multiline" (send plain text; newlines become line breaks), "plain-text" (shown exactly as typed), "wikitext" (wiki markup), "file" (an uploaded image or attachment rather than text), "date", or "datetime" (send local time; RT reads it in the user's timezone). Check it before writing a multi-line or formatted value. Every applied field is always listed. If RT permits seeing that a field is applied but not reading the field itself, the entry carries id, Name and a DetailsUnavailable message explaining why; a QueueCustomFields entry still carries its CurrentValues too. The field is still applied to the queue either way, and a field in CustomFields can still be set on a ticket. Tell the user which fields came back without details rather than reporting them as missing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesQueue ID or name

Schema Changelog

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

  1. First observedv0.2.1

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only provide readOnlyHint=true, but the description adds substantial behavioral detail: three return groups, ContentFormat rendering semantics for all seven formats, the DetailsUnavailable edge case (fields applied but unreadable), that every applied field is always listed, and that QueueCustomFields entries still carry CurrentValues. This far exceeds what the annotation alone conveys and discloses tricky response behavior.

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 long but front-loaded with the core purpose in the first sentence. Each subsequent sentence adds genuinely useful information: group distinctions, ContentFormat details, and edge-case behavior. It could be slightly tightened (e.g., the RTIR parenthesis is contextual but not essential), but every sentence earns its place for a tool with this subtlety.

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 there is no output schema, the description does an excellent job of explaining return structure: three groups, fields carrying ContentFormat, allowed values in types, and how to interpret DetailsUnavailable entries. It also covers how to present results to the user. No critical information needed to call and interpret this tool is missing.

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 input schema has only one parameter, 'id', described as 'Queue ID or name', so schema coverage is 100%. The description does not add extra parameter-level semantics, but it doesn't need to because the schema already fully documents the parameter. Baseline 3 applies.

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 opens with a specific, actionable statement: 'Get custom fields (with types and allowed values) and lifecycle name for a queue.' It clearly identifies the resource (queue custom fields), the operation (get), and the return content (types, allowed values, lifecycle name). It further distinguishes three subgroups, which prevents confusion with siblings like get_queue or search_custom_fields.

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 gives concrete guidance on when each group is relevant: CustomFields are for ticket creation/update, QueueCustomFields for queue-level settings, TransactionCustomFields for comments/replies. It also explicitly instructs the agent to report all three groups when a user asks about queue custom fields. It does not name alternative tools or provide explicit when-not-to-use conditions, so it stops short of a 5.

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