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., "@Freshdesk MCP Server show me all open high priority tickets"
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.
Hey! This is a custom Model Context Protocol (MCP) server for Freshdesk. It's built on top of FastMCP to let your AI agents (like Claude Desktop or custom LangChain setups) read and write directly to your Freshdesk account.
I've packed in a bunch of tools so the AI can handle almost any helpdesk task:
Tickets & Responses
get_tickets: Search and filter incoming tickets.
get_ticket: Pull all details for a specific ticket.
create_ticket: Open a new support ticket.
update_ticket: Change status or priority.
delete_ticket: Trash a ticket (be careful with this one).
reply_ticket: Send a reply to the customer.
add_note: Drop an internal or public note on a thread.
list_conversations: Grab the entire back-and-forth history of a ticket.
create_outbound_email: Send proactive emails (fully supports CC, BCC, tags, and custom fields).
Customers & Companies
search_contacts: Look up customers by email or phone.
get_contact / create_contact / update_contact: Manage your user base.
get_company / create_company: Manage companies.
Agents & Knowledge Base
list_agents / get_agent: See who is working on what.
search_solution_articles / get_solution_article: Let the AI search your help docs so it can answer questions better.
Related MCP server: Freshservice MCP Server
If you just want to run this locally on your own machine (like inside Claude Desktop), it's super simple:
Clone this repo and set up your environment:
python -m venv venv
source venv/bin/activate
pip install -e .Copy the .env.example file to .env and drop in your Freshdesk domain and API key.
Start it up:
mcp dev src/freshdesk_mcp/server.pyIf you're hosting this on a cloud server so multiple remote agents can talk to it, you don't want just anyone hitting your API. I built a lightweight, database-free JWT authentication layer over the SSE connection to keep it safe.
Here's how to use it:
In your .env, set up your JWT_SECRET_KEY and define who is allowed to connect using ALLOWED_CLIENTS=agent1:pass123,agent2:secure456.
Run the secure server wrapper:
python -m freshdesk_mcp.serveYour clients will first need to send a POST request to /token (using Basic Auth with their agent credentials) to get a 1-hour JWT.
They can then connect to the main MCP stream by passing Authorization: Bearer <their_token> in the headers.
(Pro-tip: If you want to make sure an AI agent can only read data and doesn't accidentally delete anything, just set STRICT_MODE=True in your .env and it will lock down all destructive tools).
MIT License - feel free to use and modify it however you need!
Add a note to a ticket. private=True means it is an internal note.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| private | No | ||
| ticket_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only clarifies the private parameter meaning. It does not disclose side effects, permission requirements, immediacy of action, or constraints beyond what the schema shows.
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?
Very concise at two sentences, no wasted words. First sentence front-loads purpose. Slightly more length could include parameter clarifications without harming conciseness.
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?
Minimal completeness given the tool's context. Lacks explanation of return value, potential errors, or when to use. For a 3-param tool with no schema descriptions, more context is needed for effective use.
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 has 0% description coverage. The description adds meaning only for the 'private' parameter, leaving 'body' and 'ticket_id' unexplained. Body likely contains note text, but no clarification.
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 'Add a note to a ticket', which is a specific verb+resource. It distinguishes from sibling tools like reply_ticket by mentioning the private flag meaning internal note, implying use case.
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 guidance on when to use this tool versus alternatives. Only mentions the private parameter meaning, but does not provide context for choosing between add_note and reply_ticket or other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new company.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| description | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It only states 'Create a new company,' offering no details on side effects, idempotency, permissions, or error handling.
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 short sentence, which is concise but under-specified. It lacks necessary details that would make it useful, violating the principle that conciseness should not sacrifice completeness.
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's simplicity (2 params, output schema exists), the description should mention return values or validation. It fails to provide enough context for an AI agent to use it correctly.
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 0%, and the description adds no meaning to the parameters. It does not explain what 'name' or 'description' should represent (e.g., uniqueness, format).
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 'create' and resource 'company.' However, it does not differentiate from sibling tools like create_contact or create_ticket, missing a chance to specify unique scope or behavior.
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. No prerequisites, context, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new customer contact.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| Yes | |||
| phone | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'create' (implying mutation) but omits permissions, idempotency, duplicate handling, or any side effects. The output schema exists but is not referenced.
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, making it concise. However, it sacrifices information density; it could include parameter guidance or behavioral notes without becoming 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?
With an output schema available and no annotations, the description fails to provide necessary context about return values or constraints. It is too sparse for a tool with multiple parameters and siblings.
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 0%, yet the description adds zero information about parameters. The agent learns nothing about 'name', 'email', or 'phone' beyond their names and types 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?
Description clearly states verb ('create') and resource ('customer contact'), distinguishing it from siblings like update_contact. However, it is nearly a tautology of the tool name, lacking additional nuance.
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 versus alternatives (e.g., create_company, update_contact, search_contacts). The agent receives no contextual cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create and send an outbound email from Freshdesk. Supports cc, bcc, tags, and custom fields.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| Yes | |||
| status | No | ||
| subject | Yes | ||
| priority | No | ||
| cc_emails | No | ||
| bcc_emails | No | ||
| description | Yes | ||
| workspace_id | No | ||
| custom_fields | No | ||
| email_config_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'Create and send' with no details on expected behavior (e.g., idempotency, error conditions, permission requirements). It adds little beyond the fact that it's a write operation.
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 efficiently states purpose and key supported fields. It front-loads the core action, but could be slightly more structured (e.g., separating purpose and supported features). No filler.
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 11 parameters, 4 required, and an output schema, the description is too sparse. It does not explain the output, prerequisites (e.g., email_config_id configuration), or the broader workflow context (e.g., relationship to tickets or contacts).
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 0%, and the description only mentions cc, bcc, tags, and custom fields by name without explaining their purpose, format, or relationships. Required parameters (email, subject, description, email_config_id) are not elaborated, so the description adds minimal semantic value beyond 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 the tool creates and sends an outbound email from Freshdesk and lists supported features (cc, bcc, tags, custom fields). However, it could more explicitly distinguish this from sibling tools like reply_ticket, and clarify whether the email is tied to a ticket or standalone.
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 versus alternatives (e.g., reply_ticket). The description does not include when-not-to-use or prerequisites like email_config_id meaning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Freshdesk ticket. Priority: 1=Low, 2=Medium, 3=High, 4=Urgent. Status: 2=Open, 3=Pending, 4=Resolved, 5=Closed.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | |||
| status | No | ||
| subject | Yes | ||
| priority | No | ||
| description | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 only states the action and enum values, omitting details such as side effects (e.g., notifications), authentication needs, idempotency, or confirmation behavior. This is insufficient for safe invocation.
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 brief (two sentences) and front-loaded with the action. It efficiently conveys core info but could include more detail without becoming 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?
With 5 parameters, 3 required, and no schema descriptions, the description should cover all parameter semantics and constraints. It only covers two. The presence of an output schema reduces the need to explain returns, but overall completeness is low.
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 0%. The description adds meaning for priority and status via enum mappings, but leaves subject, description, and email unexplained. This partially compensates but leaves significant gaps.
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 'Create a new Freshdesk ticket' which specifies the action and resource. It distinguishes from sibling tools like reply_ticket and update_ticket by focusing on creation. The enum mappings for priority and status further refine the purpose.
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 creating a new ticket but does not explicitly specify when to use this tool versus alternatives like reply_ticket or update_ticket. No guidance on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a specific ticket.
| Name | Required | Description | Default |
|---|---|---|---|
| ticket_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose important behavioral traits such as whether deletion is permanent or soft, whether it cascades to related data, or any side effects. No annotations are provided to fill this gap.
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 at one sentence, but it sacrifices critical details needed for correct usage. It is efficient in length but not in delivering complete 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?
Given the existence of an output schema (omitted) and no annotations, the description is insufficient. It does not explain what happens after deletion, whether any confirmation is needed, or how to handle errors. For a potentially destructive action, this is a significant gap.
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 parameter 'ticket_id' is left without any description in the schema (0% coverage) and the tool description adds no additional meaning beyond implying it identifies the ticket. No constraints, format, or source information is given.
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 'Delete a specific ticket' clearly specifies the action (delete) and the resource (ticket). It distinguishes this tool from sibling tools like create_ticket, update_ticket, and get_ticket, 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.
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 when to delete vs close or update a ticket. There are no prerequisites, conditions, or mentions of irreversible actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get specific agent details by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description is minimal and does not disclose any behavioral traits such as required authentication, error handling (e.g., what happens if agent_id not found), or side effects. With no annotations, the burden is fully on the description, which fails to provide 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?
While short, the description is under-specified and lacks structure. It does not provide a clear breakdown of behavior or parameters, making it less helpful despite its 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?
Given the low complexity (1 parameter, output schema exists), the description should at least explain the return value or typical use. It does not, leaving significant gaps in completeness.
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 0% and the description adds no meaning beyond the parameter name. It does not explain what 'agent_id' represents (e.g., format, source, range). The description fails to compensate for the lack of schema documentation.
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 'Get specific agent details by ID', specifying verb and resource. It distinguishes from sibling tool 'list_agents' which likely returns all agents. However, it could be more explicit about what 'details' includes.
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 versus alternatives like list_agents or get_ticket. No context about prerequisites or common workflows, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve company details by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| company_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should carry the burden of behavioral disclosure. It only states the basic action; no mention of safety, authentication needs, or side effects. The description adds no value beyond the obvious.
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, clear sentence with no waste. However, it is very brief and could benefit from minimal additional context.
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 low complexity and existence of an output schema, the description covers the basic purpose. However, it lacks usage context and sibling differentiation, making it minimally 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 0%, so the description must add meaning to the company_id parameter. It does not; the parameter is merely listed without any additional context or validation hints.
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 'Retrieve', resource 'company details', and method 'by ID'. It is specific but does not differentiate from sibling tools like get_contact or get_agent, which follow the same pattern.
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 versus alternatives. No mention of prerequisites, exclusions, or recommended conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve contact details by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| contact_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose that the tool is read-only, non-destructive, or any side effects. The output schema may cover return format, but behavioral traits like authorization or rate limits are missing.
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. Every word contributes to conveying 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 retrieval tool with one parameter and an output schema, the description covers the core action. It lacks usage guidance and behavioral transparency, but the output schema mitigates the need to explain return values.
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 0% (description does not mention any parameter). The description adds no meaning beyond the schema field name 'contact_id'. Since schema coverage is low, description should compensate but fails.
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 the verb 'retrieve' and resource 'contact details by ID'. It distinguishes from sibling tools like create_contact, update_contact, or search_contacts which have different purposes.
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 like search_contacts. Usage is implied when a specific contact ID is known, but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the content of a specific knowledge base article.
| Name | Required | Description | Default |
|---|---|---|---|
| article_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully convey behavior. It only states 'retrieve', implying read-only, but does not disclose any permissions, rate limits, or side effects. The output schema exists but is not described, leaving ambiguity about what 'content' includes.
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 superfluous words, achieving maximum conciseness. However, it could benefit from a bit more structure, such as specifying what 'content' entails or the expected output.
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 simplicity of the tool (one parameter, output schema exists), the description covers the basic purpose. But it fails to provide enough context for an AI agent to understand potential limitations, error cases, or whether the article content includes metadata. Acceptable but not thorough.
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 schema has 0% documentation coverage for parameters. The description mentions 'specific knowledge base article' but does not explain the 'article_id' parameter's format, source, or constraints. The parameter is required but lacks semantic explanation beyond its name.
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 ('Retrieve') and the resource ('content of a specific knowledge base article'), with an implication that the article ID is the key. It distinguishes from sibling 'search_solution_articles' which is a search tool. However, it does not articulate the scope or any unique aspects beyond the basic 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?
No guidance is provided on when to use this tool versus alternatives, nor are there any usage conditions or prerequisites mentioned. The description lacks context for when retrieval is appropriate compared to searching or other actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific ticket by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| ticket_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only says 'Get detailed information' without disclosing any behavioral traits (e.g., read-only nature, potential restrictions, or error conditions). It relies on the tool name, which 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, efficient sentence with no wasted words. However, it is too short to be fully informative, slightly under-specifying for its context.
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 single integer parameter and presence of an output schema, the description is minimally adequate. However, it does not elaborate on what 'detailed information' entails, leaving some ambiguity.
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 0% (no parameter descriptions), and the description adds no extra meaning to the single 'ticket_id' parameter beyond its name. It does not clarify format, source, or validation.
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 detailed information') and the resource ('a specific ticket by ID'), distinguishing it from sibling tool 'get_tickets' which implies listing. It is specific and actionable.
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 like 'get_tickets' or 'reply_ticket'. It does not specify prerequisites, edge cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tickets in Freshdesk. Optionally filter by requester email.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'List tickets' but does not disclose behavioral traits such as pagination behavior, rate limits, or what happens when no tickets are found. The presence of a page parameter suggests pagination but is not 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?
The description is concise with two sentences, no fluff. However, it could benefit from a more structured format to include parameter explanations.
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 presence of an output schema (not shown) and two parameters, the description is too minimal. It lacks details on pagination, default behavior, and how to use the email filter (e.g., exact match or substring).
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?
With 0% schema description coverage, the description must explain parameters. It explains the email parameter (optional filter) but does not explain the page parameter at all. The meaning of page (e.g., page number, page size) is left ambiguous.
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 tool lists tickets in Freshdesk and optionally filters by requester email. It uses a specific verb and resource, and while it doesn't explicitly distinguish from get_ticket (singular), the plural 'tickets' implicitly implies listing multiple.
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 like get_ticket (singular) or other sibling tools. There is no mention of exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List support agents. Optionally filter by email.
| Name | Required | Description | Default |
|---|---|---|---|
| No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavior. It implies a safe read operation ('list'), but does not disclose any potential side effects, rate limits, or result format. Minimal but not misleading.
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?
A single, front-loaded sentence that conveys the core purpose and filter option without extraneous words. Optimal conciseness for a simple tool.
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 existence of an output schema, return values need not be described. However, the description lacks any mention of pagination, ordering, or behavior when no filter is applied. It is adequate for a basic list but could be more comprehensive.
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 0%, so the description carries the burden. It states the 'email' parameter is used for optional filtering, which adds clarity. Although only one parameter, the explanation is sufficient and accurate.
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 ('List') and the resource ('support agents'), with optional filtering. This is straightforward, though the name itself is already informative, and the description adds little beyond confirming the filter capability.
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 versus siblings like 'get_agent' or 'search_contacts'. The description only mentions the optional email filter, without explaining when not to use it or what alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch all replies and notes associated with a ticket.
| Name | Required | Description | Default |
|---|---|---|---|
| ticket_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 does not disclose behavioral traits beyond the action itself, such as whether pagination is supported, if access control applies, or if the operation is read-only. The verb 'Fetch' implies read, but this is not explicit.
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 of 8 words, front-loading the core purpose. There is no redundant or extraneous information, earning its place efficiently. It is as concise as possible while achieving its goal.
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 one parameter, an output schema (not shown but present), and no nested objects, the description is minimally complete. It tells the agent what the tool does and which parameter is needed. However, it lacks details on output structure or behavioral constraints, which could be considered incomplete for an agent to predict side effects or handle errors.
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 schema has one parameter (ticket_id) with no description, and schema coverage is 0%. The description adds meaning by specifying that this parameter identifies the ticket whose replies and notes are fetched. However, it does not elaborate on expected format (e.g., integer from existing ticket IDs) or constraints, so it adds moderate value beyond 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 the verb 'Fetch' and the resource 'replies and notes associated with a ticket', which aligns with the tool name 'list_conversations'. It distinguishes from siblings like 'get_ticket' which retrieves a single ticket, and 'reply_ticket' which is a write operation. However, it could be more explicit about what constitutes a conversation (e.g., replies to a ticket and internal notes).
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 only states what the tool does, with no guidance on when to use it versus alternatives. It does not mention when not to use it or compare it to siblings like 'get_ticket' for retrieving conversation details. This leaves the agent without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reply to an existing ticket.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| ticket_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight—no details on side effects (e.g., email notification), required permissions, or what 'reply' actually entails beyond the name.
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 single sentence is excessively brief, lacking critical details; this is under-specification, not conciseness, as each sentence should earn its place but fails to provide actionable guidance.
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?
Despite having an output schema, the description omits essential context: prerequisites (ticket existence), behavioral outcomes (public vs internal reply), and parameter semantics, making it incomplete for confident use.
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 0%, yet the description adds zero meaning to the parameters: no explanation that 'body' is the reply content or that 'ticket_id' identifies the target ticket, leaving the agent uninformed.
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 'Reply to an existing ticket' clearly identifies the action (reply) and resource (ticket), distinguishing it from related tools like 'create_ticket' or 'add_note' in purpose, though not explicitly differentiating.
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 the ticket must already exist, but lacks explicit guidance on when to use this tool versus alternatives (e.g., 'add_note' for internal notes), and no exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a contact by email, phone, or mobile.
| Name | Required | Description | Default |
|---|---|---|---|
| No | |||
| phone | No | ||
| mobile | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The term 'Find' suggests a read-only operation, but there is no disclosure about behavior such as whether it returns one contact or multiple, what happens with partial matches, or any authentication requirements. This is insufficient for a search tool.
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. No extraneous information or unnecessary detail.
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?
While there is an output schema (not shown), the description fails to explain what is returned, such as a list of matching contacts or details about each contact. It omits critical context about match behavior, pagination, or error handling. For a search tool without annotations, this is incomplete.
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 0%, with no descriptions for the three string parameters. The description merely lists the parameter names (email, phone, mobile) without adding meaning beyond what is in the schema. It does not explain how they interact (e.g., OR vs AND) or expected format. At 0% coverage, the description should compensate significantly, but it does not.
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 'Find' and the resource 'contact', along with the search criteria (email, phone, or mobile). It is specific and distinguishes from sibling tools like get_contact (which likely retrieves by ID) and create_contact.
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 an email, phone, or mobile, but it does not provide explicit guidance on when to use this tool versus alternatives like search_solution_articles or other contact retrieval methods. No when-not-to-use or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for knowledge base articles by keyword.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not state whether the search is read-only (likely but not confirmed), whether results are paginated, or how matching works (exact vs fuzzy). Key behavioral traits are missing.
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 wasted words, which is concise. However, it lacks structure (e.g., bullet points or separate sections) and could benefit from more informative content without losing 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?
Given the presence of an output schema and many sibling tools, the description is underdeveloped. It does not explain how the search behaves (e.g., pagination, result limits, sorting) or how it differs from get_solution_article. The output schema partially compensates, but the tool description remains incomplete for an AI agent to use confidently.
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 schema has 0% description coverage, so the description must add meaning to the keyword parameter. It merely restates 'by keyword' without specifying format, length, case-sensitivity, or allowed patterns. This adds minimal value beyond the parameter name.
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 (search) and resource (knowledge base articles) with the keyword filter. It is specific and unambiguous, though it does not explicitly differentiate from sibling search tools like search_contacts or the retrieval tool get_solution_article.
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 like get_solution_article (for specific article retrieval) or search_contacts (for contact search). There is no mention of prerequisites, exclusions, or best use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing contact's details.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| No | |||
| phone | No | ||
| contact_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states 'Update' without disclosing required permissions, side effects (e.g., overwriting fields), or what happens when optional fields are omitted.
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 short sentence, which is concise, but it lacks substantive content. It is not overly verbose, but it fails to convey essential information efficiently.
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 4 parameters and an output schema (not shown), the description is too brief. It does not clarify which fields can be updated or the granularity of updates, leaving significant gaps.
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 0%. The description adds no meaning to parameters like name, email, phone, or contact_id. It merely says 'details', which provides no additional context.
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 ('Update') and the resource ('an existing contact's details'). It distinguishes from siblings like create_contact (creation) and get_contact (read).
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 versus alternatives such as create_contact or update_ticket. No prerequisites or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a ticket's status or priority.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | ||
| priority | No | ||
| ticket_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only states 'update', implying mutation, but lacks details on side effects, required permissions, rate limits, or what happens to existing values. The description is insufficient for an agent to understand behavioral implications.
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 short sentence, making it concise and quick to read. However, it could be restructured to front-load the required ticket_id and indicate that both status and priority are optional.
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 relatively simple tool with 3 parameters and an output schema, the description is adequate but not complete. It lacks details on return values, error handling, and parameter semantics, which a complete description would include.
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 0%, so the description must compensate. It mentions 'status or priority' but does not clarify what integer values represent (e.g., mapping to ticket states). The description adds minimal semantic value beyond the parameter names.
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 (update) and resource (ticket) and specifies the fields to update (status or priority), distinguishing it from siblings like create_ticket or delete_ticket. However, it does not mention the required ticket_id or that only two fields are updatable.
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 like reply_ticket or add_note. There is no mention of prerequisites, use cases, or 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0add_notecreate_companycreate_contactcreate_outbound_emailcreate_ticketdelete_ticketget_agentget_companyget_contactget_solution_articleget_ticketget_ticketslist_agentslist_conversationsreply_ticketsearch_contactssearch_solution_articlesupdate_contactupdate_ticketEach tool targets a distinct resource and action. While add_note, reply_ticket, and create_outbound_email all relate to ticket communication, their purposes are clearly separated: notes, replies, and outbound emails respectively. No two tools could be easily confused.
All tool names follow a consistent verb_noun pattern in snake_case, such as create_ticket, get_contact, list_agents. The verbs are consistently chosen (create, get, list, update, delete, search, reply, add) and the nouns are singular or plural as appropriate.
With 19 tools, the server is slightly above the ideal range of 3-15, but each tool serves a distinct and necessary function within the Freshdesk domain. The count is justifiable given the variety of entities (tickets, contacts, companies, agents, knowledge base) and operations.
The tool set provides comprehensive coverage for tickets (CRUD, notes, replies, conversations, outbound emails). Contacts and companies have create, read, and update operations but lack delete and listing capabilities. Knowledge base supports search and retrieval but not curation. Overall, core workflows are well-supported with minor gaps.
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.
Connect AI tools to Weav customer service. Search conversations, reply, and manage knowledge.
Freshdesk MCP Pack — helpdesk ticket and contact management via Freshdesk API v2.
Read tickets, users, orgs, macros and satisfaction ratings; create, update and comment on tickets.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Sidd07Dev/freshdeskMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
