mcp-server-rt

Official

by bestpractical

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.1
Disambiguation5/5
Each tool targets a distinct resource and action: users, queues, tickets, transactions, and attachments are all cleanly separated. Overlapping operations like add_comment vs add_reply are clearly differentiated by visibility, and get_ticket_history vs get_transaction serve list-vs-detail purposes.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern (get_, lookup_, search_, save_, list_, create_, update_, add_). The naming is uniform and predictable, making the tool set easy to navigate.
Tool Count4/5
At 17 tools, the set is slightly above the typical 3-15 range but each tool covers a necessary aspect of RT (users, queues, tickets, transactions, attachments). The count feels appropriate for a comprehensive server, just on the higher end.
Completeness4/5
Core ticket lifecycle operations (create, update, get, search, comment, reply) are covered, along with queues, users, attachments, and history. Minor gaps exist such as no tool to add attachments to a ticket or manage ticket links, but the primary workflows are fully supported.
Average 4/5 across 17 of 17 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on March 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under GPL 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true, and the description does not contradict. However, the description adds no behavioral context beyond the action itself—no mention of side effects, permissions, or that a new ticket is created. It merely restates the purpose without disclosing additional 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?
The description is a single, front-loaded sentence with no wasted words. It is perfectly concise for the simple action it states.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite high schema coverage, the tool is complex with 25 parameters, nested objects, and no output schema. The description does not explain return values (e.g., ticket ID) or provide an operational overview, leaving the agent to rely entirely on the schema. This is insufficient for such a complex 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 descriptions cover 100% of 25 parameters, including detailed explanations for nested objects like Attachments and CustomFields. The description adds no parameter-level information, so 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?
Description uses a specific verb 'Create' and resource 'ticket' in 'RT', clearly distinguishing it from sibling tools like update_ticket, add_comment, and search_tickets. The scope 'in RT' adds context and leaves no ambiguity about the tool's purpose.
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?
No explicit guidance on when to use this tool vs alternatives. It is implied by the name and description that this creates new tickets, but there is no mention of when not to use it (e.g., for modifications use update_ticket) or prerequisites beyond required fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, covering the read-only safety profile. The description adds context by listing transaction types (comments, replies, status changes) but does not disclose pagination behavior, ordering, or other behavioral traits. This matches the calibration example where adding some context yields a 3.
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, well-structured sentence with the action and resource at the start. It includes useful detail about return content without any redundant or filler words.
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?
With four parameters and no output schema, the description gives a reasonable hint at return values by listing transaction types, but omits pagination and field selection context. It is adequate but leaves gaps about how the page/per_page and fields parameters affect the response.
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% (all four parameters have descriptions), so the description adds no additional parameter semantics. Baseline 3 is appropriate since the schema already documents each parameter.
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's action ('Get') and resource ('transaction history for a ticket'), and specifies the return type ('a list of transactions'). It effectively distinguishes itself from siblings like get_transaction and get_ticket by focusing on the history/list aspect.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention that get_transaction might be used for a single transaction or indicate any exclusions/alternatives. Only the purpose is stated, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates this is a safe read operation. The description does not add any behavioral context beyond that, such as the exact contents of the response or any permission requirements. It is not contradictory, but it also doesn't expand on the annotation.
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, concise sentence that immediately front-loads the verb and resource. There is no unnecessary wording or redundancy.
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 straightforward getter with a well-defined schema and readOnly annotation, the description adequately conveys the core purpose. It does not specify return format or optional parameter usage, but the schema fills in those gaps. The overall context is sufficient for an agent to select this tool correctly.
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 provides complete descriptions for all three parameters (id, fields, subfields), so the schema covers the meaning. The description only mentions the ID, adding no extra semantics for the optional fields. Since schema coverage is 100%, the baseline of 3 applies.
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 clearly states the action ('Get detailed information') and the resource ('a specific ticket by its ID'), using a specific verb and resource. It does not explicitly differentiate from sibling tools like get_ticket_history or get_ticket_attachments, but the scope is evident from the description.
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 usage context is implied—when you have a ticket ID and need full details—but the description provides no explicit guidance on when to use this tool instead of alternatives like search_tickets or get_ticket_history. No exclusions or preferred scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'MCP server writes the file directly', clearly indicating a write operation, but annotations declare readOnlyHint=true. This is a direct contradiction and severely misleads the agent about the tool's safety profile.
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 primary action. Every sentence contributes meaningful information (operation, platform note, path handling) with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with few parameters and no output schema, so the description need not explain return values. However, the contradiction with readOnlyHint leaves the agent without reliable safety information. Additionally, important details like overwrite behavior, error handling, and return values are omitted, reducing completeness for a write operation.
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 already covers both parameters with descriptions (100% coverage). The description adds extra value by explaining path behavior when a directory is provided ('original filename is used'), which goes beyond the schema's description. This additional semantic clarification justifies a score above the baseline of 3.
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?
Clearly states the action ('Save an attachment to a local file'), the resource (attachment), and the destination. It is distinct from sibling tools like get_attachment which retrieves content, making the purpose unambiguous.
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?
Provides context that the server writes the file directly and works on any platform, implying cross-platform reliability. However, it does not explicitly mention when to prefer this over get_attachment or other alternatives, nor does it list exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation. The description adds no additional behavioral context such as return format or side effects; it only restates the identification method which is already in 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that conveys the action, target, and identifier method with no redundant 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?
For a simple read-only tool with one parameter, the description is adequate. However, the lack of an output schema means the description could clarify what 'details' includes, especially given the sibling get_queue_fields to avoid ambiguity.
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 describes the sole parameter 'id' as 'Queue ID or name', providing full coverage. The description's mention of 'by ID or name' adds no semantic value 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's function: retrieving details for a specific queue, identified by ID or name. This distinguishes it from sibling list_queues (listing all queues) and get_queue_fields (field definitions).
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 queue identifier is known, but does not explicitly mention alternatives like list_queues for browsing or get_queue_fields for field-specific data. No exclusions or when-not-to-use are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already indicates a safe read operation, and the description does not contradict it. The description adds the scope 'all available queues' but offers no further behavioral context such as response format, pagination, or ordering. This is acceptable given the annotation coverage.
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, concise sentence with no unnecessary words. It front-loads the core purpose effectively and is appropriately sized for the tool's simplicity.
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 list tool with one optional parameter and no output schema, the description adequately communicates the primary function and implies a return of queue objects. However, it lacks any hints about the return structure or use-case examples, which prevents a perfect score.
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 only parameter 'fields' is fully described in the schema, including a default value and detailed explanation. The tool description adds no additional meaning beyond the schema, so the baseline 3 for high schema coverage 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 'List all available queues' clearly identifies the verb (list) and resource (queues), and distinguishes this tool from siblings like get_queue (which targets a single queue) and get_queue_fields (which likely returns metadata). It is 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 implies usage for listing all queues but provides no explicit guidance on when to use this tool versus siblings like get_queue. There is no mention of exclusions or alternative scenarios, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The destructiveHint annotation already signals a state-modifying operation, and the description adds the valuable context that comments are internal and hidden from the requestor. However, it does not disclose other potential side effects like time logging or the permanence of the comment, but given the annotation, the bar is lower.
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 conveys purpose and the key behavioral constraint. 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?
Despite having five parameters and no output schema, the tool is a simple mutation with rich parameter descriptions and a destructiveHint annotation. The description adequately captures the main functional distinction (internal vs external) in context with sibling tools. Slightly more detail about return behavior could improve completeness, but it's not critical.
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% with all five parameters documented, so the description is not required to add parameter details. The description itself adds no extra semantics beyond what the schema provides, matching the baseline for full coverage.
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 adds an internal comment to a ticket, with the specific qualifier 'not visible to the requestor'. This verb+resource structure immediately distinguishes it from the sibling 'add_reply' tool.
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 implicit usage context by specifying 'internal comment' and 'not visible to the requestor', which tells the agent when to use this over the sibling 'add_reply'. However, it does not explicitly reference the alternative or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the useful context that the reply is visible to the requestor, but it does not disclose additional behavioral traits such as potential email notifications, irreversibility, or status changes beyond what the destructiveHint annotation implies. The annotation covers the destructive nature, so the description's contribution is modest but non-contradictory.
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 no filler. Every word earns its place, efficiently conveying the action, resource, and visibility scope.
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?
Given the tool has six parameters and no output schema, the description is brief but sufficient for selection because the schema thoroughly documents parameter semantics. The key differentiator (visibility to requestor) is present, though it does not mention optional capabilities like status changes or time logging that are described in the schema.
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 100% description coverage for all six parameters, including detailed explanations of attachment handling and optional fields. The description adds no parameter-level information beyond the schema, so it meets the baseline of 3.
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 a specific verb ('Send') and resource ('a reply on a ticket'), with the scope 'visible to the requestor' distinguishing it from sibling tools like add_comment. This is a precise, non-redundant statement of the tool's core function.
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 phrase 'visible to the requestor' provides clear context for when to use this tool (customer-facing correspondence) versus internal notes, but it does not explicitly name alternatives or state when not to use it. This is clear context without formal exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description's 'Search' wording aligns with this. However, the description does not add any extra behavioral context such as pagination semantics, result shape, or rate limits, so it contributes minimal value beyond the annotation.
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, focused sentence that immediately communicates the tool's purpose with no filler. It is well-structured and front-loaded, making it easy to parse.
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?
Given the simplicity of the tool and the comprehensive schema plus read-only annotation, the description is mostly sufficient. It could benefit from naming the output format or potential limitations, but the core usage is clearly captured, making it complete enough for a basic search 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?
The input schema covers all three parameters (query, page, per_page) with full descriptions, achieving 100% coverage. The tool description does not enrich the parameter semantics beyond what the schema already provides, 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 clearly states the action ('Search'), resource ('RT users'), and scope ('by name or email address'). It distinguishes itself from sibling tools like search_tickets (ticket search) and get_current_user (current user) by specifying the user-focused lookup nature.
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 provides clear context for when to use this tool—whenever a user needs to be found by name or email. It does not explicitly mention alternatives or when not to use it, but the purpose is sufficiently self-evident from the wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already conveys this is a safe read operation. The description adds value by specifying exactly what is returned (custom field types/allowed values and lifecycle name), which is helpful given there is no output schema. It does not discuss edge cases or response formatting, but for a simple read tool this is 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 a single, concise sentence that front-loads the action and clearly lists the returned data. No redundant or extraneous wording.
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?
For a simple metadata retrieval tool with one well-documented parameter, read-only annotation, and no output schema, the description provides sufficient information: what the tool returns and what input it needs. It is complete for tool selection and invocation.
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 already fully documents the single parameter 'id' as 'Queue ID or name' (100% coverage). The description does not add any additional parameter detail, so the baseline 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's function: retrieving custom fields (including types and allowed values) and the lifecycle name for a queue. It uses a specific verb ('Get') and resource, and it distinguishes itself from sibling tools like get_queue and list_queues by focusing on queue metadata fields.
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?
Usage context is implied by the description: use this tool when you need the custom field definitions and lifecycle name of a queue. However, there is no explicit guidance on when to prefer this over get_queue or other list tools, nor any mention of alternative paths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation. The description adds value by specifying exactly what fields are returned (names, MIME types, sizes, IDs), which is useful in the absence of an output schema. It does not discuss pagination behavior, but the annotation covers the safety profile.
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 no filler words. It efficiently communicates the resource, the action, and the key return fields.
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 list operation with three well-documented parameters and a read-only annotation, the description is largely complete. It covers the return fields, but the phrase 'all attachments' could be slightly misleading given the pagination parameters (page, per_page), so a small gap remains.
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%, so all three parameters (id, page, per_page) are already documented with descriptions. The description adds no extra parameter-level meaning beyond what the schema provides, so the baseline 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 and resource: 'List all attachments on a ticket', and enumerates the returned fields (names, MIME types, sizes, IDs). This clearly distinguishes it from sibling tools like get_attachment (singular retrieval) and save_attachment (write operation).
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 clearly states the use case: listing attachments on a ticket. It does not explicitly contrast with alternatives like get_attachment, but the context is unambiguous for a listing operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint=true, indicating mutation, and the description aligns with this. It adds the behavioral detail that parameters must be top-level rather than nested, which is not covered by annotations. However, it does not elaborate on side effects like replacing existing lists, though individual schema descriptions cover those.
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 one concise, front-loaded sentence. It immediately states the purpose and captures the essential usage nuance without any fluff, making every word earn its place.
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?
Given the tool's complexity (35 parameters), the description is minimal but sufficient because the schema provides full parameter documentation. It adds the critical non-schema instruction about top-level parameters, and the destructiveHint annotation covers safety. No output schema exists, but return behavior is not essential for an update tool.
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 adds meaningful guidance beyond the schema by instructing agents to pass each property as a top-level parameter and explicitly forbidding the nested 'fields' object, with examples (Due, Status, Owner). This is valuable for correct invocation.
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's function: 'Update an existing ticket.' This is a specific verb+resource that distinguishes it from 'create_ticket', 'add_comment', and other sibling tools. It also adds usage instruction about top-level parameters, further clarifying its scope.
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 says 'Update an existing ticket', implying use when modifying existing entities, and explicitly instructs to pass properties as top-level parameters and avoid the nested 'fields' object. It provides clear context for when to use the tool, though it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant context beyond the readOnlyHint annotation: TicketSQL syntax pitfalls, meta-status values, and a mandatory field list. It warns about non-obvious syntax and gives examples, which helps agents understand the query behavior and expectations.
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?
Each sentence earns its place: purpose, grammar warning, syntax key, examples, and field guidance. The description is structured and efficient for a complex query tool, avoiding fluff while packing essential details.
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?
Given the complexity of TicketSQL and no output schema, the description thoroughly covers query construction and expected fields. It does not explain the return format explicitly, but the focus on fields implies the response structure. The main challenges are addressed.
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 enriches parameter semantics by explaining the query parameter with concrete examples and specifying the 'fields' parameter defaults. This adds value beyond the schema's basic parameter 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 'Search for tickets using RT's TicketSQL query language' with a specific verb and resource. It distinguishes from sibling tools like get_ticket (single ticket retrieval) and get_ticketsql_grammar (grammar reference), making the purpose unambiguous.
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 consulting get_ticketsql_grammar before writing complex queries, providing a clear prerequisite. While it doesn't explicitly say when not to use the tool, the guidance to consult the grammar and the context of sibling tools imply appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral detail beyond the readOnlyHint annotation: text content is returned decoded, binary content as MIME Base64. This informs the agent about response format, which is valuable for a retrieval tool.
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 action, then encoding details, then alternative guidance. Every sentence earns its place with no redundancy.
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?
For a simple, single-parameter read-only tool with no output schema, the description covers purpose, behavior, and alternatives. It is fully sufficient for an agent to select and invoke the tool correctly.
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% (id with 'Attachment ID'). The description says 'by ID' but doesn't add further meaning beyond the schema. Baseline 3 is appropriate; no additional parameter context is provided.
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 a single attachment by ID, which is specific and distinguishes it from siblings like get_ticket_attachments (likely list) and get_transaction. The phrase 'single attachment' differentiates it from batch operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names alternative tools for finding attachment IDs (get_ticket_attachments or get_transaction), giving when-to-use guidance. It implies the tool is for when you already have an ID, and the alternative instructions cover when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds the critical context that the returned user is tied to the auth token, clarifying identity semantics. It goes beyond structured data without overclaiming 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: the first states the action and resource, the second explains when to use it. No wasted words, and the critical usage guidance is front-loaded.
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?
For a no-parameter getter with readOnly annotation, the description fully covers what the tool does and when to use it. No output schema exists, so explaining the return value is not necessary beyond identifying the resource.
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 and 100% schema description coverage, so the description need not explain parameters. Baseline 4 is appropriate for this parameterless interface.
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 specifies a concrete verb ('Get') and resource ('RT user account') tied to the configured auth token. It clearly differentiates from sibling lookup_user by focusing on the current user identity rather than arbitrary search.
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?
Explicitly states when to use: 'to determine who "I" or "me" refers to' in ticket assignment and search contexts. It does not explicitly name alternatives, but the usage context is unambiguous and self-contained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already signals a safe read operation, and the description adds that it returns 'decoded message content,' which is a useful behavioral detail beyond the annotation. No contradiction exists. It doesn't discuss return format or errors, but for a simple get operation this is reasonable.
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 avoids redundancy and is highly efficient.
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?
Despite lacking an output schema, the description explains what is returned (full details plus decoded content) and provides clear usage context via the sibling reference. For a simple single-parameter tool with strong annotations, this is complete.
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 has 100% coverage with a single parameter 'id' described as 'Transaction ID.' The description adds no new parameter-level detail beyond referencing 'single transaction,' which is already in the schema. Baseline 3 is appropriate since the schema carries the burden.
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's function: 'Get the full details of a single transaction including decoded message content.' It uses a specific verb ('Get'), identifies the resource ('single transaction'), and distinguishes itself from siblings like get_ticket_history by noting the decoded content feature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use this after get_ticket_history to read the actual text of a reply or comment.' This directly tells the agent when to use this tool relative to a sibling, fulfilling the dimension fully.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation, and the description adds useful context by identifying the RT version and the nature of the returned reference. It does not contradict the annotation.
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 with no redundant wording. The first states the purpose, the second provides targeted usage guidance, making it highly efficient.
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?
For a parameterless, read-only lookup tool, the description fully explains what it does and when to use it. No output schema exists, but the nature of the returning reference is self-evident and sufficiently described.
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 coverage is 100%. The description doesn't need to document parameters; it instead focuses on the returned grammar reference, which 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 it 'Returns the TicketSQL grammar reference' for a specific version, with a specific verb and resource. This distinguishes it from sibling tools like search_tickets and get_queue_fields, which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence explicitly instructs to 'Consult this before writing any TicketSQL query' and highlights specific difficult areas (Status, date/time, custom fields, link fields), providing strong usage guidance. No alternatives are mentioned, but this tool has no close substitutes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-server-rt MCP server](https://glama.ai/mcp/servers/bestpractical/mcp-server-rt/badges/card.svg)](https://glama.ai/mcp/servers/bestpractical/mcp-server-rt)

Score Badge

Copy to your README.md:

[![mcp-server-rt MCP server](https://glama.ai/mcp/servers/bestpractical/mcp-server-rt/badges/score.svg)](https://glama.ai/mcp/servers/bestpractical/mcp-server-rt)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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