Click on "Deploy 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., "@Freshdesk MCP Server Get details of ticket 12345"
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 (MCP) server that fetches Freshdesk ticket details and provides them as context for LLM interactions.
get_ticket - Fetch complete ticket details from a Freshdesk URL or ticket ID
Ticket metadata (subject, status, priority, type, tags)
Requester and assignee information
All conversations (replies and private notes)
Attachments list
Time entries
Satisfaction ratings
Custom fields
search_tickets - Search tickets by text query
Filter by status (open, pending, resolved, closed)
Filter by priority (low, medium, high, urgent)
Configurable result limit
get_agent_tickets - Get tickets assigned to a specific agent
Search by agent name (supports partial matching)
Filter by status
Configurable result limit
Related MCP server: Freshservice MCP Server
No installation required. Add directly to your config:
Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"freshdesk": {
"command": "npx",
"args": ["-y", "github:nikhilchintawar/freshdesk-mcp"],
"env": {
"FRESHDESK_API_KEY": "your-api-key",
"FRESHDESK_DOMAIN": "yourcompany"
}
}
}
}Claude Code (~/.claude/settings.json):
{
"mcpServers": {
"freshdesk": {
"command": "npx",
"args": ["-y", "github:nikhilchintawar/freshdesk-mcp"],
"env": {
"FRESHDESK_API_KEY": "your-api-key",
"FRESHDESK_DOMAIN": "yourcompany"
}
}
}
}# Clone the repository
git clone https://github.com/nikhilchintawar/freshdesk-mcp.git
cd freshdesk-mcp
# Install dependencies
npm installThen add to your config:
{
"mcpServers": {
"freshdesk": {
"command": "node",
"args": ["/absolute/path/to/freshdesk-mcp/build/index.js"],
"env": {
"FRESHDESK_API_KEY": "your-api-key",
"FRESHDESK_DOMAIN": "yourcompany"
}
}
}
}Claude Desktop (macOS): ~/Library/Application Support/Claude/claude_desktop_config.json
Claude Desktop (Windows): %APPDATA%\Claude\claude_desktop_config.json
Claude Code: ~/.claude/settings.json
Variable | Description | Required |
| Your Freshdesk API key | Yes |
| Your Freshdesk subdomain (e.g., | Yes |
Once configured, you can use natural language to interact with Freshdesk:
"Get the details of ticket https://mycompany.freshdesk.com/a/tickets/12345"
"Search for tickets about 'login issue'"
"Show me all open tickets assigned to John"
"Find high priority tickets related to billing"
Log in to your Freshdesk account
Click on your profile icon → Profile Settings
Your API key is displayed on the right side of the page
# Watch mode for development
npm run dev
# Build for production
npm run build
# Test with MCP Inspector
FRESHDESK_API_KEY=your-key FRESHDESK_DOMAIN=your-domain \
npx @modelcontextprotocol/inspector node build/index.jsMIT
Get tickets assigned to a specific Freshdesk agent by name. Supports partial name matching.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default: 30, max: 100) | |
| status | No | Filter by ticket status (optional) | |
| agent_name | Yes | Name of the agent to find tickets for. Supports partial matching (e.g., 'John' will match 'John Doe'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses partial name matching, but does not mention error handling, pagination, ordering, or permissions. For a listing tool, more context on results behavior would help.
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 with no unnecessary words. It is front-loaded with the action and resource. However, it could be slightly more structured with separate sections for usage notes.
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 3 parameters, no output schema, and no annotations, the description covers the basic purpose but lacks details on return format, sorting, error cases, and pagination. It is sufficient for simple usage but not fully 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?
Schema description coverage is 100%, so the description adds no additional parameter details beyond what the schema provides. It reinforces partial matching for agent_name but does not enhance understanding of limit or status.
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 tickets' and the resource 'assigned to a specific Freshdesk agent by name'. It also mentions partial name matching. This distinguishes it from sibling tools like get_ticket (single ticket) and search_tickets (general search).
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 does not explicitly provide guidance on when to use this tool versus alternatives. It implies usage when filtering by agent name, but lacks explicit when-not-to-use criteria. Sibling tools are listed but not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch complete ticket details from Freshdesk including conversations, attachments, time entries, and satisfaction ratings. Accepts a ticket URL or ID.
| Name | Required | Description | Default |
|---|---|---|---|
| ticket | Yes | Freshdesk ticket URL or ticket ID. Examples: 'https://company.freshdesk.com/a/tickets/12345' or '12345' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lists included data (conversations, attachments, etc.) implying a comprehensive fetch. No annotations, but no contradictions; a simple read operation without 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?
Single sentence with no wasted words, front-loading the action and including key details.
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?
Covers purpose, input, and included data adequately for a simple fetch tool. Lacks mention of error handling or pagination, but acceptable 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?
Schema already provides 100% coverage with examples. Description adds minimal extra value beyond stating input format (URL or 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 specifies the tool's action (fetch complete ticket details) and distinguishes it from siblings like get_agent_tickets and search_tickets by focusing on a single ticket by URL or ID.
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?
Implicitly indicates use when a ticket identifier is known and full details are needed. Sibling names provide context for alternatives, but no explicit when-not-to conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Freshdesk tickets by text query. Can filter by status and priority.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default: 30, max: 100) | |
| query | Yes | Search text to find in ticket subject or description | |
| status | No | Filter by ticket status (optional) | |
| priority | No | Filter by ticket priority (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits like pagination, rate limits, authentication requirements, or response format. Only a basic search/filter action is described.
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 unnecessary words. Essential information is front-loaded. Every sentence earns its place.
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 tool has no output schema, so the description should hint at return values (e.g., ticket summaries or IDs). It does not, leaving the agent uncertain about the result format. For a search tool with 4 parameters, more context is needed.
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 all parameters described. The description adds 'by text query' and mentions filters, but does not significantly augment schema information. Baseline score of 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 it searches Freshdesk tickets by text query with optional filters, distinguishing it from siblings like get_ticket (single ticket) and get_agent_tickets (agent-specific).
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 implicitly suggests use for searching tickets but does not explicitly state when to use this tool versus alternatives, nor when not to use it. No exclusions or context provided.
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.
v1.0.0get_agent_ticketsget_ticketsearch_ticketsScored across 3 tools
Each tool targets a distinct operation: fetching by agent, fetching by ID/URL, and searching by text query. There is no overlap in purpose.
All tool names follow a consistent verb_noun pattern using snake_case (get_agent_tickets, get_ticket, search_tickets).
Three tools is on the low side but still within the typical 3-15 range and each tool serves a clear read-focused purpose for the domain.
Only read operations are covered; missing create, update, and delete functionalities that are essential for managing tickets in a CRM system.
Read tickets, contacts, companies, agents and groups; create, update and reply to tickets.
Read tickets, users, orgs, macros and satisfaction ratings; create, update and comment on tickets.
List, search, create, update, and reply to support tickets across your Dispatch Tickets brands.
Freshdesk MCP Pack — helpdesk ticket and contact management via Freshdesk API v2.