Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@NKS osTicket MCP find tickets about password reset"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol server for osTicket. It lets AI agents (Claude, etc.) list, search, read, create, update, reply to and delete tickets, plus read stats, manage parent/child subtickets and download attachments.
It talks to the companion NKS osTicket API plugin, which exposes a single JSON endpoint inside osTicket.
Tool | Purpose |
| List tickets (filter by status/department, paginated) |
| Full-text search by subject |
| One ticket with full message thread |
| Total / open / closed / overdue counts |
| All ticket statuses |
| Create a ticket |
| Change status / due date / topic, add internal note |
| Post a customer-facing reply (emailed) |
| Delete a ticket (irreversible) |
| Link child under parent |
| Remove a child's parent link |
| List a parent's children |
| Get a child's parent |
| Download an attachment (base64) |
Related MCP server: OTRS MCP Server
Node.js ≥ 18
The NKS osTicket API plugin installed on your osTicket instance
An osTicket API key (Admin → Manage → API Keys) with the permissions your tools need, bound to the source IP this server runs from
npm install
npm run buildSet via environment variables (see .env.example):
Variable | Required | Default | Description |
| yes | – | URL of the API entry, |
| yes | – | osTicket API key |
| no |
| Request timeout |
| no |
|
|
Add to your MCP server configuration:
{
"mcpServers": {
"osticket": {
"command": "node",
"args": ["/absolute/path/to/nks-osticket-mcp/dist/index.js"],
"env": {
"NKS_OSTICKET_URL": "https://support.example.com/api/nks-osticket.php",
"NKS_OSTICKET_API_KEY": "your-api-key"
}
}
}
}MIT — see LICENSE.
Create a new ticket. Requires subject and message.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Submitter name | |
| No | Submitter email | ||
| message | Yes | Ticket body (message) | |
| subject | Yes | Ticket subject | |
| topicId | No | Help topic id | |
| priority | No | Priority id (1=low..4=emergency) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must explain behavioral traits. It only says 'Create a new ticket' and 'Requires subject and message.' It omits details on authentication, rate limits, what happens with invalid data, or side effects (e.g., email notifications).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, consisting of two sentences. It is concise without being verbose, but it could be more informative while remaining succinct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters and no output schema, the description is minimal. It does not explain default values for optional fields (e.g., priority, topicId), the response format, or error handling. It lacks completeness for a tool that creates a resource.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter has a description in the schema. The tool description adds only that subject and message are required, which is already implied by the schema. No additional semantic guidance is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Create' and resource 'a new ticket', and notes required fields. It clearly communicates the core action, though it doesn't differentiate from siblings like osticket_reply_ticket.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as osticket_reply_ticket or osticket_update_ticket. There is no context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a ticket and its thread. Irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | Ticket number to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses destructive nature ('Permanently delete', 'Irreversible'), which is good, but lacks details on permissions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and no output schema, the description sufficiently covers what the tool does and its irreversibility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameter with a description. Description adds no extra meaning beyond what schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete' and the resource 'ticket and its thread', distinguishing it from siblings like create, update, reply, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The word 'Irreversible' implies caution but doesn't explicitly state prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a ticket attachment by its numeric file id (from a thread entry's attachments[].fileId in osticket_get_ticket), returned as base64.
| Name | Required | Description | Default |
|---|---|---|---|
| fileId | Yes | Attachment file id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description indicates read-only download, but doesn't disclose potential size limits, authentication needs, or handling of non-existent files. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with key verb and resource, including input source and output format. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple download tool with one param and no output schema, the description covers input source and output format. Could add error handling or size info, but sufficient given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with one integer parameter. Description adds context by specifying the source (thread entry's attachments[].fileId), which goes beyond the schema's basic 'Attachment file id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it downloads a ticket attachment by numeric file ID and returns as base64. It specifies the ID comes from osticket_get_ticket's attachments array, distinguishing it from sibling tools which don't handle downloads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when to use or alternatives, though it implies use after getting a fileId from osticket_get_ticket. Lacks guidance on when not to use or error conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all child tickets of a parent ticket.
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | Parent ticket number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description does not disclose behavioral traits such as whether the operation is read-only, any required permissions, or potential side effects. With no annotations, the description carries full burden but fails to provide this information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single, front-loaded sentence. It is concise but extremely brief, potentially sacrificing informative detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too minimal for a tool with no output schema. It does not explain the return format (e.g., list of ticket IDs or full objects), pagination, or how to interpret results. This lack of completeness may hinder correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has one parameter 'number' with description 'Parent ticket number.' The tool description does not add any additional meaning beyond what the schema already provides. Since schema coverage is 100%, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List all child tickets of a parent ticket,' specifying verb (list) and resource (child tickets). It distinguishes this tool from sibling osticket_get_parent, which retrieves the parent ticket.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives like osticket_get_parent or osticket_link_subticket. The description lacks explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the parent ticket of a child ticket (null if none).
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | Child ticket number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the function without disclosing any behavioral traits such as permissions, read-only nature, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently conveys the tool's purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter and no output schema, the description is adequate. It explains the return value but does not cover error cases or the representation of the parent ticket.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description aligns with the parameter's schema description. However, it adds no additional meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get parent ticket) and the resource (a child ticket). It distinguishes from siblings like osticket_get_children and osticket_get_ticket.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a child ticket number, but it does not explicitly state when to use this over alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregate ticket statistics: total, open, closed, overdue.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 correctly indicates a read-only operation (aggregate stats), but does not disclose whether the data is real-time, cached, or any authorization requirements. Adequate but lacks deeper 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It efficiently conveys the tool's purpose and output. Every word is earned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters, no output schema, and is a simple stats endpoint, the description adequately lists the returned statistics. Provides complete information for an agent to understand the tool's capability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0 required), so schema coverage is 100% trivially. The description adds value by enumerating the specific statistics included (total, open, closed, overdue), which is essential since there is no output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and resource 'stats', and specifies the exact statistics returned (total, open, closed, overdue). This distinguishes it from sibling tools that manipulate individual tickets or lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when aggregate ticket statistics are needed) but does not explicitly state when not to use or mention alternatives. It is clear but lacks exclusion or comparison guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one ticket with full detail including the message thread. Each thread entry may include an "attachments" array (fileId, name, type, size, inline, cid); pass an attachment's numeric fileId to osticket_download_attachment. Provide number or id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Internal ticket id (alternative to number) | |
| number | No | Public ticket number, e.g. "CH00072469" |
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 states the tool returns full detail and thread with attachments, which implies a read operation. However, it does not explicitly confirm idempotency, safety, or any side effects, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The first sentence front-loads the core purpose. The second adds necessary detail about attachments and parameter usage. No unnecessary words, but could be slightly shorter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description covers the main return structure (message thread, attachments). It tells how to use parameters (one of id/number). However, it does not list other likely fields (status, subject, etc.), leaving some incompleteness for an agent needing full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both id and number. The description adds value by clarifying that 'Provide number or id' suggests mutual exclusivity and provides an example format (e.g., 'CH00072469'), which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get one ticket with full detail', specifying the verb and resource. It distinguishes from sibling tools like osticket_list_tickets (list) and osticket_search_tickets (search) by focusing on a single ticket with full detail and thread.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need full detail of a single ticket, but it does not explicitly state when to use this vs alternatives (e.g., osticket_list_tickets for summaries, osticket_search_tickets when id is unknown). No exclusions or when-not scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Link a child ticket under a parent (parent/child relationship).
| Name | Required | Description | Default |
|---|---|---|---|
| child | Yes | Child ticket number | |
| parent | Yes | Parent ticket number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic purpose. It does not disclose side effects (e.g., overwriting existing parent links), required permissions, or what happens on failure. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded. However, it could be slightly expanded with useful context without losing conciseness. Current size is efficient but borderline under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple operation (linking), lack of output schema, and no annotations, the description is too sparse. It fails to explain post-link behavior, error conditions, or any return value, making it incomplete for an agent to correctly anticipate the tool's full effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both parameters. The description adds no additional meaning beyond the schema's field names and types, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Link' and identifies the resource as 'child ticket under a parent', clearly defining the parent/child relationship. It distinguishes from siblings like osticket_unlink_subticket (which reverses the operation) and osticket_get_children/osticket_get_parent (which are read operations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., osticket_unlink_subticket). It lacks prerequisites such as the parent ticket existing or the child not already being linked, and does not specify the context in which linking is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all ticket statuses with their canonical state.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'list' which implies read-only behavior, but does not disclose other traits like whether it requires authentication, rate limits, or if it returns cached data. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description is adequate but lacks details about the response format or what 'canonical state' includes. Could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, schema coverage is 100%. The description adds no parameter info, which is acceptable as none exist. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb ('List') and resource ('ticket statuses'), and adds 'with their canonical state' which distinguishes it from sibling tools like osticket_list_tickets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving statuses by mentioning 'List all ticket statuses', but does not explicitly state when to use it vs alternatives or provide any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tickets, newest first. Filter by status (open/closed/resolved/archived or numeric id) and department. Paginated.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort field (default created) | |
| limit | No | Max results (default 20, max 100) | |
| offset | No | Pagination offset | |
| status | No | open | closed | resolved | archived | <status id> | |
| department | No | Department name or id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses pagination and sorting behavior, but does not mention read-only nature, authorization needs, or potential side effects. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundancy. Every word serves a purpose: verbs, nouns, and modifiers are precise. Excellent front-loading of purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 5 parameters fully described in schema and no output schema, the description covers essential aspects: ordering, filters, pagination. It does not detail return format, but that is acceptable given tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions already present. The description adds clarity on default sort ('newest first') and reinforces filter options, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List tickets' with specifics: newest first order, filterable by status and department, and paginated. This distinguishes it from sibling tools like osticket_search_tickets or osticket_get_ticket.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving filtered, paginated ticket lists, but does not explicitly compare to alternatives like osticket_search_tickets. It provides context on default sorting and available filters but lacks 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Post a customer-facing reply to a ticket. This is emailed to the ticket's user.
| Name | Required | Description | Default |
|---|---|---|---|
| alert | No | Email the user (default true) | |
| title | No | Optional reply title | |
| number | Yes | Ticket number to reply to | |
| response | Yes | Reply body, sent to the customer |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states the reply is emailed, but does not cover other important behaviors such as authentication requirements, whether the reply modifies ticket state, or what happens when 'alert' is false. The schema provides some detail (e.g., alert default), but the description itself lacks transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Every word contributes to understanding the tool's core function. Well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose but omits return value, error conditions, and prerequisite checks (e.g., ticket existence). Given no output schema and 4 parameters, additional details would improve completeness for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 only minor context (e.g., 'emailed' reiterates schema). No new semantic value beyond what the schema already provides for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (post a customer-facing reply) and the resource (ticket). It also clarifies that the reply is emailed to the ticket's user, which distinguishes it from internal updates. This specificity makes 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for customer-facing replies but does not explicitly contrast with sibling tools like osticket_update_ticket (which might be for internal notes). No when-not-to-use guidance is provided, though the email hint helps infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search tickets by subject. Optional status filter and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | ||
| limit | No | ||
| query | Yes | Search text matched against ticket subjects | |
| offset | No | ||
| status | No | Optional status filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states it's full-text search and mentions optional filters, but does not explain default behavior (e.g., sort order), result format, or case sensitivity. Some transparency is added beyond the schema, but more detail would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 12 words, front-loaded with the primary action. No unnecessary verbiage; every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and only 40% parameter coverage, the description lacks critical information such as response format, default sort order, and whether search is case-sensitive. Agent may struggle to use tool correctly without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 40%; description adds 'full-text' context to query and groups pagination (limit/offset) as 'pagination', but does not explain individual parameter semantics (e.g., sort enum values, offset meaning). It provides marginal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it performs full-text search on tickets by subject. This distinguishes it from sibling tools like osticket_list_tickets (which lists all tickets without search) and osticket_get_ticket (single ticket retrieval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool should be used when searching tickets by subject, with optional status and pagination. It does not explicitly state when not to use it or name alternatives, but the context is clear enough for differentiation from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a child ticket's parent link.
| Name | Required | Description | Default |
|---|---|---|---|
| child | Yes | Child ticket number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose side effects (e.g., behavior if the child ticket has no parent), authentication requirements, or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but it is too minimal. It could include useful context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple unlink operation, the description is fairly complete given the single parameter and no output schema, but it omits potential edge cases or return value expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'child' is described in the schema as 'Child ticket number', and the tool description adds no extra meaning. Since schema coverage is 100%, baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the action 'remove' and the resource 'child ticket's parent link', which is clear and distinguishes it from sibling tools like osticket_link_subticket and osticket_get_parent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool instead of alternatives like osticket_link_subticket or osticket_get_parent. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a ticket: change status, set/clear due date, change help topic, and/or add an internal staff note.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Internal note (staff-only, not emailed) | |
| number | Yes | Ticket number to update | |
| status | No | New status (open/closed/... or id) | |
| dueDate | No | Due date (ISO); null clears it | |
| topicId | No | New help topic id | |
| noteTitle | No | Title for the internal note | |
| statusComment | No | Optional comment logged with a status change |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral traits such as required permissions, whether updates are logged, or the effect on the ticket. The term 'update' is generic and carries the full burden of behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that front-loads the main action and lists capabilities. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 7 parameters with good schema coverage, the description provides a reasonable overview but lacks behavioral context and does not cover all parameter nuances (e.g., noteTitle).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context by grouping parameters into actions (e.g., 'change status' for status), but does not explain noteTitle or statusComment beyond what schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Update a ticket' and lists specific actions (change status, set/clear due date, change help topic, add internal note). This distinguishes it from siblings like create, delete, and reply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating ticket fields, but no explicit guidance on when to use this vs. siblings like osticket_reply_ticket (which likely adds a public reply). No when-not or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.1.0osticket_create_ticketosticket_delete_ticketosticket_download_attachmentosticket_get_childrenosticket_get_parentosticket_get_statsosticket_get_ticketosticket_link_subticketosticket_list_statusesosticket_list_ticketsosticket_reply_ticketosticket_search_ticketsosticket_unlink_subticketosticket_update_ticketEach tool targets a unique operation on tickets or related entities (attachments, parent-child relationships, statistics, statuses). There is no ambiguity between tools; even similar ones like get_ticket vs list_tickets vs search_tickets have clearly different purposes.
All tools follow the pattern osticket_verb_noun with consistent snake_case. Verbs like create, delete, get, list, search, reply, update, link, unlink, and download are appropriately chosen and clearly convey the action.
14 tools cover the essential ticket management operations (CRUD, parent-child, attachments, statistics, statuses) without being excessive. Each tool earns its place for a focused osTicket MCP server.
Core ticket lifecycle (create, read, update, delete), parent-child management, replying, searching, and statistics are covered. Minor gap: no tool for uploading attachments on ticket creation or replies, but the overall surface is thorough.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read tickets, contacts, companies, agents and groups; create, update and reply to tickets.
List, search, create, update, and reply to support tickets across your Dispatch Tickets brands.
Read tickets, users, orgs, macros and satisfaction ratings; create, update and comment on tickets.
Manage Superlist tasks and lists in plain language from any MCP-compatible AI agent.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nks-hub/nks-osticket-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server