Manage Freshservice ITSM tickets, problems, changes, releases, assets and the service catalog.
Freshservice ships in the w6w first-party pack. It declares 23 actions, 3 health checks, and the host runs its code in a sandbox that never sees the credential.
io.w6w.freshserviceFreshservice is Freshworks’ ITSM platform, and this app manages the tickets at its center along with problems, changes, releases, assets and the service catalog around them. Create, read, update, delete and restore tickets, add notes and replies to a conversation, and pull requesters, agents, groups, departments and locations — the directory data ticket work depends on.
Beyond ticketing, it reaches into change management — creating a change with its priority, risk and impact grading — the CMDB, where assets are created and looked up by their display id, and the service catalog and knowledge base, where service items are listed and solution articles searched. These are the parts of ITSM that sit around a ticket rather than inside one.
A fit for workflows that create tickets from an external trigger, keep a change record in sync with a deployment pipeline, or surface asset and requester context automatically instead of an agent looking it up by hand. Every account has its own Freshservice subdomain, which the connection resolves once so no action needs to carry it.
Three routes to the same 23 actions. The Workflow tab is generated from Freshservice's own manifest and carries its real ids, so it is copy-pasteable; the Code and CLI examples are the same call for any action on any app, so every app-specific value in them is a blank you fill in.
agent-get-many List agents — the people who work tickets. Useful for resolving an assignee ID.
asset-create Add an asset to the CMDB. `Type fields` carries the asset-type-specific attributes, whose keys are suffixed with the asset type ID.
asset-get Fetch one asset. Assets are addressed by their DISPLAY ID, not the `id` field — that is Freshservice's own convention here.
asset-get-many List CMDB assets, newest first. Assets not in the trash are returned unless `Trashed` is set.
change-get-many List change requests, with the Changes module's own query and view filters.
conversation-get-many Every note and reply on a ticket. Use this rather than `ticket-get`'s embed once a ticket has more than ten.
group-get-many List agent groups. Groups are per-workspace in Freshservice, so there is no all-workspaces listing — pass one workspace at a time.
location-get-many List the cities, campuses, offices and rooms assets and users are filed under.
problem-get-many List problem records. Without a workspace only the primary one is returned; pass 0 for every workspace.
release-get-many List release records. Without a workspace only the primary one is returned; pass 0 for every workspace.
requester-get-many List requesters — the people who raise tickets. Called Contacts in Freshservice for MSPs.
service-item-get-many List the service catalog. The `display_id` on each item is what a service request is placed against.
solution-article-search Search the knowledge base. Returns only PUBLISHED articles the credential's own user can see.
ticket-add-note Add a note to a ticket. Notes are private by default — visible to agents but not the requester.
ticket-add-reply Send a public reply to the requester. Unlike a note, this leaves the portal.
ticket-delete Move a ticket to the trash. Deleting a parent service request deletes its child tickets too; `ticket-restore` brings it back.
ticket-get-many List tickets, newest first by default. Only tickets created in the past 30 days are returned unless `Updated since` is set.
ticket-update Change a ticket's fields. Only the fields you set are sent, so untouched ones keep their values.
A workflow step names the app and the action, and the editor fills in the
connection when you pick one. This is the Step shape from the
workflow spec, carrying Freshservice's real ids.
{
"manifestVersion": "2",
"name": "freshservice-example",
"steps": [
{
"id": "asset-create",
"uses": {
"app": "io.w6w.freshservice",
"action": "asset-create",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"name": "<name>",
"assetTypeId": "<assetTypeId>"
}
}
]
}asset-create agent-get-many asset-get asset-get-many change-create +18 more actions available
Every app-specific value here is a blank you have to fill in. An
app action is reached through the connection that authenticates it, so the
address is a connection id, not the app id — and connections belong to your account,
so a public page cannot know yours. Create one for Freshservice, then fill in
the three blanks: conn_YOUR_CONNECTION_ID, the action key, and the
parameters that action declares. The call itself is real — the shape is transcribed
from the studio's own snippet builder, which prints the same kind of blanks — but
nothing in it is specific to Freshservice. The Workflow tab is where this app's
real ids are.
npm install @w6w/sdkyarn add @w6w/sdkpnpm add @w6w/sdkdeno add npm:@w6w/sdkimport { W6wClient, isActionRun } from "@w6w/sdk";
// Reads W6W_BASE_URL and W6W_TOKEN from the environment when omitted.
const client = new W6wClient();
const envelope = await client.run({
urn: "conn_YOUR_CONNECTION_ID",
action: "ticket-create",
payload: {
subject: "<value>",
description: "<value>",
// requesterEmail: "<value>",
// requesterId: "<value>",
// status: "<value>",
// priority: "<value>",
// source: "<value>",
// urgency: "<value>",
// impact: "<value>",
// groupId: "<value>",
// responderId: "<value>",
// departmentId: "<value>",
// category: "<value>",
// subCategory: "<value>",
// itemCategory: "<value>",
// tags: "<value>",
// ccEmails: "<value>",
// dueBy: "<value>",
// workspaceId: "<value>",
// customFields: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value); npm install -g @w6w/cli w6w run conn_YOUR_CONNECTION_ID --action ticket-create --payload '{"subject":"<value>","description":"<value>"}' Give an AI agent Freshservice — without giving it Freshservice's credentials. One MCP endpoint exposes every app, function and workflow the caller is entitled to, as tools it can discover and run. Access is granted per team while we onboard.
One tool call{
"name": "w6w_invoke",
"arguments": {
"ref": "app:io.w6w.freshservice#asset-create",
"input": {
"name": "<name>",
"assetTypeId": "<assetTypeId>"
}
}
}
Every tool names its target with a single ref. The
app: form above doesn't name a connection at all — the
host resolves which of the caller's Freshservice connections to sign
with, and refuses rather than guesses when the answer is ambiguous.
The token is attached host-side, at the moment of the call. It is never a tool argument, never in the model's context, and never in a transcript — so a prompt injection has nothing to exfiltrate.
Tools are derived per end user from what that person has actually connected and is entitled to — not one shared bot identity carrying the union of everyone's access.
Multi-step work runs on the workflow engine and returns a run handle the agent can poll — retries, branching and state survive the conversation that started them.
Freshservice's declared health checks are on the surface too, so an agent can tell "the vendor is down" from "your credential expired" before it burns a retry on either.
The MCP surface is part of the hosted platform. Freshservice itself is MIT, and the runtime that executes it is source-available (FSL).
Freshservice declares its own checks, so its health is a property of the app rather than something the host guesses at.
Component status from Freshstatus, the platform behind updates.freshservice.com. Reports one component per hosting region.
Per-minute account allowance remaining, read off the `X-Ratelimit-*` headers on a one-row ticket read.
Unauthenticated request to this connection's Freshservice domain. A 403 passes — it proves the portal is serving; credential validity is the `auth:*` check's job.