servicedesk-plus

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a distinct purpose: list, detail, create, update, add note, and list notes. No overlap or ambiguity between them.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case (e.g., list_tickets, create_ticket, update_ticket). This is uniform and predictable.
Tool Count5/5
Six tools is well-scoped for a help desk ticket server, covering core ticket operations and note management without unnecessary bloat.
Completeness4/5
The tool set covers create, read, update, list, and notes. Missing delete is acceptable for tickets, but lack of assign/transfer or note editing is a minor gap.
Average 4/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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.
This server has been verified by its author.
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?
With no annotations, the description must disclose behavioral details, but it only says 'update fields' without explaining null-value semantics, idempotency, behavior when a ticket doesn't exist, or response format. It leaves ambiguity about whether passing null clears a field or leaves it unchanged, which is critical for a mutation 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?
The description is concise: one purpose sentence plus a clean one-line-per-parameter list. It is front-loaded with the action and avoids unnecessary words, making it easy for an agent to quickly parse.
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?
For a simple update tool, the description covers purpose and parameter meanings, but it misses key operational context such as null semantics, minimum requirements, error behavior, and permissions. An output schema exists so return values are covered, but the lack of behavioral context and explicit usage guidance leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, so the description fully compensates by explaining every parameter: ticket_id as unique numeric ID, subject as optional new subject, description as plain-text/HTML, and status with examples. This adds significant meaning beyond the raw 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 uses a specific verb+resource: 'Update fields on an existing ticket in ServiceDesk Plus.' This clearly distinguishes from siblings like create_ticket (existing vs new) and list/get (fields vs retrieval). The Args section further reinforces 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?
The description implies use on existing tickets, but it does not explicitly contrast with create_ticket or other alternatives, nor does it state when not to use it. There are no preconditions or exclusions described, so the guidance is implied rather than explicit.
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?
With no annotations, the description carries the burden. 'Append' conveys a non-destructive, additive write operation, which is helpful. However, it does not disclose potential requirements (e.g., ticket existence, authorization, formatting constraints) or response behavior beyond the append.
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 very concise: two sentences for purpose plus a compact Args list. No filler or redundant content, and essential parameter details are front-loaded.
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 simplicity and the presence of an output schema (which removes need to describe return values), the description covers the core purpose and all parameter semantics. It lacks usage guidance and behavioral caveats, but overall it is reasonably complete for a straightforward append operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description's Args section explicitly explains both parameters: ticket_id is 'the unique numeric ID' (clarifying despite schema string type) and note is 'Text content of the note to append.' This fully compensates for the schema gap.
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 with a specific verb ('Append') and resource ('note to a ticket'). It differentiates from siblings like list_ticket_notes (read operation) and create_ticket/update_ticket (ticket-level operations), making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any context about prerequisites (e.g., ticket must exist) or outcomes. The sibling list is available but the description does not reference it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description carries the full burden of behavioral disclosure. It does not mention read-only nature, error handling, pagination, ordering, or what happens if the ticket does not exist, leaving significant uncertainty for an agent.
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 extremely concise, with a one-sentence purpose followed by a single parameter explanation. It is well-structured, front-loaded, and contains no unnecessary information.
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?
For a simple single-parameter list tool, the description covers purpose and parameter adequately. However, it lacks behavioral details like error conditions, ordering, or pagination, which are not compensated by the existing output schema.
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?
With 0% schema description coverage, the description compensates by explaining that ticket_id is 'the unique numeric ID of the ticket.' This adds meaning beyond the schema's bare type definition, clarifying that the ID is unique and numeric despite being typed as a string.
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 'List all notes attached to a specific ticket' with a specific verb (list), resource (notes), and scope (attached to a ticket). This distinguishes it from sibling tools like list_tickets (lists tickets) and add_ticket_note (adds a note).
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 makes it clear that this tool is for retrieving notes for a given ticket, providing clear context on when to use it. It implies the need for a valid ticket_id and is distinct from sibling tools, though it does not explicitly mention alternatives.
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?
With no annotations, the description must carry the full burden of behavioral disclosure. It does reveal that the description field accepts plain-text or HTML and that requester_email defaults when omitted, but it does not mention permissions, idempotency, side effects, or what the response contains.
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 extremely concise: one purpose sentence plus a bullet list of four parameters. It is front-loaded with the primary action and each parameter gets a brief, informative line, with 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?
For a simple create operation, the description covers the main action and all parameters, and an output schema exists to define return values. However, it omits explicit usage guidance and any preconditions, making it adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description fully compensates by explaining each parameter: subject, description, priority (with examples), and requester_email (with default behavior). This adds substantial meaning beyond the bare property names.
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 states 'Create a new Help Desk ticket in ServiceDesk Plus,' which is a specific verb (create) and resource (Help Desk ticket) with a clear system context. This clearly distinguishes it from sibling tools like list_tickets and update_ticket.
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 does not explicitly mention when to use this tool or any alternatives, so the usage is implied by the name and purpose. It offers no exclusions or comparison to sibling tools like update_ticket or add_ticket_note, leaving the agent to infer the correct 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?
With no annotations, the description carries the behavioral transparency burden. It discloses useful details like default row_count (20) and max (100), and that start_index is 1-based. However, it does not mention return structure, ordering, or how filters are combined, leaving some behavioral gaps.
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 concise and well-structured: a brief summary sentence followed by a clean argument list. Every line adds value, with no fluff or repetition.
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 presence of an output schema and clear parameter documentation, the description is largely complete for a listing tool. Minor gaps like default ordering and filter combination semantics prevent a perfect score, but these are not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the sole source of parameter meaning. It explains every parameter, provides examples for status, and clarifies search_query searches ticket subjects. It also adds the row_count maximum and start_index base, going 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: 'Retrieve, search, and filter ServiceDesk Plus tickets.' This uses a specific verb and resource, and distinguishes it from siblings like get_ticket (singular), create_ticket, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not provide explicit when-to-use or when-not-to-use guidance, nor does it contrast with alternatives like get_ticket. Usage is implied rather than stated.
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?
No annotations are provided, so the description carries the full burden. It discloses the read-only nature via 'Retrieve' and indicates some return fields, but it does not address error conditions (e.g., non-existent ticket), authorization requirements, or any side effects. This is a moderate disclosure.
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 concise and front-loaded, with one sentence for purpose and a brief Args line. No wasted words or extraneous 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?
For a single-parameter read tool with an output schema, the description is largely complete. It specifies the input and the kind of information returned. It could mention not-found behavior, but that is not critical for a straightforward retrieval.
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 description adds meaning to ticket_id by describing it as a unique numeric ID for the ticket to retrieve. This goes beyond the schema's bare type/title, though the type mismatch (numeric vs string) could cause minor confusion. Overall, it meaningfully enhances 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 retrieves detailed information on a single ticket, listing specific fields (status, resolution, description). This distinguishes it from siblings like list_tickets, create_ticket, and update_ticket, which handle 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'single ticket' provides clear context that this is for retrieving one specific ticket, not multiple. However, it does not explicitly mention alternatives like list_tickets for multiple tickets or add any 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.

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:

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

Score Badge

Copy to your README.md:

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

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/kaattaalan/servicedesk-mcp'

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